AI agent control planes expose the limits of proxy-only governance

At a glance

What this is: This analysis argues that AI agent proxies are necessary but insufficient because they control traffic, not the decisions autonomous agents make with tools and data.

Why it matters: It matters to IAM and security teams because agent governance now depends on controlling action, privilege, and data use across the full execution path, not just the entry point.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.

👉 Read Fiddler's analysis of AI agent control planes and proxy-only governance

Context

AI agent control planes address a governance gap that appears once agents can call tools, hand off tasks, and act with real permissions. A proxy can secure the network path, but it does not determine whether the agent should use the data it retrieved, propagate it to another agent, or leak sensitive content into the next step of execution.

For IAM, PAM, and NHI teams, the issue is not simply access approval. It is behavioural oversight across autonomous workflows, where workload identity, tool access, and policy enforcement need to be coordinated. That makes this topic directly relevant to AI agent governance and to any programme trying to extend identity controls into agentic systems.

The article's starting position is typical of many enterprises moving from experimentation to production: they already have a gateway, but they have not yet built a control layer for decisions, outcomes, and auditability.

Key questions

Q: How should security teams govern shared AI agents that can inherit hidden proxy settings?

A: Treat shared agents as imported software with identity, network, and tooling metadata. Review the configuration before reuse, restrict outbound destinations, and require approval for any agent that can relay prompts or files. If you cannot verify lineage and runtime behaviour, keep the agent out of production workflows.

Q: Why do shadow AI agents create a governance gap for IAM and NHI teams?

A: Shadow AI agents create a governance gap because they can hold persistent permissions, act on behalf of users, and connect to corporate data while staying outside normal inventory processes. IAM and NHI teams cannot review, recertify, or offboard what they cannot see. That makes discovery a prerequisite for any meaningful lifecycle control.

Q: What do security teams get wrong about AI control planes?

A: They often treat the control plane as a product choice rather than a trust-boundary decision. The real issue is where identity enforcement, evidence, and secret handling live when agents act on sensitive systems, because that is what determines auditability and containment.

Q: Who should be accountable when an AI agent causes a security incident?

A: Accountability should sit with the human owner, platform team, or business function that granted and operated the agent. The identity may act independently, but governance cannot detach responsibility from the delegation chain. Programs should define ownership, escalation, and remediation paths before deployment so responsibility is clear when the agent's behaviour changes.

Technical breakdown

Why a proxy cannot govern agent decisions

A proxy or gateway is designed to control connectivity. It can route requests, manage API keys, apply rate limits, and block a tool call at the edge, but it does not maintain a model of the agent's intent, the content returned by tools, or the downstream meaning of a decision. That is why traffic-layer controls are necessary but incomplete for agentic systems. Once an agent can use retrieved content to make another call, the security problem shifts from access to behaviour, which requires inspection, evaluation, and policy at the execution layer.

Practical implication: Treat gateway controls as ingress protection, not as the governance boundary for autonomous action.

The data plane, control plane, and MCP path

The article uses the networking split correctly: the data plane is where agents run, while the control plane sets the rules they must obey. In agentic environments, that distinction matters because MCP servers and other tool endpoints create an inbound path that can deliver sensitive data directly into agent context. Existing controls were often built around outbound model calls, so they miss the risk of tool-returned content, prompt injection, and multi-agent propagation. Governance has to span both the request and response path if the organisation wants meaningful oversight.

Practical implication: Map MCP-enabled tool flows separately from model routing and apply policy where content enters and leaves agent context.

Observability before autonomy

The strongest point in the article is that autonomy without observability creates unmanaged decision space. If a team cannot reconstruct what an agent saw, how it evaluated a tool response, and why it chose the next action, then it cannot claim behavioural control. This is especially important in fleets of agents, where one agent's output becomes another's input and a local error can become a systemic one. For agentic AI, governance is no longer a per-request approval pattern; it is a continuous control system with telemetry, evaluation, and auditability.

Practical implication: Build traceability and policy enforcement before expanding agent permissions or allowing multi-agent chaining.

NHI Mgmt Group analysis

Proxy-only governance is a category error for agentic systems. A gateway secures access, but it does not govern the decisions that follow access. Once agents can call tools, consume returned data, and trigger new actions, the relevant control is behavioural oversight across the full execution chain. Practitioners should stop treating routing as governance and start separating transport security from decision control.

AI agent control planes create the identity layer that agent fleets now need. In practice, this is where workload identity, tool permissions, and policy enforcement converge. That intersection matters to IAM and NHI programmes because each agent action is effectively a privileged runtime event, even when the agent is not a human user. The control-plane model is becoming the governance structure for agent identities at scale, and teams should align it with existing identity and privilege controls.

Semantic threats now sit above the access list. Prompt injection, malicious tool output, and cross-agent propagation are not solved by binary allow and deny logic. They require content-aware controls that evaluate what data an agent receives and how it uses it. The named concept here is behavioral governance gap: the blind spot that appears when organisations can authorise a tool call but cannot govern the decision made after the call returns. Teams should frame agent risk in those terms.

Multi-agent systems amplify small governance failures into fleet-wide exposure. When one agent's output becomes another agent's instruction, a compromised or manipulated step can cascade across a workflow without ever breaching the proxy's rules. That shifts the security question from isolated request control to system-level assurance. Practitioners should assume that agent governance must scale at the fleet level, not per individual assistant.

Auditability is becoming a compliance requirement, not a nice-to-have logging function. The article's emphasis on registry, telemetry, and evaluative oversight reflects where AI governance is heading. For identity and security teams, the practical conclusion is clear: if you cannot show policy versioning, decision lineage, and affected data, you do not have defensible control over the agent estate.

What this signals

Behavioral governance gap: agent programmes are now failing at the seam between authorised access and authorised action. The practical response is to treat agent telemetry, policy enforcement, and decision lineage as core controls, not optional observability features. For teams aligning to external standards, the NIST AI Risk Management Framework and the OWASP Agentic AI Top 10 are the right starting points for framing that operating model.

Identity teams should expect agent estates to start looking like high-churn NHI populations, with permissions, tool links, and delegation paths changing faster than manual review cycles can keep up. That makes lifecycle ownership and auditability more important than static approval. The more useful control question is not whether an agent can authenticate, but whether the programme can explain every action it took and every data source it touched.

For practitioners

• Separate routing from governance Keep gateways for transport, rate limiting, and API key handling, but move decision policy, evaluation, and redaction into a distinct control layer that can act before execution completes.
• Instrument MCP tool flows end to end Trace what enters the agent context, what tools return, and what the agent does next so that prompt injection and sensitive-data propagation can be detected across the full path.
• Create an AI agent registry Maintain a single inventory of live, testing, and retired agents with ownership, permissions, connected tools, and policy version so governance decisions are auditable.
• Enforce pre-execution policy checks Apply allow, block, and redact decisions before an agent can use a tool response or hand off to another agent, especially where access to sensitive data or credentials is possible.
• Align agent controls to identity and privilege reviews Review agent permissions the same way you review high-risk service accounts and workload identities, with explicit ownership, scoped access, and recurring reassessment.

Key takeaways

• Proxy controls are necessary but they do not govern autonomous decisions, so they cannot be treated as the full security boundary for AI agents.
• The governance gap is measurable because agent actions, tool returns, and downstream decisions require separate oversight that many programmes still do not have.
• Teams should build behavioural control, identity-grade auditability, and pre-execution policy enforcement before expanding agent permissions at scale.

Key terms

• Agent Control Plane: An agent control plane is the policy layer that decides what an AI agent may do before execution. It connects discovery, identity, and authorization so the organisation can enforce task-scoped limits instead of relying on static registration or after-the-fact review.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Behavioral Governance Gap: The gap that appears when an organisation can authorise an AI agent's access but cannot govern what it does with returned data. It usually shows up as incomplete telemetry, weak decision lineage, or policy that controls transport but not action.
• AI Agent Posture Management: AI agent posture management is the ongoing process of discovering autonomous agents, mapping what they can access, and checking whether their configuration matches policy. It focuses on visibility, ownership, and risk assessment so teams can see where an agent exists and how far its trust reaches.

What's in the full article

Fiddler's full blog post covers the operational detail this post intentionally leaves for the source:

• How the control-plane model maps to request, response, and decision paths in agentic systems
• The five capability areas that Fiddler uses to distinguish governance from routing, including telemetry and auditable oversight
• Examples of production failure modes such as policy drift, down-sampled evaluation, and incomplete audit trails
• How the article frames coding agents, MCP flows, and agent posture management across development and production

👉 The full Fiddler post covers the control-plane model, agent failure modes, and governance patterns across production and coding agents.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners extending identity controls into agentic systems. It helps teams translate identity principles into operational governance for service accounts, machine identities, and AI agents.