When AI Agents Bypass the Gateway, Can Runtime Security Still Backstop Them?

An Overlooked Architectural Crack: When Sub-Agents Hold API Keys

A developer on Reddit raised a strikingly sharp question: If AI Agents can bypass the Gateway, does Runtime Security still matter?

His hypothetical scenario isn't complicated. A gateway inspects every tool call, checking against task-level permissions, read budgets, and approval policies. This mechanism works well on the normal path. The problem arises when a sub-agent directly obtains an API key and bypasses the gateway to call underlying services. At this point, the policy itself isn't wrong—what's wrong is that the enforcement boundary has disappeared.

The core of this vulnerability isn't about whether "the policy is written correctly," but about "where the policy is enforced." If the enforcement point can be skipped, even the most fine-grained permission controls are just decoration.

The Gateway Isn't a Security Boundary—It's Just Part of the Orchestration Layer

Many Agent frameworks design the gateway as a security hub. All tool calls pass through the gateway, which handles authentication, auditing, and rate limiting. This centralized approach performs well in single-agent scenarios.

But once a system evolves to include sub-agents, mixed frameworks, and self-hosted runtimes, the gateway's coverage becomes fragile. Sub-agents can establish their own HTTP connections, use keys from environment variables to directly call external APIs, or spawn local processes that the orchestrator never sees. None of these paths go through the gateway.

The original poster followed up with several key questions: Should agents have direct provider credentials? In self-hosted environments, if you can't fully control the Agent runtime, how do you enforce that all tool access goes through the gateway? Is implementing controls framework-by-framework a reasonable fallback, or does it create a false sense of security?

These questions point to the same conclusion: The gateway is part of the orchestration layer, but it is not the security boundary itself. Treating the gateway as the only line of defense means betting security on the assumption that "all calls will obediently go through this path."

Credential Management Is the Real Boundary

If I were to answer the original poster's first question: Agents should not directly hold provider credentials. This is currently the most controllable boundary design.

The approach can be layered. Short-lived credentials are dynamically issued through STS or similar mechanisms, bound to specific tasks and sessions, and expire when no longer valid. A Credential Broker holds long-term keys on the gateway side, exchanges them for short-term tokens when agents request them, and sub-agents never see the long-term keys. Network-layer constraints restrict outbound traffic to only allow runtime access to the gateway address, blocking the ability to directly connect to external APIs.

The core logic behind these measures is consistent: remove credentials from the Agent process and place them where the Agent cannot directly read them. As long as credentials aren't in the Agent's hands, bypassing the gateway becomes moot.

The author, while building the open-source runtime security project AegoTrax, is clearly thinking about similar problems. He mentioned wanting to understand architectural approaches that don't rely on a centralized gateway, which shows he's aware of the single-point gateway's limitations.

STS (Security Token Service) is a service that issues temporary, limited-permission credentials on demand, with AWS STS being a typical example. Its core value lies in: the caller uses a long-term identity (such as an IAM role) to exchange for a set of temporary credentials from STS, typically valid for 15 minutes to several hours, with built-in expiration times and permission scopes. For Agent scenarios, this means that even if temporary credentials are stolen, the attack window is compressed to minutes, and permissions are confined to a specific task scope.

Credential Broker is an architectural extension of this idea: it acts as a trusted intermediary holding long-term keys, so the Agent never touches the original credentials and can only obtain short-term tokens exchanged by the broker on a per-task basis, with all exchanges logged for auditing. This effectively transforms "who can use the key" into "who can obtain a token through the broker," shifting the boundary from process memory to a controlled service.

The Dilemma of Self-Hosted Environments and Pragmatic Trade-offs

Self-hosted environments are the trickiest scenario for this problem. You can't fully control the Agent runtime—users might use any framework, any language, any deployment method. The gateway's enforcement power then depends on how cooperative the user is.

Implementing controls framework-by-framework is a common fallback. Intercept tool calls at the framework level (LangChain, CrewAI, AutoGen, etc.) and perform permission checks. But this approach has an obvious problem: it creates framework-level security, not system-level security. If the user switches frameworks, writes a custom tool, or directly calls the requests library, the controls fail.

A more pragmatic path might be: network isolation at the operating system or container level, combined with credential brokers and short-term tokens. This way, even if the framework layer is bypassed, the network layer can still block it. The cost is increased deployment complexity and demands on the self-hosted user's operational capabilities.

When the original poster asked "Is framework-by-framework enforcement reasonable," my judgment is: it can serve as an auxiliary layer, but not as the primary defense. It's suitable for development-phase warnings and auditing, but not for production-environment enforcement boundaries.

Network isolation at the operating system or container level is typically implemented using Linux's eBPF or iptables/nftables: the former can attach programs in kernel space for fine-grained filtering of process-level outbound connections, even identifying DNS queries; the latter uses rule tables to only allow traffic directed at the gateway address, dropping everything else. Both can provide backstop protection when the framework is bypassed, but both require root privileges or dedicated container runtimes (such as gVisor, Firecracker).

For self-hosted users, this means security responsibility shifts from "framework configuration" to "infrastructure configuration." If users use Docker, outbound traffic can be restricted through network policies and custom bridges; if in Kubernetes, NetworkPolicy can be used. The choice depends on how much operational complexity the user is willing to bear—which is the fundamental reason why self-hosted security is always difficult to achieve "out of the box."

Architectural Choices: The Trade-off Between Centralized and Decentralized

The original post mentioned wanting to understand architectures that don't rely on a centralized gateway. This direction is worth expanding on.

Decentralized approaches typically use the sidecar pattern: a security proxy runs alongside each Agent process, with all outbound traffic passing through the sidecar. The sidecar handles credential injection, policy checks, and audit logging. This eliminates the need for a central gateway, but each Agent instance requires a corresponding sidecar, shifting operational costs to the deployment layer.

Another approach is the Capability Token model. The Agent doesn't hold API keys, but rather a signed capability token declaring "this token allows calling interface Y of service X, valid for N minutes." The server verifies the token signature and scope. Tokens are generated by a trusted issuance service and cannot be forged by the Agent. In this model, the gateway may not exist—the boundary is carried by the token itself.

Both approaches have their costs. Sidecars increase deployment complexity, while capability tokens require server-side modifications. Which to choose depends on how much control you have over your existing infrastructure.

The Sidecar pattern originates from the classic design of Service Mesh—in projects like Istio and Linkerd, each business Pod has a proxy container attached, and business traffic is transparently hijacked to the sidecar before going outbound. When migrated to Agent scenarios, the sidecar takes on not just mTLS and load balancing, but credential injection, tool call policy validation, and auditing. The benefit is that the Agent process is completely unaware and no business code changes are needed; the cost is that each Agent instance requires a corresponding sidecar—acceptable in Kubernetes, but a noticeable operational burden in bare-metal or local development environments.

Capability Token thinking can be traced back to unforgeable, self-contained authorization credentials like Macaroons and JWTs. The token itself encodes "what can be done" (interface Y of service X), "how long it's valid," and "who issued it." The server only needs to verify the signature and scope to grant access, without querying back to a central gateway. This allows authorization decisions to flow with the token, naturally fitting decentralized architectures.

No Silver Bullet, But There Are Priorities

Back to the original question: Can runtime security protect Agents that can bypass the gateway?

The answer depends on how you define "runtime security." If it's just a piece of policy code inside the gateway, then no. If it's a defense-in-depth system covering credential management, network isolation, and token issuance, then yes, it can backstop.

The priority order is roughly: credentials never land in the Agent process—this is the first and most important line; network-layer outbound restrictions—this is the second line; framework-layer interception and auditing—this is the third line, used to detect anomalies rather than prevent them.

The original poster's AegoTrax project is attempting to explore in this direction, and open-source community discussion on runtime security is still in its early stages. If you're designing an Agent system, I suggest first answering one question: Whose hands are your credentials in? The answer to this question determines your system's real security boundary far more than how finely crafted your gateway policies are.

One-line Summary

The gateway isn't the real boundary of Agent security—credential management is what determines the system's actual security.

Paragraph Summary

Starting from a developer's question on Reddit: If AI Agents can bypass the gateway, does runtime security still matter? The author points out that the gateway is merely an orchestration layer component, not a security boundary, and sub-agents can bypass it to directly call external services with API keys. The real boundary lies in credential management—agents should not hold long-term credentials but should obtain short-term tokens through STS or credential brokers, combined with network-layer outbound restrictions to form defense in depth. Framework-level permission interception only creates a false sense of framework-level security and cannot cover custom tools and direct requests. The article also explores sidecar patterns and capability token models as decentralized alternatives, and provides priorities: credentials never landing > network-layer isolation > framework-layer auditing. Finally, it returns to the core question: Whose hands are your credentials in?