By NHI Mgmt Group Editorial TeamBased on Akto: “MCP Proxy: Security, Observability and Governance of Enterprise AI” (December 4, 2025)

TL;DR: MCP proxies place a policy and audit layer between AI agents and tools so requests can be routed, validated, logged, and blocked before execution, according to Akto. That matters because agentic workflows expand the blast radius of prompt injection, unauthorized tool access, and data exfiltration faster than conventional IAM assumes.


At a glance

What this is: This article argues that MCP proxies are becoming the control plane for AI agents by enforcing policy, routing, logging, and blocking between agents and tools.

Why it matters: IAM, PAM, and NHI teams need to treat agent-to-tool traffic as a governed access path, because control now depends on what happens before execution, not after.


Context

MCP proxy governance is the problem space here, not just a product pattern. The article describes a middleware layer that sits between AI agents and MCP servers to validate requests, enforce policy, translate protocols, and log interactions before tool execution.

For identity teams, the important shift is that agent access is no longer only about who can authenticate. It is about whether every tool call is authorised, inspected, and attributable at runtime across a fast-changing agentic workflow.

That makes the proxy behave like an enforcement plane for non-human identity in agentic systems. Once agents can dynamically choose tools and data sources, conventional access reviews and static entitlements no longer describe the real control boundary.


Key questions

Q: What breaks when AI agents can call backend tools directly?

A: Direct tool access collapses the boundary between model output and enterprise action. Once an agent can reach raw APIs, schemas, or databases, prompt injection and malformed tool calls become operational risks instead of contained errors. The practical failure is loss of policy enforcement at the point where execution actually happens.

Q: Why do MCP proxies matter for governance and compliance in agentic AI?

A: They create a record of what the agent requested, what the system allowed, and what was blocked. That makes auditability and accountability possible when regulators, customers, or internal reviewers ask how an agent was controlled. Without that evidence, governance claims are hard to defend because the execution trail is incomplete.

Q: How can security teams tell whether agent access is actually under control?

A: Look for evidence that the team can trace every tool call, secret use, and cross-system action back to a named owner and a valid approval path. If an agent can reach messaging, browser, and infrastructure tools without a revocation chain, access is not truly governed. Control exists only when the runtime can be stopped as fast as it can act.

Q: What is the difference between agent authentication and MCP proxy enforcement?

A: Authentication answers who the agent is, while proxy enforcement decides what that agent can do with each request. An authenticated agent can still be unsafe if it can reach tools, data, or external services outside policy. The proxy turns identity into actionable control at runtime instead of static access alone.


Technical breakdown

How an MCP proxy becomes the enforcement point for agent-to-tool traffic

An MCP proxy sits between an AI client and MCP servers, acting as the single path for requests, responses, routing, and logging. In practical terms, it is not just a relay. It can validate a request, apply policy, translate between transport protocols such as HTTP, SSE, and STDIO, and then decide whether the interaction is forwarded or blocked. That makes it closer to an identity-aware control plane than a simple gateway, because the decision happens before tool execution, not after the fact.

Practical implication: Treat the proxy as the authoritative control boundary for agent access, not as an optional observability layer.

Why prompt injection turns into tool abuse without proxy enforcement

Prompt injection becomes operationally dangerous when an agent can turn malicious instructions into tool calls with no policy checkpoint. The proxy changes that by scanning input, evaluating context, and applying guardrails before the request reaches the server. That matters because the threat is not only bad text, but unauthorised action taken by a legitimate agent identity. Once the proxy is absent, the attack path moves from manipulated language to direct execution against APIs, databases, and internal systems.

Practical implication: Use the proxy to separate instruction intake from execution rights so malicious prompts do not become tool actions.

Why audit trails matter more when AI agents can act across many tools

Agentic systems do not fail in one place. They create distributed activity across multiple servers, APIs, and data sources, which makes traceability a control requirement rather than a reporting feature. A proxy that logs each request, response, and policy decision gives teams a record of what the agent asked for, what was allowed, and where the interaction stopped. Without that record, investigations become guesswork and compliance evidence is weak. Observability is therefore part of runtime governance, not an afterthought.

Practical implication: Preserve request-level logs that tie every tool action back to the agent, context, and enforcement decision.


Threat narrative

Attacker objective: The objective is to make a legitimate AI agent perform unsafe tool actions that leak data or widen access without detection.

  1. Entry occurs when a malicious prompt or unsafe instruction reaches an AI agent and attempts to influence downstream tool selection.
  2. Escalation occurs when the agent can convert that instruction into an unauthorized tool call because no proxy layer validates the request first.
  3. Impact follows when the tool call exposes sensitive data, performs an unintended action, or sends information to an external service without inspection.
  • SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
  • Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

MCP proxy governance is becoming the practical control plane for agentic identity. Once agents can choose tools dynamically, the control point moves from the application boundary to the request path itself. That is a governance shift, not a deployment detail. Security teams should stop treating tool access as a static entitlement problem and start treating it as a runtime enforcement problem.

Prompt injection is only half the problem; tool-authorised execution is the real failure mode. The article shows why filtering prompts alone is insufficient when the same request can become an API call, a data lookup, or an outbound transfer. The critical issue is not what the agent read, but what the system allowed it to do next. Practitioners need to frame agent risk in terms of action control, not content moderation.

Agent access review becomes weaker when execution is faster than governance cadence. Traditional IAM assumes access can be granted, reviewed, and revoked as a relatively stable state. Agentic workflows can create and consume access within the same session, so the review artefact may never exist long enough to certify. The implication is that governance has to move closer to issuance and request-time policy.

Structured communication is now a security requirement, not a protocol preference. The MCP layer is only useful as a control plane if every agent interaction is forced through it. Otherwise the architecture devolves into direct-to-tool sprawl, where logs are incomplete and policy is bypassable. That means identity teams, platform teams, and security architects need a shared governance model for MCP routing, authentication, and audit scope.

Identity blast radius is the right named concept for MCP proxy design. The proxy is doing more than routing traffic, it is reducing the amount of damage one agent identity can cause across multiple tools and contexts. That matters because agentic systems amplify privilege faster than conventional application patterns. Teams should measure how far a single agent can reach before proxy enforcement stops the chain.

From our research library:

What this signals

Identity blast radius is the emerging design metric for agentic systems. When an AI agent can reach multiple tools through one control point, the real question is how far one compromised request can travel before policy stops it. That shifts governance away from isolated authentication checks and toward path control, request inspection, and revocation at the proxy layer.

Access reviews designed for stable accounts do not fit agentic workflows that can acquire and consume permissions inside a single session. The practical programme change is to govern issuance, tool scope, and audit capture at request time, because waiting for a periodic review leaves the dangerous part of the workflow invisible.


For practitioners

  • Define the MCP proxy as the runtime policy boundary Place all agent-to-tool requests behind a mandatory proxy path so validation happens before execution and direct server access is not possible.
  • Map every tool call to an agent identity and context Require request-level identity, role, and purpose data on each interaction so policy decisions are tied to the specific agent action.
  • Block unsafe requests before protocol translation Validate prompts and parameters at the proxy layer, then reject requests that attempt sensitive file access, data exfiltration, or unapproved tool use.
  • Keep immutable audit logs for agent actions Record request, response, policy decision, and outcome data so investigations and compliance evidence can reconstruct every tool interaction.
  • Restrict tool permissions by agent role Assign only the minimum tool scope needed for the agent's function, and revoke or reissue permissions centrally as workflows change.

Key takeaways

  • MCP proxies move governance closer to execution by enforcing policy before an agent reaches a tool or API.
  • Without that control point, prompt injection and unsafe tool calls can turn into authorised-looking actions with little visibility.
  • Practitioners should govern agent identity at request time, not assume conventional IAM review cycles will capture the real risk.

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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Agentic AI Top 10ASI02Tool misuse is the central risk when agents reach tools through MCP.
Recommendation — Apply ASI02 controls to block unsafe agent tool calls at the proxy boundary.
OWASP Non-Human Identity Top 10NHI-04MCP proxy authentication governs how non-human identities reach tools.
NHI-05The article centers on limiting agent scope to reduce blast radius.
Recommendation — Use NHI-04 controls to validate agent identity before any tool request is forwarded. Enforce NHI-05 to keep agent privileges limited to the minimum tool set they need.
MITRE ATT&CKTA0006;TA0010Prompt-influenced tool abuse here maps to credential access and exfiltration outcomes.
Recommendation — Map unsafe tool paths to TA0006 and TA0010 so detections focus on access abuse and leakage.
NIST CSF 2.0PR.AA-05Proxy policy enforcement is an access-permissions problem for agent identities.
Recommendation — Apply PR.AA-05 to govern which tools each agent identity can reach.

Key terms

  • MCP proxy: An MCP proxy is a middle layer that sits between an AI agent and MCP servers, forwarding requests, enforcing policy, and often logging activity. In technical terms, it mediates Model Context Protocol traffic, can normalize tool calls and responses, and helps control authentication, authorization, auditing, and data exposure across connected resources.
  • Agentic AI Identity: The complete set of credentials, permissions, and governance controls applied to an autonomous AI agent, covering authentication, authorisation, action logging, and access revocation. Distinct from traditional NHI because agent identities are often ephemeral, delegated, and multi-hop.
  • Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
  • Tool-Level Guardrails: Tool-level guardrails are built-in controls that restrict what an AI agent can do through connected tools. They limit dangerous actions, enforce scope boundaries, and reduce misuse even if the model is manipulated. In agent security, these guardrails are a core control because they constrain impact at execution time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org