Treat bypass paths as separate control planes, not exceptions to ignore. Apply identity, policy, logging, and review controls to direct web access, non-MCP APIs, and in-process calls so that important activity does not disappear outside the governed boundary.
Why This Matters for Security Teams
When agent traffic bypasses the AI gateway, the organisation loses the one place where identity, policy, logging, and review were supposed to converge. That matters because agents do not behave like fixed applications. They can chain tools, call direct web endpoints, and reuse tokens in ways that defeat perimeter assumptions. Guidance from the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework both point to the same reality: runtime governance has to follow the workload, not just the gateway.
This is not just a visibility issue. Bypass paths create a second control plane that often inherits weaker authentication, looser logging, and inconsistent policy enforcement. In NHI Management Group research such as the OWASP NHI Top 10, the recurring failure mode is not that teams lack a gateway, but that they assume the gateway is the whole boundary. The result is blind spots around direct browser use, non-MCP API calls, embedded SDK calls, and agent-to-agent handoffs. In practice, many security teams encounter the breach through a bypass path only after a token, data set, or downstream system has already been exposed.
How It Works in Practice
The first step is to treat bypass traffic as governed traffic. Direct web access, non-MCP APIs, and in-process calls should be assigned identity, policy, logging, and review controls even if they never touch the main AI gateway. That means the agent needs a workload identity, not just an app token, so each request can be tied back to a specific runtime instance or execution context. For agentic systems, current guidance suggests combining short-lived credentials with request-time authorisation rather than relying on static role grants.
In practice, security teams usually need four layers:
- Workload identity for the agent runtime, using cryptographic proof of what the agent is.
- Just-in-time credentials for each task, with short TTLs and automatic revocation on completion.
- Policy-as-code decisions evaluated at request time, so the same action can be approved or denied based on context.
- Centralised logging and review that captures bypass traffic in the same retention and detection pipeline as gateway traffic.
This is why frameworks like CSA MAESTRO agentic AI threat modeling framework and the MITRE ATLAS adversarial AI threat matrix are useful: they push teams toward runtime controls, misuse detection, and threat-informed governance. NHI Management Group also sees the same pattern in the Analysis of Claude Code Security, where tool access and execution paths matter more than the nominal front door. These controls tend to break down when agents are allowed to persist long-lived tokens inside developer machines or unmanaged services because the bypass path becomes the trusted path.
Common Variations and Edge Cases
Tighter control over bypass traffic often increases operational overhead, requiring organisations to balance safety against developer speed and integration complexity. That tradeoff is especially visible in environments where teams have mixed patterns: some actions go through an AI gateway, while others happen in notebooks, service meshes, CI jobs, or embedded workflows. There is no universal standard for this yet, but best practice is evolving toward parity between gateway and non-gateway paths.
One common edge case is in-process calls inside a monolithic application. Those calls may never appear as network traffic, so gateway-centric monitoring misses them entirely. Another is autonomous multi-agent workflows, where one agent hands off tasks to another through a broker, queue, or direct API. In those cases, the control question is not whether the request entered the gateway, but whether the next action was still evaluated against live policy. The CoPhish OAuth Token Theft via Copilot Studio research is a useful reminder that indirect paths can still produce direct compromise.
For teams with mature secrets governance, the operational lesson is the same one highlighted in The State of Secrets in AppSec: strong confidence does not prevent long remediation windows when control coverage is fragmented. Bypass controls should therefore be reviewed as part of the same change-management process as the gateway itself, not as an exception list that grows silently over time.
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, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Agent bypasses expand tool and access abuse paths outside the gateway. |
| CSA MAESTRO | M1 | MAESTRO focuses on runtime governance for agentic systems across control planes. |
| NIST AI RMF | GOVERN | Bypass traffic needs accountable governance and traceable decisions at runtime. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Bypass paths often rely on weak, long-lived secrets and unmanaged credentials. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access must extend to non-gateway workloads and tool calls. |
Replace static credentials with short-lived secrets and revoke them on task completion.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
