Disclosure: This article was written in collaboration with Aembit. The framing, architectural opinions, and checklist are my own.
“I need a gateway” is the wrong first sentence in most agentic AI security conversations. An AI gateway is easy to draw, and it offers one place that can route, inspect, rate-limit, log, and block traffic. As applications add models, tools, MCPservers, and agent-to-agent connections, that choke point starts to look like the whole answer.
It is not the whole answer. The first security question is: Why should anyone trust the request?
Before a Policy Enforcement Point can allow or deny live traffic, an identity and access layer has to establish who is asking; whether the software presenting itself as an agent is the approved workload running in the expected environment; which human, process, or upstream agent delegated authority to it; what resource and action that authority covers; how long the authority remains valid; and whether current risk and business context still permit the action. Those are questions about identity, attestation, delegated authorization, credentials, and policy decisions. An AI gateway can enforce these policy decisions, but it cannot create the underlying trust evidence that justifies them.
This distinction is far sharper for autonomous agents than for traditional software. In a standard web application, platform engineers typically grant the service a high-privilege connection to the datastore, leaving the application logic to enforce fine-grained authorization for deterministic code.
An agent, however, is a dynamic planner. The underlying language model determines the execution path, selecting tools and parameters at runtime. Prompt guardrails offer behavioral guidance, not deterministic access control. Because an agent may require read access in one step, a tightly scoped write in the next, and zero permissions in an unanticipated third, issuing a static credential broad enough to cover every potential action turns dynamic execution into dangerous standing privilege.
A safer model applies deterministic policy to a non-deterministic actor. The system attests the agent as a workload, binds that attested identity to the human, process, or organizational role on whose behalf the agent acts, and re-evaluates policy at the action boundary. It then issues a short-lived, audience-bound credential and records the chain so an auditor can reconstruct who acted, for whom, and with what authority.
Figure 1 illustrates the architectural relationship between trust establishment and policy enforcement: a gateway can route or block traffic, but defending an allow-or-deny decision requires pre-existing identity attestation, understanding whether there is delegated authority, and short-lived credentials. Delegated authority is the workforce case: a person or an upstream agent hands the agent a task. An unattended agent that runs on its own service account has no delegator, so that input is optional for it, while attestation and short-lived credentials still apply.
Figure 1: Enforcement is downstream of trust
The strongest case for identity-first security does not diminish the AI gateway. It gives the gateway a job it already performs well.
Agent execution generates erratic traffic patterns through streaming, retries, fan-out tasks, dynamic model selection, and tool discovery. AI gateways address this by standardizing provider APIs, optimizing cost and regional routing, handling model failover, converting AI API JSON responses into Model Context Protocol (MCP) tools, and mediating agent-to-agent transports. Modern solutions represent distinct approaches to this role: Kong layers AI gateway features onto an established enterprise API management core; the Linux Foundation’s Agentgateway provides a lightweight, open-source Rust proxy built specifically for LLM, MCP, and A2A protocols; and Google Cloud Apigee integrates MCP endpoints, tool registries, and governance into mature enterprise infrastructure.
These functions matter to security even when they are not identity functions. Controlled routing keeps regulated data in approved regions. Failover can stop an outage from sending prompts to an unapproved model. A catalog can cut down on shadow integrations.
An agent can turn one user request into a burst of model and tool calls. Traditional request-per-second limits still help, and AI workloads add token budgets, model spend, concurrency, tool-call fan-out, and loop duration. An AI gateway can rate-limit by client, model, tool, or credential and cut off a runaway loop. Identity makes those limits attributable, so a limit keyed only to an IP address or a shared key does not punish unrelated users. A limit keyed to a verified agent-plus-user pair can stop the offending workflow and leave everyone else running.
Gateways are well positioned to inspect prompts, tool parameters, retrieved context, and model responses. They can invoke moderation APIs, enforce data loss prevention (DLP) rules, and restrict egress to unauthorized destinations. However, content inspection evaluates the payload, whereas identity and access management evaluates the actor and delegated authority—robust production architectures require both.
Inline components capture standard operational telemetry—traffic volume, latency, model selection, token consumption, tool invocations, execution status, and policy outcomes. Observability stops at metrics and logs; true auditability requires provenance:
Attested agent instance A (instantiated from blueprint B), operating on behalf of user C for task D, requested an action against resource E.
Policy version F authorized the request.
Credential G was minted specifically for audience H with an ephemeral time-to-live.
While the gateway captures the runtime event, the identity layer provides the principal context, policy evaluation, and joinable audit trail required for SIEM ingestion.
Architecturally, the gateway functions as a Policy Enforcement Point (PEP), applying allow-or-deny decisions directly to network traffic. The Policy Decision Point (PDP) remains distinct: a centralized control plane (such as Aembit Cloud) evaluates policy, while enforcement components—such as an MCP identity gateway, Kong, Apigee, Agentgateway, or a service mesh—enforce the decision on the wire. Gateways with embedded policy engines collapse these distinct roles into a single component. However, decoupling them remains critical because their failure modes are fundamentally different: a PEP failure disrupts traffic availability, whereas compromised identity evidence causes the PEP to execute unauthorized actions accurately.
The Model Context Protocol (MCP) formalizes these enforcement boundaries. The MCP authorization specification defines OAuth-based flows over HTTPS, mandates protected-resource metadata, and restricts token scopes to designated resource servers. It prohibits clients from relaying inbound MCP tokens to downstream APIs. While an AI gateway can enforce these transport-level constraints, standard JWT signature validation only proves that a trusted issuer signed a payload. Defensible security still depends on the upstream identity layer registering verified agents, evaluating runtime attestation, maintaining delegated authorization chains, and managing credential lifecycles.
An agentic access decision is more than “client X has scope Y.” It needs a verifiable software actor; proof that this actor is the approved workload; the human or process behind it; a real grant of delegated authority; a specific resource and action; current context; a short-lived, audience-bound credential; and a durable record.
If you identify only the user, the agent disappears. Downstream logs attribute every action to the person even when the software chose the tool. If you identify only the agent, you lose the person or process that delegated the work. Shared service accounts collapse several automations into one principal.
Aembit calls the combination Blended Identity. One policy decision evaluates the agent’s attested workload identity and the human identity validated through an enterprise workforce identity provider such as Okta, Microsoft Entra ID, or Google. Policy can distinguish between Ken using an approved client, Ken using an unapproved client, and another employee using the same approved client. The same model works when no user is present. The platform attests a custom autonomous agent as a workload identity from the trust sources the environment already has: cloud metadata services, Kubernetes service-account tokens, OIDC, Kerberos, VMware, or a custom attestor. You get one identity with many sources of trust, for both blended and autonomous cases.
Static secrets do not prove identity. A string such as agent_id=expense-bot is an assertion any caller can copy. Strong workload identity begins with evidence the platform can verify. SPIFFE and SPIRE supply a useful primitive, a signed, short-lived workload identity, but they do not decide business authorization. Aembit maps attested evidence to ownership, purpose, delegated authority, and the credential the target already accepts.
A Cloud Security Alliance survey commissioned by Aembit reports that 68 percent of surveyed organizations cannot clearly distinguish activity performed by AI agents from activity performed by humans. That finding points to a practical gap: organizations are deploying actors faster than they can name, govern, and attribute them. It is a strong case for an identity layer, not a reason to wait [3].
Delegation belongs in the policy model as a first-class object. If each hop forwards the original bearer token, every component receives more authority than it needs. OAuth 2.0 Token Exchange (RFC 8693) can express that one party is acting for another, but few systems implement the proposed standard widely today. A production system still needs a policy model for what can be delegated, how deeply, to which agent, and for how long. The secure default is attenuation: every grant narrows or preserves authority, and none of them silently expands it.
Lifecycle is still identity work. Teams create, copy, version, suspend, and retire agents. Microsoft Entra Agent ID creates specialized directory objects and blueprints and extends Conditional Access to agents. Okta Cross App Access focuses on signed identity assertions between requesting agents and resource applications. CyberArk approaches the problem from privileged access and zero standing privilege. These platforms are strong where the human, the enterprise directory, and SaaS applications sit at the center.
Aembit sits alongside them, not as a directory replacement and not as a generic AI gateway. It is the workload-attestation and credential-broker layer that works across clouds, SaaS, on-premises systems, and AI platforms. Like Microsoft Conditional Access, Aembit evaluates policy when credentials are issued or refreshed and can apply conditional access on risk posture, geo, and time. The difference is the left-side job Aembit was built to do: attest the running software, blend it with the human when a human is present, and give every enforcement point the same identity context.
Human approval for a payment, a source-code merge, or a destructive change is not new. Mature organizations already require a second person before money moves and a pull request before code lands. That control lives in the business process. What changes with agents is the path. A conventional application does at runtime what the developer coded. An agent does what the model selected, within whatever deterministic constraints exist at the time. Identity does not replace the approval workflow. It makes the agent a named principal in that workflow and binds the approval to the exact action, not to a vague conversational confirmation.
Even in an intent-based world, policies should stay deterministic. A prompt may say “draft, do not execute.” A manipulated agent can still produce a plausible explanation for an unsafe call. Policy should prefer verifiable facts: approved task type, tool, operation, resource, classification, amount, user role, runtime identity, and required approval. Intent can help choose which policy to evaluate. It should not create authority the principal does not already have.
Those answers sit on five planes. Governance and directory register the agent, its sponsor, its lifecycle, and the resources it may ever touch. The trust and policy plane attests the running workload, blends identities, and decides. The credential plane mints a short-lived, audience-bound token. Enforcement applies that decision on the wire. Resource authorization, row-level rules, transaction limits, and domain invariants stay with the target.
Figure 2 shows the five planes of a mature agent-access architecture. Aembit provides the identity and policy layer across the first three. Enforcement can sit in Aembit, in another AI gateway, or in both.
Figure 2: Five planes of agent access
Identity for an AI agent is not a static identifier—it is an ephemeral authorization decision evaluated per action. Static labels like expense-bot or upstream user tokens forwarded into downstream tool calls fail to establish true access context. Defensible security requires continuous, request-time evaluation: is this specific principal or sponsor, operating through this attested agent instance, authorized to perform this exact action on this target resource, under an active grant, within current risk parameters, and against a specific policy version?
That is why the unit of authorization is a tuple, not a badge. The left side of the decision holds two subjects that must not collapse into each other. The human or sponsor is the user, customer, process owner, or upstream agent that delegated the work. The agent or workload is the blueprint, the deployment, the instance, and the runtime evidence that proves the software is the approved one. Aembit’s glossary calls the fusion of those two planes a blended identity: the agent’s cryptographically attested workload identity plus the human currently instructing it. When no human is present, a process owner, a service identity, or an upstream agent still fills the sponsor slot, so the decision never becomes “the software, acting as itself, with no one to name.”
The center of the decision binds those subjects to a grant. Delegation has to be a first-class input: what was given, how far it may hop, and whether this hop attenuates. Resource and action pin the audience: this tool, this operation, this object, not “whatever the model selects next.” Task and approval capture the business-process control the previous section described: a payment, a merge, or a destructive change, bound to the exact action rather than a chat confirmation. Time, risk, and posture play the same role Conditional Access plays for people: geography, maintenance window, runtime health, and incident identifier. Policy version is what lets you reconstruct the decision six months later.
The only output that should leave that decision is an audience-bound, short-lived credential and a correlated record. The agent does not inherit the user’s standing token, and it does not receive a shared service-account key. It receives a credential that is valid for that audience, for a short lifetime, and that you can join in the SIEM to the human, the workload instance, the grant, the policy version, and the outcome. Aembit’s documentation is explicit that blended identity is not impersonation. The agent is not allowed to become the user. Policy evaluates both identities independently, so Ken on an approved client, Ken on an unapproved client, and another employee on the same approved client are three different decisions.
If any of those inputs is missing, the system should not issue a scoped result. A gateway that validates a JWT without them is only enforcing a label.
Figu…
