A recurring pattern in agent deployments is clear: teams reach for a gateway first, but gateways are the control they are least prepared to operate. That shortfall stems from gateways depending on identity and attribution layers that frequently do not exist.
The risk is not theoretical. In June, the Cybersecurity and Infrastructure Security Agency (CISA) added a LiteLLM flaw to its Known Exploited Vulnerabilities catalog after attackers abused it in the wild. The bug allowed commands to run on the host via the gateway itself and, chained with a second flaw, required no credentials. In a single AI gateway, seven CVEs were disclosed in one month — a layer many enterprises try to secure first.
Why gateway controls should come later
Nik Kale argues gateway controls should typically be the fifth control, not the first. Most maturity models list controls organizations will need eventually, but they often omit practical guidance for brownfield scenarios: in what order should controls be layered alongside an existing identity and access management (IAM) system?
If the control plane cannot say which agent is acting, who delegated the work, what the task is, and which credentials are in use, the context is incomplete. A gateway may block clear policy violations, but it will struggle to distinguish a justified action from one that is technically allowed yet operationally inappropriate.
An example of the wrong starting point
Consider routing agent traffic through a new runtime gateway: a finance-reconciliation agent attempts to modify a production record. The gateway authenticates the user token and checks the API call, but it cannot see that the request was agent-initiated, that the agent is executing a limited function, or that the request is part of an untrusted tool chain. The credential is valid and the API call permissible, yet the action may contradict the delegation’s purpose. Without supporting context, the gateway can apply a costly control to a narrow slice of the problem.
Limit privileges, but don’t lose attribution
Capping an agent’s privileges to those of the human principal is useful, but it does not create separate attribution. Multiple agents operating under a single person’s permissions still need unique identities, audit logs, behavior profiles and revocation paths.
Dependency-gated deployment: the six gates
Kale calls the recommended approach dependency-gated deployment: upstream exit tests must be satisfied before downstream controls are considered operationally complete. Downstream work can be developed concurrently, but it should not be relied upon until upstream gates pass. The six gates and the operational proof for each are:
- Agent inventory and accountable ownership
- Every production agent has a named owner, a stated purpose, approved tools, and a lifecycle state.
- Distinct agent identity plus delegation context
- The system can identify the agent, its owner, and the principal it acts on behalf of.
- Task-scoped, short-lived credentials
- A compromised agent cannot access resources unrelated to its assigned task.
- Attributable telemetry
- A completed task can be reconstructed from initiation to downstream effect.
- Runtime action enforcement
- Policy decisions consider agent, principal, task, and action context, not just token validity.
- Behavioral baselines and a cross-system kill path
- The agent’s effective authority can be stopped across every system it reaches.
Operational advice: start with what you can name
Begin by cataloguing production agents across open-source frameworks, cloud offerings, SaaS products and developer tools. For each agent record the owner, responsibility, lifecycle stage, allowed tools, data domains and credential sources. Skipping this step costs the organization the first hour of incident response while teams determine what asset a given activity belongs to.
Agent identity must include delegation context
An agent should not be hidden inside a developer token, a shared service account or a human session. Simply knowing a caller is an agent is insufficient: the control plane needs delegation context — who delegated the work, which specific task was instructed, and which resources the agent needs authority to access. Identity tells you who made the call; delegation tells you under whose authority and for what reason it acted. If that link is severed, downstream logs will attribute the agent’s actions to the employee whose token was borrowed.
Shrink authority before inspecting behavior
Once an agent can be identified, capabilities should be limited: access must be time-bound and constrained to the tools and resources required by the task. Implementations can use existing IAM features such as workload identity, token exchange, conditional access and time-bound entitlements.
A 2026 Teleport study of 205 security leaders found that access scope outperforms industry, maturity or self-assurance in predicting AI-related incidents: organizations with over-privileged AI reported a 76% incident rate, while those with the least privilege experienced incidents at a 17% rate. This underscores that access scope in the dependency chain is often more important than context-aware runtime enforcement.
The guiding principle is monotonic delegation: each transfer of responsibility must preserve or reduce authority; it must never increase it. For a reconciliation agent that means the agent should be able to view the specific ledger it needs, not inherit all systems the employee can access.
Fix attribution before automating enforcement
Most audit stacks can capture which resource was accessed and which credential enabled it. In the agent deployments Kale reviewed this gate was most commonly missed. Before relying on adaptive runtime policy, link tool invocations to agent identity, initiating principal, task id, parent action and outcome. Then verify you can reconstruct a completed task: identify the initiator, the agent that executed it, the authority used, the tools involved and the outcome. In regulated environments, un-attributed oversight is untenable.
When the gateway is ready, it adds most value
If the gateway has access to registered identities, explicit delegation, scoped credentials and attributable telemetry, it can ask: is this agent authorized to perform this action for this principal, within this task and involving this resource? Even if a user’s credentials would provision write access, situational context may show the action is out of scope. Gateways are most valuable at irreversible boundaries — payments, access policy changes, deletions, production modifications and data exports.
Detection and kill path come last
Behavioral baselines are constructed last because you must first establish distinguishable and attributable agent activity to define the standard. Then security teams can detect anomalous tool usage, unexpected cross-domain access and deviations from assigned tasks. A proper kill path includes disabling the agent’s identity, invalidating active and derived credentials, blocking tool activation, terminating active tasks and isolating the workload that contains the agent.
Don’t replace your IAM immediately
You do not need to design an entirely new identity program. If your existing identity provider does not natively treat agents as objects, start with an authoritative registry linked to existing workload identities. Extend agent and task identifiers as trusted execution contexts, implement short-lived credentials to mitigate inherited privileges, and include those identifiers in tool-call logs for later gateway ingestion. The dependency model remains the same as vendor support matures.
Measurable gaps
Okta’s 2026 survey found only 34% of executives say their organization always applies the same level of security rigor to agentic workers as to human workers. The final control in the chain cannot be applied first to bridge that gap.
What to do in the next 30 days
- Start with 10 production agents. For each, identify the owner, purpose, approved tools and credential sources to begin an agent registry and governance insights.
- Test attribution: can IAM and logging differentiate each agent from the human or service that delegated the task? If not, a gateway would operate without visibility.
- Reconstruct one completed agent task across the action chain, from start to downstream effects. Where the chain breaks is where your deployment is insufficient.
Adding downstream enforcement before the required upstream context breaks agent security. Maturity models describe the destination; a correct build order gets you there without breaking production along the way.
Nik Kale is a principal engineer specializing in enterprise AI platforms and security.
