How can organisations decide whether to route agent tool traffic through a gateway or allow direct connections?

Why This Matters for Security Teams

Routing agent tool traffic is not just an architecture preference. It determines where identity is asserted, where policy is enforced, and where evidence is recorded when an agent calls shared tools, data stores, or regulated systems. With autonomous workloads, direct connections can look efficient at first, but they often remove the one place security teams can reliably inspect intent, redact sensitive fields, and revoke access quickly.

This is especially important in MCP-style environments, where tool access can expand faster than teams expect. NHIMG research on the Astrix Security findings showed that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why unmediated paths become difficult to govern. The risk is not only exposure, but also drift: once agents are allowed to connect directly, each new integration tends to inherit its own credentials, logging gaps, and exception handling. Current guidance from OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework supports designing controls around runtime risk rather than trusting static connectivity alone. In practice, many security teams discover the weak path only after an agent has already been granted broad tool reach.

How It Works in Practice

A gateway is the better pattern when a team needs central control over identity, scoping, logging, redaction, and policy enforcement. It acts as a mediated trust boundary between the agent and the target tool. That allows the system to inject short-lived credentials, translate the agent’s workload identity into tool-specific permissions, and evaluate each request against context such as tenant, task, data class, and environment.

Direct connections can still be justified for narrow, low-risk integrations, but only when the blast radius is small and the identity model is already mature. For example, a single-purpose internal agent with one read-only API may not need a full brokered path. Even then, the safer pattern is to rely on workload identity and short-lived tokens, not static secrets. That aligns with the direction described in the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, which both emphasize governance, traceability, and risk-based controls.

In practice, gateway-mediated routing usually includes:

• Workload identity for the agent, so the system knows what the agent is rather than trusting a shared secret.
• Just-in-time credential issuance with short TTLs and automatic revocation after task completion.
• Policy-as-code evaluation at request time, using context rather than pre-approved blanket access.
• Field-level logging and redaction for prompts, tool arguments, and returned data.
• Rate limits and tool scoping to reduce lateral movement and tool chaining.

This is where NHIMG’s guidance on the Ultimate Guide to NHIs — 2025 Outlook and Predictions remains relevant: organisations still struggle with excessive privileges, weak rotation, and poor visibility across non-human identities. Gateway controls help close that gap by making every call observable and revocable. These controls tend to break down when agents must operate across highly fragmented legacy systems that cannot support consistent identity propagation or request-time policy checks.

Common Variations and Edge Cases

Tighter gateway control often increases latency, integration effort, and operational overhead, requiring organisations to balance stronger oversight against delivery speed and developer friction. That tradeoff is real, especially for event-driven agents, high-throughput pipelines, or internal automation that depends on many low-value calls.

Best practice is evolving, and there is no universal standard for when a gateway becomes mandatory. Current guidance suggests a gateway when any of the following are true: multiple agents share the same tool, the tool touches regulated or high-impact data, the agent can chain actions across systems, or the organisation needs consistent auditing and redaction. Direct connectivity is more defensible when the tool is low risk, the agent is tightly bounded, and the credential can be issued per task with strict expiry.

Teams should be cautious with exceptions. A direct path that starts as a temporary workaround often becomes the permanent path, especially in production. That is why many security programs now treat gateway routing as the default for agentic workflows and direct connections as an exception that needs documented review. The OWASP Agentic Applications Top 10 and the MITRE ATLAS adversarial AI threat matrix both reinforce the need to assume dynamic abuse paths, not fixed request patterns. In practice, direct links remain most fragile in environments where secrets are long-lived, tool inventories change quickly, and no single team owns the full agent-to-tool trust chain.

Related resources from NHI Mgmt Group

• How should security teams decide whether JIT access is safe for non-human identities?
• How can organisations decide whether to buy a standalone red teaming tool or a broader platform?
• How do organisations decide whether an AI agent should be allowed to act autonomously?
• How do organisations decide whether an AI agent needs NHI controls, AI controls, or both?