When is one control plane preferable to separate agent gateways?

Why One Control Plane Wins When Agents Need Both Models and Tools

A single control plane is usually the better fit when the same agent must decide, in one transaction, whether to call a model, invoke a tool, or hand work to another service. Separate gateways can still work, but they often split policy, logging, and enforcement in ways that make governance slower and incident review harder. The more the agent behaves like a governed actor, the more a unified plane helps.

That matters because control is not just about routing traffic. It is about keeping one policy decision, one access path, and one record of what the agent was allowed to do. In practice, that makes it easier to answer a simple question later: was the model call, the tool call, and the resulting action all authorised under the same decision?

A single plane is also the cleaner design when policy needs to follow the AI Agent Authorisation Guide principle of task-scoped access. If an agent can reach multiple capabilities, the control point should be able to evaluate the full request context, not just a fragment of it at different boundaries.

What Separate Gateways Make Harder

Separate agent gateways are not wrong. They are preferable when the model boundary and the tool boundary are genuinely different trust zones, such as when one path must be exposed externally while another stays internal. The trade-off is that policy can become inconsistent if each gateway makes its own local decisions, especially when a single agent action spans both paths.

That split creates practical problems for auditability. If the model call is logged in one place and the tool invocation in another, reconstruction depends on stitching together IDs, timestamps, and context that may not line up cleanly. The same issue appears when approvals, retries, or fallback behaviour are handled in different layers.

It also increases the chance of policy drift. One gateway may enforce a stricter identity check, another may allow broader delegation, and neither layer by itself has the full picture. In environments with shared prompts, shared tools, or reusable agent workflows, that inconsistency is often more dangerous than the extra hop.

A control plane approach is easier to defend when you need one timeline for observability and incident response, as described in the AI Agent Observability, Audit and Incident Response Guide. When one decision path governs both model and tool activity, attribution and replay become much more reliable.

Where the Boundary Still Belongs: When Separation Is Justified

Separate gateways make sense when the architecture has materially different security domains, different owners, or different lifecycle rules. For example, a model gateway may need enterprise-wide policy and cost controls, while a tool gateway may need stronger environment-specific checks, approval gates, or data loss controls. If the two layers truly enforce different responsibilities, separation can reduce accidental coupling.

That design choice becomes more attractive when the tool side has direct side effects and the model side does not. In those cases, the gateway closer to the side effect should hold the stronger enforcement, because that is where least privilege and approval logic matter most.

For teams still deciding how much autonomy to allow, the useful comparison is often not gateway versus no gateway, but unified policy versus fragmented policy. The Zero Trust for AI Agents guidance fits this decision well: verify the principal, the request, and the action at the point of use, then remove standing privilege wherever possible.

Risk and Threat Considerations

The main risk with separate gateways is not simply complexity, it is control bypass through inconsistency. If one gateway trusts a token, context, or approval state that the other does not recognise, an attacker or buggy agent flow can exploit the mismatch to get an action through a weaker path.

Failure mechanism: policy decisions split across gateways can create gaps in identity, authorization, logging, or replay handling, especially when a single agent action depends on both model output and downstream tool execution.

Impact: you can lose end-to-end auditability, misattribute actions, or allow a broader effective privilege than either gateway intended. In a compromise, that makes containment and incident reconstruction slower and less reliable.

Practitioner Guidance

What to verify: If the same agent can both reason and act, confirm that one control plane can enforce the policy for the full action path, including approvals, tool scope, and logging. If you cannot reconstruct the full decision from one trace, the design is probably too fragmented.

Decision rule: Use a single plane when the security question is “may this agent do this now?” and use separate gateways only when the answer genuinely differs by boundary, owner, or trust zone. If the decision is still one decision operationally, splitting the enforcement layer usually adds friction without adding safety.

What practitioners underestimate: separate gateways often look cleaner on an architecture diagram than they are in an incident review. The practical test is whether you can prove, after the fact, why the model call and the tool call were both allowed, and whether the same trace explains both.

Practitioner takeaway: prefer one control plane whenever the agent’s model use and tool use are part of the same governed action, because shared policy and shared evidence usually matter more than gateway separation.

Related resources from NHI Mgmt Group

• When do NHI access reviews create more value than a one-time cleanup?
• Why is single-provider AI agent governance not enough for enterprise security?
• How can organisations reduce the blast radius of compromised agent identities?
• Where does cross-environment agent discovery fit in an IAM programme?