A proxy stops being enough when the agent touches real business systems, customer data, or regulated workflows. At that point, the organisation needs runtime authorisation, consent evidence, and identity binding. Transport success alone does not prove the action belonged inside the agent's delegated authority.
Why This Matters for Security Teams
An MCP proxy is useful for mediation, but it is not a production control by itself. Once an agent can reach customer records, payments, source code, or regulated workflows, the question is no longer whether the request passed through a gateway. The question is whether the action was authorised for that exact task, at that exact time, with that exact identity. That is why current guidance increasingly separates transport enforcement from runtime authorisation.
This distinction matters because agentic systems do not behave like static service accounts. They chain tools, change goals mid-session, and can expose secrets or data outside their intended scope. NHIMG research on the State of MCP Server Security 2025 found that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which shows how often proxy-level control is mistaken for governance. The broader risk is already visible in agent deployments, as described in AI Agents: The New Attack Surface report and the OWASP Agentic AI Top 10.
In practice, many security teams discover the gap only after an agent has already taken an action that was technically proxied but operationally out of scope.
How It Works in Practice
For production use, an MCP proxy should be treated as one layer in a broader control plane, not the final decision point. The proxy can inspect transport, normalise requests, and enforce coarse routing, but production systems usually need runtime policy decisions based on the agent’s intent, the requested tool, the data classification involved, and the current session context. That means the access check happens at request time, not just at onboarding.
Practitioners usually add four control layers:
- Workload identity for the agent or tool runtime, so the system can prove what is acting rather than only what secret it holds.
- Just-in-time credentials with short TTLs, so access expires with the task instead of persisting across sessions.
- Policy-as-code for request-time decisions, often using OPA or Cedar, so authorisation can incorporate context such as data sensitivity, destination system, and task purpose.
- Consent and audit evidence, so privileged actions can be traced back to the delegated authority that allowed them.
That model aligns with the direction signalled in the Ultimate Guide to NHIs — The NHI Market and the OWASP Top 10 for Agentic Applications 2026, both of which reflect the shift toward runtime control for autonomous workloads. Current guidance suggests using the proxy to enforce protocol safety and observability, while the real authorisation decision is made by a separate policy engine tied to identity and task context.
These controls tend to break down when legacy business applications only support long-lived tokens or coarse service accounts, because there is no reliable way to bind each action to a short-lived delegated task.
Common Variations and Edge Cases
Tighter runtime control often increases integration cost, so organisations have to balance operational friction against the risk of uncontrolled agent behaviour. That tradeoff is especially visible in mixed environments where some tools are read-only, some are write-capable, and some trigger regulated workflows such as payments, HR, or customer communications.
There is no universal standard for this yet, but best practice is evolving in a few predictable directions. Low-risk internal search may remain proxy-only for a period, while anything that writes to a production system should require context-aware authorisation, explicit approval gates, or ephemeral delegated credentials. In higher-risk environments, the proxy may still be valuable, but only as part of a Zero Trust design rather than as a standalone safeguard.
The biggest edge case is when an MCP proxy creates false confidence because the request path looks controlled even though the agent can still pivot through chained tools, cached credentials, or downstream APIs. That is why agentic governance work now overlaps with Analysis of Claude Code Security and the OWASP Agentic AI Top 10. A proxy is enough only when the agent has no authority beyond low-risk, reversible, and fully observable actions.
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 | Agent tool abuse and runtime authorization gaps are core agentic risks. | |
| CSA MAESTRO | Covers operational guardrails for autonomous agent workflows and tool execution. | |
| NIST AI RMF | Supports governance for context-aware AI risk decisions and accountability. |
Use MAESTRO patterns to separate transport mediation from policy, consent, and runtime enforcement.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
