AI agent security must start before the gateway

A finance-reconciliation agent can present a valid user token, make an API call the user is allowed to make, and still take an action it was never delegated to perform. A runtime gateway may approve the request because it sees valid credentials and permitted write access. Yet the authorization decision changes when the gateway also knows that an agent initiated the request, its reconciliation remit is narrower than the user’s permissions, and an untrusted artifact triggered the tool chain.

Why gateway-first agent security can create false confidence

The finance case exposes a basic problem with starting agent security at the gateway. Authentication establishes that a credential is acceptable, but it does not establish that an agent’s action belongs to its assigned purpose. If the agent inherits write access from the employee it serves, changing a production record can be technically permissible while falling outside the delegated task.

That distinction changes the security question for teams putting agents into production. The question is whether identity, delegation, least privilege, and attribution provide enough context for runtime controls to make meaningful decisions. A gateway consumes those inputs downstream, so treating it as the foundation can leave authenticated agents free to perform operationally inappropriate actions.

Because those inputs come from upstream controls, build order matters as much as the controls an organization acquires. The agent must be identifiable, its delegated authority must be known and constrained, and its activity must be attributable before a gateway can reliably decide what a valid credential may do in a particular task. Strong enforcement with weak upstream context can create confidence that the enforcement point cannot justify.

Gateways are valuable, but they are Gate 5

The dependency on upstream context does not make early gateway deployment useless. Runtime enforcement can catch obvious policy violations immediately, so gateway engineering can proceed while upstream systems are still being built. But its operational limit is clear: a gateway cannot reliably distinguish a justified action from a technically allowed but inappropriate one until it receives agent identity, delegating principal, task context, scoped authority, and attributable telemetry.

That limit matters because the runtime layer creates an attack surface of its own. In June, CISA added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog after exploitation was observed in the wild. One LiteLLM vulnerability enabled commands to run on the host through the gateway; chained with a second flaw, the attack required no credentials. Seven CVEs were disclosed in LiteLLM within one month.

Those vulnerabilities do not show that gateways are inherently unsafe. They show why one runtime component should not carry the architecture beneath it, particularly when that component can itself become an attack surface. Gateway enforcement has substantial value once upstream controls provide the context its decisions require.

A “dependency-gated deployment” model organizes those upstream and downstream requirements into six gates. Each gate produces context needed by controls later in the sequence, and each has an exit test that establishes when it is operationally complete. Upstream exit tests must pass before downstream controls receive that status, even when engineering and procurement for several gates proceed in parallel.

The six gates describe information dependencies, so they should not be confused with a purchase schedule. An enterprise may already own a gateway, behavioral system, and mature identity and access management (IAM) stack, or it may build all of them simultaneously. The sequence concerns the information each control can depend on when it starts making production decisions.

Gates 1 and 2: Know which agent exists, who owns it, and whose authority it carries

Because every later control acts on an agent, Gate 1 establishes which production agents exist and what each is meant to do. Discovery needs to cover agents running through open-source frameworks, cloud offerings, SaaS services, and developer tools. For every agent found, the inventory should record its owner, responsibility, lifecycle stage, allowed tools, data domains, and credential sources. Gate 1 is operationally ready when every production agent has a named owner, purpose, approved tools, and lifecycle state.

That inventory may look administrative compared with runtime policy, but an incident makes its security role concrete. Without an authoritative record, responders can spend the first hour determining which agents exist and what each is supposed to be doing. With the inventory in place, investigation and enforcement have a defined asset with a known purpose and accountable owner.

Once Gate 1 establishes the asset, Gate 2 gives it a distinct identity. An agent buried inside a developer token, shared service account, or human session may authenticate successfully, but later controls cannot reliably separate its actions from those of other software or people using the same identity. Giving the agent its own identity creates a revocable, auditable actor that can persist across individual calls.

That distinct identity leaves a second question: whose authority is the agent exercising, and for what purpose? Delegation context should preserve who assigned the work, the particular task given to the agent, and the resources required to complete it. Identity tells the system which actor made a call; delegation explains the authority and reason behind it.

The distinction becomes important when twenty agents operate under one person’s permissions. The human’s permissions can cap what all twenty can reach, yet the agents may perform very different work and therefore need separate identities, audit logs, behavioral profiles, and revocation paths. A human permission ceiling limits aggregate authority, but accountability still requires the system to distinguish the individual agents using it.

The reconciliation agent shows what happens when that test fails. When the agent borrows an employee token without an agent-to-human identity link, downstream logs attribute its activity to the employee and lose the identity of the actor that executed the task. Gate 2 exits only when the system can identify the agent, its owner, and the principal for whom it is acting, preserving both sides of that relationship for later decisions.

Gate 3: Reduce authority before trying to infer bad behavior

Once the system knows the actor and the delegation, Gate 3 reduces how much damage that actor can cause. The sequence is concrete: identify the agent, bound access to its assigned task, restrict it to the required tools and resources, and make that access expire with the task. The exit test is equally practical: compromise of the agent should not grant access to resources outside the assignment.

Existing IAM machinery can implement much of that boundary. Workload identity can establish the software actor, token exchange can issue credentials appropriate to delegated work, conditional access can apply constraints, and time-bound entitlements can remove standing authority. Together, those controls turn a broad inherited permission set into credentials shaped around a specific task.

Those controls implement “monotonic delegation,” which means every transfer of responsibility preserves or reduces authority and never increases it. For a reconciliation task, an agent that needs to inspect one ledger should receive authority over that ledger for the required work. Simply inheriting everything the employee can access gives the agent unrelated authority its assignment never required.

The effect of access scope appears in a 2026 Teleport study involving 205 security leaders. Organizations with over-privileged AI reported a 76% incident rate, compared with 17% among organizations operating under least privilege. Teleport interpreted the results as showing that access scope predicted AI-related incidents better than industry, maturity, or respondents’ self-assurance. Teleport sells identity and access infrastructure, so it has a commercial interest in organizations investing in controls that limit and govern access.

Within Teleport’s findings, the large difference in incident rates makes privilege scope a security priority before sophisticated behavioral judgment. Adaptive enforcement can try to recognize a dangerous action after broad authority has already been granted. Task-scoped credentials reduce the available actions first, which limits the consequences of drift, compromise, or a poisoned input before a runtime system has to infer intent.

That smaller action set also gives later controls clearer evidence. A policy engine evaluating a narrowly scoped credential can compare an attempted action with an explicit resource boundary, while an investigation can compare actual use with the same boundary. Gate 3 turns delegation from descriptive context into enforceable authority.

Gate 4: Make an agent’s actions reconstructable before making policy adaptive

Even narrow authority needs attribution because runtime policy and later detection depend on knowing how individual actions fit into a task. Gate 4 links each relevant tool invocation to the agent identity, initiating principal, task ID, parent action, and outcome. Its exit test is the ability to reconstruct a completed task from initiation through its downstream effect.

That reconstruction directly tests the telemetry established by Gate 4. Pick a completed task and determine who initiated it, which agent executed it, under whose authority it ran, which tools it used, and what outcome followed. Any missing link identifies a place where later policy would have to decide with incomplete context.

Those missing links are the telemetry version of the identity problem at Gate 2. Audit infrastructure may record a resource and the credential that accessed it, but adaptive agent controls need the relationship among principal, agent, task, actions, and effects. In regulated environments, unattributed oversight is difficult to justify because the organization cannot reliably connect an outcome to the actor and authority that produced it.

Gate 5: Runtime enforcement now has enough context to judge the action

With Gates 1 through 4 supplying context, the gateway can perform the role that gateway-first designs expect from it. Registered agent identities identify the actor, explicit delegation supplies the principal and task, scoped credentials define bounded authority, and attributable telemetry connects the current action to a traceable chain. Runtime policy can now evaluate agent + principal + task + action + resource.

That richer decision changes the opening finance-reconciliation case. An employee’s credentials may permit writes, but the gateway can see that the reconciliation agent is acting under a narrower delegation and reject a production change that falls outside that purpose. The gateway can distinguish a credential-valid request from a delegation-valid request because it now has the inputs required to make that distinction.

With those inputs available, the strongest enforcement belongs at actions whose consequences are difficult to reverse or especially sensitive. Those boundaries include payments, access-policy changes, deletions, production-environment modifications, and data exports. At each boundary, Gate 5 exits when the decision incorporates agent, principal, task, and action context alongside token validity.

Earlier gateway deployment still has value because clear violations can be blocked before this context is complete. After the first four gates, however, the quality of judgment available at runtime changes. Enforcement advances from checking an observable request against broad policy to deciding whether this particular actor, acting for this principal on this task, should perform this action on this resource.

Gate 6: Behavior and containment come after activity becomes distinguishable

Once agent activity is attributable, behavioral baselines can describe how a particular agent normally operates within its assigned work. Security teams can then detect anomalous tool-use patterns, unexpected access across data domains, and deviations from the tasks assigned to that agent. Building these baselines earlier would mix activity that the system cannot yet reliably distinguish or attribute.

Detection then needs a containment path that reaches farther than one policy point. Gate 6 exits when the organization’s effective authority over the agent can be stopped everywhere the agent reaches. Reaching that state requires disabling the agent identity, invalidating active and derived credentials, blocking tool activation, terminating active tasks, and isolating the workload containing the agent.

That cross-system kill path matters because agent authority can persist in several forms after one directory object or gateway route is disabled. An active task may still be running, a derived credential may remain usable, or the workload may retain access to a tool. Containment is complete when those paths can be cut together, with each relevant enforcement point stopping the authority it controls.

Brownfield IAM can support this sequence without a wholesale replacement

The dependency model is particularly useful for brownfield IAM, where identity infrastructure is already in production and the organization has to add agents without rebuilding its identity program. Conventional maturity models can disadvantage this environment when they describe a future set of controls without explaining how to layer them onto existing IAM. Organizations in that position commonly reach first for gateways, even though the gateway depends on context the current identity model may not yet represent.

That context can be added even when an identity provider lacks a native agent object. The enterprise can establish an authoritative agent registry and link its records to existing workload identities. Agent and task identifiers can then become trusted execution contexts, while short-lived credentials reduce inherited privilege and those identifiers are written into tool-call logs for later gateway ingestion.

Because later gates depend on the information rather than a particular implementation, the model can remain stable as vendor support matures. A native identity capability can eventually replace or integrate with pieces of the interim implementation without changing the information later gates need. For a brownfield organization, an authoritative registry plus workload identity is a workable starting architecture without a wholesale IAM replacement.

The need to fit agent controls into normal security operations also appears in Okta’s 2026 survey. Only 34% of executives said their organization always applies the same security rigor to its agentic workforce as to its human workforce. The figure does not establish the six-gate sequence, but it does show a broad governance gap around agentic systems.

A 30-day test: start with 10 production agents

That governance gap can be tested against real infrastructure with a next-30-days exercise covering 10 production agents. For each one, identify the owner, purpose, approved tools, and credentials, turning the exercise into the beginning of an agent registry while exposing immediate governance gaps. Then test whether IAM and logging can distinguish each agent from the human or service that delegated its work; if they cannot, the gateway lacks necessary visibility into who is actually acting.

Once those identities have been tested, choose one completed agent task and reconstruct its full action chain, including downstream effects. Follow the initiator through agent execution, authority, tool calls, and resulting changes, and record every point where the chain can no longer be followed. Each break identifies a dependency that production controls currently assume but cannot establish.

Use each recorded break to identify the next control dependency to repair. If the chain loses the agent identity, fix identity propagation; if it loses delegated authority, preserve that context; if a tool call cannot be connected to its downstream effect, repair the telemetry across that boundary. Re-run the same completed-task reconstruction after each change until the system can follow the task from its initiator through the resulting changes.

In conclusion

For executives, the main decision is not whether to invest in agent security, but whether those investments are being made in an order that lets each control work as intended. A gateway can enforce policy, behavioral systems can detect anomalies, and existing IAM can constrain access, but none of them can compensate for an agent whose identity, delegated authority, and actions remain unclear.

The six-gate model provides a way to turn that dependency into an operating plan. Establish which agents exist and who owns them, preserve identity and delegation, narrow their authority, make their actions reconstructable, then use that context for runtime enforcement, behavioral detection, and containment. Teams can build several capabilities in parallel, but production trust should depend on proving the upstream context each control requires.

For business leaders, this also creates a practical standard for measuring progress. Instead of asking whether the organization has purchased an agent-security platform or deployed a gateway, ask whether a production agent can be identified, limited to its assigned task, traced from instruction to outcome, and stopped across every system it can reach. Those are testable properties that connect security investment to operational risk.

As agents gain access to payments, production systems, sensitive data, and other consequential resources, valid authentication will remain necessary but insufficient. The organizations best positioned to expand agent use safely will be those that treat identity, authority, attribution, enforcement, and containment as a connected control system rather than separate security products.