Connecting an AI agent to a tool is not the same as deciding what that agent should be trusted to do.
That distinction matters with MCP-connected tools. MCP can make enterprise data and actions available to an agent, but the connection itself does not answer the buyer’s harder question:
Should this specific action be allowed right now, for this user, with this data, under these conditions?
Consider a hypothetical support agent connected to a ticketing system through MCP. A customer ticket contains hidden instructions telling the agent to export internal account data and attach it to a new ticket.
The agent follows the instruction because the content arrived through a trusted tool. The tool connection is legitimate. The requested action is not.
This is where many security designs break. They treat the path as trusted because the server was approved during setup. But trust in the tool does not transfer to every instruction returned by the tool, and it should not transfer to every action the agent can take afterward.
The practical control is to separate three decisions:
- What entered the system? User request, retrieved document, tool response, or agent-generated reasoning.
- What does the agent want to do? Read a record, modify a record, send a message, or trigger a transaction.
- What authority applies now? User identity, data sensitivity, target system, action risk, and current policy.
A runtime policy should evaluate the proposed action, not just the source of the request. Reading a public knowledge-base article may be low risk. Sending customer data to an external address is not, even if the instruction came from an approved MCP server.
For an enterprise buyer, the useful test is simple:
Can you reconstruct why the agent was allowed to take each consequential action?
That means the audit record should connect the request, the tool response, the proposed action, the policy decision, and any human approval. A log that only says “agent called tool X” is activity history, not decision evidence.
Platform and security teams should inspect their integrations with three questions:
- Which tools can return untrusted content?
- Which actions can the agent take without a fresh policy check?
- Which high-impact actions require a human decision?
If the answer to the second question is “all actions available to the agent,” the system has a permission problem, even if the MCP server itself is secure.
The goal is not to make every agent slow or unusable. It is to put the trust boundary where the risk actually appears: immediately before the action, when intent, identity, context, and policy can still be evaluated.
Top comments (2)
The protocol solves format negotiation, not security perimeter design. When a client passes bearer credentials or broad database access down to an MCP server, the trust boundary collapses to whatever prompt injection the LLM happens to encounter in external context. Treating connection syntax as an authorization boundary is how teams end up giving read-write scopes to unconstrained agent loops.
Agree that the check belongs right before the action. On an MCP server I built for a client's reporting database, what actually limited the risk wasn't approving the connector. It was the database layer: a read-only SQL user plus a table whitelist. Even if a tool response carried an injected instruction, the worst it could do was read data that was already approved for that use. For write actions, where do you prefer to run the policy check: inside the MCP server itself, or in a gateway in front of it?