Transport mediation gets the request to the server safely. Delegated trust decides whether the agent should be allowed to perform that action for that user in that moment. The first is a network function. The second is an identity and policy function that determines whether the system is governable.
Why This Matters for Security Teams
MCP transport mediation and delegated trust solve different problems, but teams often blur them because both sit around the request path. Transport mediation is about safe delivery and protocol handling. Delegated trust is about whether a model or agent should be able to act on behalf of a user in that moment. That distinction matters because MCP can move requests correctly while still allowing unsafe authority transfer if policy is missing.
This is especially important in agentic systems, where the agent can chain tools, retry actions, and combine context in ways a human operator would not. NHI Management Group’s coverage of the State of MCP Server Security 2025 shows how often MCP environments lack basic scoping, and the problem becomes more serious when identity and policy are treated as transport concerns instead of authorization concerns. For a broader view of agent risk, see the OWASP Agentic AI Top 10.
In practice, many security teams discover the gap only after an agent has already acted with more authority than intended, rather than through deliberate trust design.
How It Works in Practice
Transport mediation is the infrastructure layer. It makes sure the MCP message reaches the server, the session is handled correctly, and the connection is not trivially abused in transit. Think TLS, protocol compliance, routing, and request integrity. It does not answer whether the action is appropriate for this user, this agent, this tool, and this moment.
Delegated trust is the governance layer. It determines whether a user can authorize an agent to act on their behalf, and under what constraints. In practice, that means evaluating intent, scope, time, resource, and tool sensitivity at request time. Current guidance suggests this should be enforced with policy-as-code and identity-aware controls, not assumed from a valid network session alone. The emerging model aligns with the OWASP Top 10 for Agentic Applications 2026 and NHI governance patterns described in the Ultimate Guide to NHIs — What are Non-Human Identities.
- Use transport mediation to authenticate endpoints, protect message delivery, and reduce protocol abuse.
- Use delegated trust to decide whether the agent may perform the requested action for the user right now.
- Prefer short-lived, task-bound credentials and explicit consent boundaries over broad standing access.
- Evaluate policy at runtime, because static role mappings do not capture changing task context.
- Bind the agent to a workload identity so the system can verify what the agent is, not just what token it holds.
Where teams get into trouble is assuming that a trusted transport implies a trusted action. These controls tend to break down when one MCP server brokers access to multiple high-value tools because policy decisions become too coarse to reflect per-action delegated authority.
Common Variations and Edge Cases
Tighter delegated trust often increases operational overhead, requiring organisations to balance user experience against stronger action control. That tradeoff becomes visible in workflows where agents need to complete multi-step tasks, hand off between tools, or ask for consent mid-stream. There is no universal standard for this yet, so best practice is evolving rather than settled.
Some teams implement delegated trust as a one-time user approval, but that is usually too coarse for autonomous systems. Others try to solve it entirely inside the MCP transport layer, which is the wrong abstraction. Transport mediation cannot express whether a spreadsheet export, ticket update, or secret retrieval is allowed under current context. For that, current guidance suggests identity-bound authorization, short TTL credentials, and runtime policy evaluation inspired by the Analysis of Claude Code Security.
The hardest cases are enterprise agents that operate across tenants, inherit user context, or invoke tools with side effects. Those environments need explicit delegated trust boundaries, auditability, and revocation paths. Transport-only protections may still be useful, but they do not make the system governable when the agent can reason across tools and act asynchronously.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Delegated trust is central to preventing overbroad agent action scope. |
| CSA MAESTRO | TR.2 | Separates transport security from agent trust and policy enforcement. |
| NIST AI RMF | GOVERN | Delegated trust needs accountable governance for autonomous AI actions. |
Treat transport as delivery only and enforce agent authorization through runtime governance.
Related resources from NHI Mgmt Group
- What is the difference between an MCP registry and an MCP gateway?
- What is the difference between a prototype MCP server and production MCP infrastructure?
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between human identity governance and AI agent governance?
