Understanding the MCP Trust Boundary Problem
Model Context Protocol architectures typically involve a host application, one or more MCP servers exposing tools and resources, and a client-side connector that mediates between them. Security weaknesses in this class of system tend to center on how tool invocations are authorized at each hop rather than on a single component.
Most agent frameworks separate tool discovery, where an agent lists what tools are available, from tool invocation, where a specific tool is executed with parameters. The gap between these two stages is a recurring source of exposure. A tool can be registered with a narrow, well-documented capability while its actual execution logic accepts a broader range of inputs than the discovery-time description implies.
When authorization checks rely primarily on what was declared at registration rather than what is validated at execution, the system inherits a mismatch between intended and actual permission scope. This is an architectural pattern, not a defect unique to any single implementation, and it applies broadly to protocol-based agent tool-calling systems.
| Boundary Gap | Description |
|---|---|
| Discovery vs. Invocation | Tools are listed with declared capabilities but invoked with parameters that are not independently validated at call time. |
| Identity Delegation Chain | Agent permissions are inherited from the host application rather than bound to a specific, auditable principal. |
| Session State Reuse | Context shared across multiple tool calls in a session can widen scope if not re-validated per call. |
| Trust Surface Conflation | Tool descriptions used for LLM selection are treated as equivalent to server-side execution logic, creating misaligned authorization assumptions. |
How Permission Escalation Occurs at Runtime
Agent identity in multi-tool environments is often distinct from end-user identity, which creates a delegation chain running from user to agent to tool. If that chain is not explicitly constrained at each link, permission scope can widen without anyone deliberately granting it.
An agent process may hold credentials broader than any single task requires, simply because the host application authenticated once at session start and the agent inherited that context for every subsequent tool call. Session and context state shared across multiple invocations compounds this risk. If parameters, prior results, or authorization tokens persist across calls without being scoped and re-validated per call, an attacker or a compromised tool can exploit that persistence to escalate access beyond what any individual call would justify on its own.
Multi-server or multi-agent topologies increase the number of these trust boundaries, and each one must independently enforce least privilege rather than relying on a single perimeter control.
Key principle: Trust boundaries must be enforced at the point of execution, not only at design time or at initial registration. Session inheritance is not equivalent to per-call authorization.
Runtime Controls That Reduce Exposure
Registration-time configuration establishes intent but cannot substitute for execution-time validation. The following controls address the structural gaps identified above:
Per-Call Parameter Validation
Tool servers should validate incoming parameters against a schema at every invocation, independent of what was declared during tool registration. This closes the gap between discovery-time capability declarations and what execution logic actually accepts.
Scoped Agent Identity
Each agent or agent task should be bound to a minimal, auditable principal rather than inheriting the full credential set of the host application. Identity should be scoped to the specific task context, not the session lifetime of the broader application.
Per-Invocation Context Validation
Authorization state, including any tokens or session parameters, should be re-evaluated at each tool call rather than carried forward from a prior call. Context persistence should be explicit and bounded, not the default behavior.
Least-Privilege Tool Permissions
Tool permissions should be defined and enforced at the narrowest scope that satisfies the documented use case. Permissions granted for convenience or broad coverage create unnecessary attack surface across all agents that share those tools.
Audit Logging at Execution Boundaries
Logs should capture what tool was called, with what parameters, under what agent identity, and at what time, at the point of actual execution rather than only at the orchestration layer. This makes post-incident analysis viable and supports compliance review.
Immediate Audit Steps for Security Teams
Security teams evaluating existing MCP deployments should prioritize these review areas:
- Map every MCP server in use and identify which agent processes are authorized to call which tools, using documented justification rather than inferred scope.
- Determine whether tool authorization checks occur at registration time only, at orchestration time, or at execution time on the server side. Identify gaps.
- Review how agent credentials are issued and whether they are scoped to specific tasks or inherited from the host application session.
- Assess whether session state and context tokens are re-validated at each tool invocation or carried forward implicitly.
- Confirm that audit logs capture execution-level detail, including agent identity, tool name, parameters, and timestamps, rather than only top-level orchestration events.
- In multi-server or multi-agent deployments, verify that each trust boundary independently enforces least privilege rather than trusting upstream authorization decisions.
- Check whether incident response plans include agent tool-call misuse as a distinct scenario category with defined detection and containment steps.
Governance Considerations Beyond Technical Controls
Closing these gaps requires more than point fixes to individual MCP servers. Enterprises should establish an internal ownership model for MCP server approval, comparable to existing review processes for third-party APIs and integrations.
Agent permission scopes should map to documented business justification, consistent with least-privilege policies already applied to human identities, rather than being granted broadly for convenience. Incident response plans should treat agent tool-call misuse as a distinct scenario category, separate from traditional application security incidents, since detection and containment paths differ.
Compliance teams should also confirm whether existing access control and change management frameworks are being explicitly applied to agent and tool permissioning. This is a newer control surface that predates most current audit checklists, and it is often outside the scope of existing reviews by default.
Runtime policy enforcement, where tool calls are checked against policy at the point of execution rather than only at design time, is the mechanism that makes these governance commitments operationally verifiable. Trussed AI focuses specifically on this layer, providing runtime governance for agent identity, tool approval, and policy enforcement so that MCP-based deployments can be audited and controlled at the point where tool calls actually execute.
Frequently Asked Questions
What makes MCP security different from standard API security?
Standard API security typically involves a defined caller, a defined endpoint, and a fixed set of parameters validated by a schema. MCP tool-calling introduces a dynamic discovery layer where an LLM selects which tool to call and constructs parameters at inference time. The authorization challenge is that the tool selection is probabilistic and the parameters are generated, which means you cannot rely solely on schema validation or perimeter controls designed for deterministic API callers. Runtime enforcement at the execution boundary is necessary to compensate for this difference.
Why is registration-time configuration insufficient?
Registration-time configuration documents what a tool is intended to do and may set coarse permissions during setup. However, it does not validate the actual parameters passed at each invocation, does not account for context changes across a session, and does not constrain agent identity at the point of execution. A tool registered with narrow declared scope can still be called with parameters that exceed that scope if there is no runtime check enforcing the boundary. Registration-time controls establish intent; execution-time controls enforce it.
How should agent identity be scoped in practice?
Agent identity should be issued for the specific task or workflow, not for the duration of the host application session. Each agent process should hold credentials limited to the tools and resources it needs to complete its assigned task. When a new task begins, a new scoped identity should be issued rather than reusing the prior session context. This is analogous to short-lived, scoped tokens used in human identity workflows and follows the same least-privilege rationale.
What should execution-level audit logs capture?
Execution-level logs should record the tool called, the agent identity that called it, the parameters passed, the time of the call, the result or error returned, and any authorization decisions made at runtime. Logs captured only at the orchestration layer miss the execution detail needed for post-incident analysis and compliance review. Logs should be tamper-evident and retained according to the same policy applied to other access control audit records.
How does Trussed AI address these gaps?
Trussed AI provides runtime governance specifically for agent identity, tool approval, and policy enforcement in MCP-based deployments. Rather than relying on registration-time configuration or orchestration-layer controls alone, Trussed AI enforces policy at the point where tool calls actually execute, making governance commitments operationally verifiable and audit-ready. This applies to both single-server deployments and multi-agent topologies where each trust boundary must be independently enforced.