Stdio proxy
Wrap an individual server process. Inspect MCP tool calls before forwarding them to the backend.
oktsec / MCP Security
MCP security. Set limits on tool access.
Secure the path between AI agents and MCP servers. Review dependencies with Signal, enforce tool and parameter policy with Control, and test the boundary with Assessment.
Review the server, its tools and its access.
MCP security covers the tools, resources and trust boundaries exposed through the Model Context Protocol. A connected server gives an agent a way to act; its implementation, permissions and responses all belong in the security review.
THE QUESTION TO ASK
Which agent can use which tool, with which arguments?
Authentication establishes a caller’s identity. Action authorization narrows what that caller may do. Server code, tool definitions and returned content also need review.
Put policy between the request and the tool.
Control can wrap a single MCP server through a stdio proxy or front multiple backend servers through an MCP gateway. Enforcement applies to calls routed through that configured integration.
01 / Request
AI client / agent
Requests a tool and arguments
02 / Policy check
oktsec
Identity · allowlist · constraints · scan
03 / Execution
MCP server
Executes the permitted tool call
A tool response is another trust boundary. Optional backend response scanning and outbound controls depend on the configured deployment.
MCP gateway
Front configured stdio or HTTP backends, discover their tools and apply per-agent policy to tool calls.
Four MCP risks and the controls to review.
A trusted tool receives a dangerous argument.
The tool is permitted, but its requested path includes production secrets.
CONTROL TO REVIEW
Constrain parameter patterns, approved paths and maximum lengths.
Tool and parameter policyA server changes after approval.
A tool schema expands from a read-only operation to a general command.
CONTROL TO REVIEW
Review the changed definition and revisit approval before trusting the broader authority.
Dependency and schema reviewA response redirects the agent.
Returned content tries to turn a legitimate task into credential access or an unauthorized transfer.
CONTROL TO REVIEW
Treat tool output as untrusted. Combine configured content scanning with explicit action and egress policy.
Prompt injection boundariesIndividually allowed calls form a harmful chain.
A credential lookup is immediately followed by a network request to an external destination.
CONTROL TO REVIEW
Use configured tool-chain cooldowns and destination controls to restrict the sequence.
Test the connected workflowLimit the arguments an allowed tool accepts.
An allowlist decides whether the agent may invoke read_file. A parameter constraint limits which paths that permitted tool can receive. Both matter when the same server can reach public data and secrets.
ILLUSTRATIVE CONFIGURATION
Researcher → read_file
- Within scope
- /data/* and /public/*
- Outside scope
- /secrets/* and *.env
- Review the environment
- Path patterns supplement server permissions and filesystem isolation; they are not a sandbox.
Inspect the tool constraint configuration
agents:
researcher:
allowed_tools: [read_file, search_files]
tool_constraints:
- tool: read_file
parameters:
path:
allowed_patterns: ["/data/*", "/public/*"]
blocked_patterns: ["/secrets/*", "*.env"]Review servers before use and after changes.
Signal: review what you connect
Inspect MCP server code, tool definitions, packages and install paths; revisit material changes.
Control: constrain what can run
Apply explicit per-agent tool, parameter and content policy at supported enforcement points.
Assessment: test whether the boundary holds
Exercise realistic tool abuse, prompt injection and data paths within the agreed scope.
Record who called the tool and what policy decided.
Review the acting identity, requested tool, applied policy and outcome. With a node key configured, hash chained and signed audit records support independent integrity verification.
- Before rollout
- Inventory the configured servers, their owners and their tools. Establish the initial approval.
- During operation
- Review blocked and quarantined calls and the evidence attached to each decision.
- After a change
- Revisit schemas, dependencies and permissions; exercise consequential changes before widening scope.
Start with a clear answer.
Does connecting an MCP server make it trusted?
No. Connectivity describes how the client and server communicate. Trust also depends on the implementation, the permissions it receives and the actions it can perform.
Can policy restrict the arguments of a tool call?
Oktsec supports per-agent tool constraints, including allowed and blocked parameter patterns. This can narrow an otherwise permitted tool to approved paths or values.
Where does MCP enforcement run?
Control enforces inside the environment where the supported gateway, proxy or integration handles the action. Deployment depends on the MCP client, server transport and workflow.
MCP documentation and security research.
Review the tools your agent can call.
Share the client, server and tools involved. We will identify which calls can be checked and which access needs to be restricted.