APISIX and Archestra split gateway and agent duties cleanly

At a glance

What this is: This is an analysis of how APISIX and Archestra divide AI gateway and agent-layer responsibilities, with the key finding that gateway controls stop short of governing agent turns and tool use.

Why it matters: It matters because teams building AI and agent stacks need to place identity, authorization and audit controls at the layer where decisions and tool calls actually happen, not only at the request edge.

Context

Enterprise teams that add agents to an existing AI gateway often discover that the request boundary is not the same as the decision boundary. APISIX can validate traffic at the edge, but once an agent begins selecting tools and routing work, the governance problem shifts into identity-aware execution.

The practical question is not whether one layer can do everything. It is whether the stack separates gateway duties from agent duties in a way that preserves least-privilege agent access and keeps auditability tied to the actor that actually made the decision.

Key questions

Q: What breaks when AI agent governance is handled only inside the application rather than at the gateway?

A: When governance sits only inside the application, controls are easier to bypass, audit trails fragment, and policy enforcement becomes inconsistent across agents and tools. That creates blind spots for access review, incident investigation, and compliance. A gateway-level control point is more resilient because it can see traffic before it reaches models or external services.

Q: Why do gateway logs fail to explain unsafe agent behaviour?

A: Gateway logs show that a request arrived and was forwarded, but they do not capture the agent’s internal choice of tools, the identity context that shaped the choice, or the influence of intermediate model output. Without those details, investigators cannot distinguish harmless automation from delegated misuse.

Q: When should teams split AI gateway and agent governance into separate layers?

A: Teams should split them when the system does more than proxy prompts and begins making tool decisions, calling MCP servers or acting on behalf of a user. At that point, the edge gateway remains useful, but it is no longer sufficient on its own. The agent layer needs its own identity, authorization and audit controls.

Q: What is the difference between request authorization and delegated tool authorization?

A: Request authorization decides whether traffic may enter the system. Delegated tool authorization decides whether a specific identity may perform a specific action through an agent after the request has already been accepted. The first is a perimeter control; the second is an action control, and both are needed when agents operate on behalf of users.

Technical breakdown

Why a gateway cannot govern an agent turn

An API or LLM gateway is built to inspect requests, enforce policy, and forward traffic. An agent turn is different because the system may decide which tools to call, in what order, and with what context. That means the relevant control point is no longer just the inbound request. It is the decision path that leads from model output to tool invocation, including identity binding, consent, and traceability across multiple downstream systems.

Practical implication: Put governance controls where tool choice occurs, not only where traffic enters the stack.

How identity-aware tool routing changes the trust model

Identity-aware tool routing means access is not merely authenticated once at the edge. The platform also resolves which user, agent, or delegated session is allowed to touch which tools, and under what conditions. This changes the trust model from perimeter validation to per-action authorization. In practice, it is the difference between allowing a request through and allowing a specific delegated action to happen on behalf of a specific identity.

Practical implication: Treat delegated tool use as a separate authorization decision from initial login or API access.

Why audit trails need decision context, not just request logs

Traditional gateway logs tell you that a call was made, how long it took, and which upstream it hit. Agent governance requires more: the decision taken, the tools selected, the identity behind the call, and the provenance of any model or tool output that influenced the next action. Without that context, incident review cannot reconstruct whether a result was benign automation or an unsafe delegated action. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Record decision-level telemetry if you need defensible review of agent behaviour.

Threat narrative

Attacker objective: The objective is to induce an agent to carry out an unintended action or tool call while preserving the appearance of a valid, authenticated request.

1. Entry occurs through a legitimate gateway request that is correctly authenticated at the edge but does not yet reveal the downstream agent decision path.
2. Escalation happens when the agent selects tools, consumes untrusted output, or routes work to an MCP server without sufficient identity-bound constraints.
3. Impact follows when the agent performs an authorised-looking action that exceeded the effective scope of the original request, leaving the request log without the full behavioural context.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Gateway controls and agent controls solve different problems: APISIX-style edge enforcement handles transport, request routing and coarse policy, but it does not govern the full agent decision path. Once an AI system begins choosing tools, the security question changes from request acceptance to delegated action control. That distinction matters because identity governance cannot stop at the edge of the conversation.

Identity-aware tool routing is the real control boundary: The article describes a stack in which the agent layer resolves which identity can use which tools, while the gateway continues to manage traffic and provider calls. That separation is the right architecture for open-source-first shops, because it places authorization where the action occurs rather than where the request arrives. Practitioners should treat tool routing as a governed identity problem, not a routing convenience.

Decision-level audit is the named concept that closes the gap: A request log is not enough when an agent can chain tool calls, consume untrusted output and continue operating within the same session. The useful concept here is decision-level audit, where the record captures the identity, the selected tool, the upstream model output and the resulting action. That is the minimum evidence needed for defensible review of agent behaviour.

Open-source composition is a governance choice, not just a licensing preference: The appeal of the APISIX and Archestra pairing is not only that both projects are open source. It is that the stack keeps gateway policy, model proxying and agent governance in separate layers with distinct control objectives. That reduces pressure to overload the gateway with agent problems it was never designed to solve.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Authorisation Guide

What this signals

Decision-level control will become the differentiator in agent stacks: As more organisations combine gateways with agent platforms, the question shifts from whether traffic is allowed to whether a delegated action is valid. That makes identity-aware tool routing and decision logging part of the core control plane, not an optional enhancement.

The practical implication for platform teams is that open-source composition will be judged by whether it preserves clear separation between request enforcement and action governance. Teams that blur those layers will struggle to explain agent behaviour, assign accountability, or defend scope boundaries when tools are introduced later.

For practitioners

• Separate gateway policy from agent governance Use the edge gateway for OIDC, rate limits, traffic shaping and provider fan-out, but move tool authorization, delegated action approval and identity-bound audit into the agent layer.
• Bind tool access to the calling identity Map each human or workload identity to the exact tools, MCP servers and delegated scopes it may use, rather than assuming a validated request is enough.
• Log decision context, not only request metadata Capture the selected tool, resolved identity, upstream model response and resulting action so review can reconstruct why the agent acted.
• Test the stack boundary before production rollout Validate that a gateway-only path cannot silently expand into agent execution, and confirm that untrusted tool output cannot influence downstream actions without explicit controls. Read Threat Modelling AI Agents.

Key takeaways

• APISIX can govern the edge of an AI request, but it cannot by itself govern the full agent decision path once tools and delegated actions enter the picture.
• The article’s core operational insight is that identity-aware tool routing and decision-level audit belong in the agent layer, not only in the gateway.
• Teams adopting agents on top of an existing gateway should separate request control from action control before production use, or they will create a governance gap at the point of execution.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Threat Modelling AI Agents · LLM Provider API Key Security and LLMjacking Guide

Key terms

• Agent Turn: A single end-to-end cycle in which an AI agent receives input, reasons, calls tools, and returns output. For security evaluation, the turn is more useful than the event because it captures the full amplification effect of multi-step reasoning and repeated tool use.
• Identity-Aware Routing: A routing model that decides whether traffic may reach a private resource based on the authenticated identity and policy context. In this pattern, the network path is not the trust boundary; entitlement and session policy are, which makes internal access auditable and scoped.
• Decision-Level Audit: A log and review model that records not just that a request was made, but why a system chose a tool, which identity was involved, and what action followed. For agentic systems, this is more useful than request-only logging because it preserves the decision context behind the action.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.