AI gateway security redefines the control point for agent access

At a glance

What this is: This analysis argues that AI gateways are becoming a central control point for agent access, and that their risk profile is determined by whether they store standing credentials or enforce runtime policy.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to decide whether agent access is governed once at provisioning or continuously at the runtime boundary where every tool call is made.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.

👉 Read Cakewalk's analysis of AI gateway security and runtime agent governance

Context

AI gateway security is the discipline of controlling how applications and agents reach model services, credentials, and downstream tools. In this article's framing, the critical failure mode is not simply exposure on the internet, but a gateway that holds standing access and does not verify each request before forwarding it.

For IAM and NHI teams, the key question is where to enforce policy when model calls, agent actions, and credentials are concentrated in one place. That makes the gateway both a target and a governance boundary, especially when agent access is built around runtime decisions rather than static permissions.

The article's broader point is that many teams are treating AI gateways as plumbing, when they are increasingly identity infrastructure. That is typical of fast-moving agent deployments, and it is exactly where control assumptions start to break.

Key questions

Q: How should security teams govern AI gateways in production environments?

A: Security teams should govern AI gateways like shared control planes, not convenience proxies. That means tying every key, token, and routing policy to an owner, enforcing least privilege for configuration changes, and making logging, retention, and fallback behaviour auditable. The gateway should sit inside IAM, secrets, and incident response processes, not beside them.

Q: Why do standing credentials inside AI gateways create such a large risk?

A: Because the gateway becomes a reusable identity holder. If an attacker reaches the host, they may inherit cloud, model, and downstream application access in one step, which expands the breach far beyond the server itself. Persistent authority inside a gateway also makes it harder to distinguish benign routing from actual privileged action.

Q: What breaks when an AI gateway lacks enterprise governance features?

A: Without enterprise governance, teams often lose auditability, enforceable access control, and consistent policy enforcement. That creates blind spots for compliance, incident investigation, and change control. It also makes it harder to prove who accessed what, when routing decisions changed, or whether sensitive workloads were handled under the right restrictions. Those gaps become serious in regulated environments.

Q: What should teams do when an AI gateway is exposed to the internet?

A: Treat it as a potential identity exposure, isolate it, and review whether it contains cloud credentials, model access, or agent-usable secrets. Then revoke any standing authority that is not required for the current task flow. Internet exposure plus persistent access is the combination that turns a gateway into a breach amplifier.

Technical breakdown

AI gateways vs MCP gateways in agent access control

An AI gateway routes model calls, while an MCP gateway mediates what agents do inside connected applications. The distinction matters because the former mainly brokers access to model services, whereas the latter can become the runtime checkpoint for tool use, credential injection, and policy decisions. When a gateway only forwards requests, it does not change the underlying trust model. When it evaluates each call, it becomes part of identity enforcement rather than just transport.

Practical implication: classify which gateway is carrying credentials versus which is enforcing agent runtime policy before deciding where governance belongs.

Standing access inside gateways creates a high-value identity layer

A gateway that carries an instance profile, API key, or other persistent credential is effectively holding NHI authority on behalf of everything passing through it. If the server is exposed, the compromise is not limited to compute abuse, because the attacker can inherit whatever the gateway can reach. This is why cloud permissions attached to the runtime host are more dangerous than a simple proxy failure. The blast radius is defined by what the gateway can use without further checks.

Practical implication: inventory every gateway credential and remove any permission that survives between calls without a fresh authorisation step.

Runtime governance changes the agent security model

Runtime governance means each tool call is evaluated at the moment of execution, based on policy, context, and the current user or task. In this model, access is not assumed to persist from one action to the next. That matters for AI agents because they may touch multiple systems in a single task, and the security question becomes whether each action is separately governed. The control point shifts from setup-time trust to execution-time decisioning.

Practical implication: move high-risk agent actions behind per-call policy decisions instead of relying on broad, pre-approved session access.

Threat narrative

Attacker objective: The attacker sought to turn a gateway foothold into cloud and model access that could be reused for broader abuse, not just compute theft.

1. Entry occurred when attackers reached an exposed AI gateway that was reachable from the internet and repeatedly targeted with login attempts.
2. Escalation followed because the gateway held standing access to Amazon Bedrock through an instance profile, giving the attacker more to inherit than just the server itself.
3. Impact was limited to cryptomining in the disclosed case, but the same access path also allowed attempted model invocation and AWS user creation, showing how a gateway compromise can extend into identity abuse.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI gateways are becoming identity infrastructure, not just traffic infrastructure. Once the gateway holds credentials, evaluates policy, and fronts multiple model calls, it becomes a governance boundary that IAM and PAM teams cannot treat as a passive relay. The control question is no longer only who can reach the gateway, but what authority the gateway itself is allowed to exercise. Practitioners should classify it as a first-class identity control point.

Standing access inside an AI gateway is a blast-radius multiplier. The Darktrace case shows the problem clearly: a single exposed server carried instance-profile access to Bedrock, which made the compromise worth far more than the compute resource alone. That pattern turns a gateway into a concentration point for cloud identity, model access, and downstream system reach. Practitioners should assume the gateway's stored authority is the real target.

Runtime policy at the gateway is the only control that matches agent behaviour. Agents do not behave like traditional users who request access once and reuse it slowly. They can chain tool calls, change context mid-task, and reach multiple systems before a human review cycle would ever trigger. The implication is that static entitlement governance alone cannot describe the risk surface anymore, especially where autonomous tool use is expanding.

Zero standing access should be the default assumption for AI gateway design. The article's core distinction is between a gateway that holds permanent credentials and a gateway that resolves access only at the moment of use. That difference determines whether a breach exposes a reusable identity asset or a short-lived action path. Practitioners should treat any persistent credential in an AI gateway as a design defect until proven otherwise.

AI gateway governance will increasingly converge with NHI lifecycle controls. Once the gateway mediates access for agents, the same lifecycle questions apply that identity teams already ask of service accounts: who owns it, what it can reach, how it is revoked, and what happens when the business task ends. The field is moving toward one runtime governance layer that must satisfy both security and accountability requirements.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That visibility gap is why OWASP NHI Top 10 matters for runtime governance, not just model safety.

What this signals

With 80% of organisations already reporting AI agents acting beyond intended scope, the governance problem is no longer hypothetical. Identity blast radius: when one gateway concentrates model access, app access, and credential use, the weakest runtime assumption becomes the system-wide failure point. Teams should expect gateway design reviews to move closer to NHI lifecycle review than to traditional API gateway tuning.

The practical change for IAM and PAM teams is that authorization design must follow the call path, not just the login path. A gateway that can inject credentials or approve tool use is already part of the identity plane, so controls like revocation, escalation, and decision traceability need to be tested at runtime, not only in access reviews.

That shift also raises the value of external policy references such as MITRE ATT&CK Enterprise Matrix for mapping adversary behaviour, and OWASP Agentic AI Top 10 for understanding agent misuse patterns.

For practitioners

• Map every gateway-held credential to a named owner Identify whether the gateway stores instance profiles, API keys, or other secrets, then assign a human owner and a revocation path for each one. If the owner cannot explain why the gateway needs persistent authority, remove it.
• Move high-risk agent actions to per-call policy evaluation Require a fresh decision for writes, destructive operations, and external actions instead of allowing a session-wide grant. Use the gateway as the policy enforcement point and deny fail-open behaviour.
• Separate model routing from tool governance Do not assume that an AI gateway that forwards model calls is also the right place to govern application actions. Distinguish model access, app access, and credential injection so each layer has a clear control objective.
• Treat exposed gateway hosts as identity incidents If a gateway host is internet reachable, investigate it like an NHI exposure event, not just a server compromise. Review logs for credential use, attempted model calls, and unexpected cloud user creation.
• Enforce zero standing permissions for agent gateways Design the runtime so no agent or gateway can carry a reusable credential across tasks. If a credential must exist, keep it server-side, scope it narrowly, and rotate or revoke it as soon as the task ends.

Key takeaways

• AI gateways are now identity control points, because they can hold credentials, policy, and access decisions in one place.
• The main breach risk is standing access inside the gateway, which turns a single compromise into cloud, model, and application exposure.
• Runtime governance and zero standing permissions are the controls that match how AI agents actually behave across tool calls.

Key terms

• AI Gateway: A control point that sits between AI applications and the models, tools, or data they call. In practice, it can authenticate requests, enforce policy, inspect runtime behaviour, and stop unsafe actions before they spread into connected systems.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Runtime Governance: Runtime governance is the set of controls that verify what a system or agent is actually doing after deployment. It combines monitoring, authorization checks, and access validation so teams can detect drift, misuse, or excessive privilege in motion rather than assuming build-time policy still holds.

What's in the full article

Cakewalk's full article covers the operational detail this post intentionally leaves for the source:

• The gateway decision flow that separates auto-approve, escalate, and deny paths for agent tool calls.
• The runtime credential injection model that keeps the agent from ever seeing a reusable secret.
• The policy evaluation structure built on Open Policy Agent and the action-type defaults for read, write, destructive, and external calls.
• The decision trace and audit model that records who delegated, what executed, and when access ended.

👉 Cakewalk's full article covers the gateway decision model, policy engine flow, and zero standing access design.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.