← Blog

The AI Agent Security Guide: Where the Controls Actually Live

AI agents plan, call tools, and make requests to models without a human in the loop for each step. Securing them spans host isolation, tool scoping, identity, and the model-call channel. This guide maps the full control surface, marks which layers sit outside an HTTP policy gateway, and shows where identity-aware authorization and per-decision logging on agent-to-LLM traffic do the work.

ByParminder Singh· Founder & CEO, DeepInspect Inc.
Problem-Awareai-agent-securityagentic-aiai-agent-identityai-audit-trailai-egress

An AI agent is a program that decides what to do next. It plans a task, calls tools, reads results, and issues requests to a model, often for many steps without a human approving each one. That autonomy is the source of both the value and the risk. When a component acts on its own authority and at machine speed, the security question stops being "did the user do something allowed" and becomes "did this agent, acting as this identity, take an action policy would permit." This guide maps the controls that answer that question, and it is honest about which of them a network-layer AI proxy covers.

I want to separate the layers first, because most confusion about agent security comes from treating one control surface as if it were the whole thing. For the broader category framing, the AI agent security pillar covers the threat landscape; this guide is the control map.

The four control layers of an agent

Agent security lives at four layers, and they fail independently.

The host layer is the process and sandbox the agent runs in. If an agent can execute arbitrary code on its host, isolation and least privilege at the OS level are the controls, and an HTTP proxy has nothing to say about it.

The tool layer is the set of functions and integrations the agent can call. Scoping which tools an agent holds, and what each tool can touch, happens in the agent framework and the systems it connects to.

The identity layer is who the agent is when it acts. Every call an agent makes should carry a verified, scoped identity rather than a shared key.

The model-call layer is the traffic between the agent and the LLM it reasons with. This is the layer an AI policy gateway inspects.

The agent-to-model channel

The model-call channel is where a policy gateway earns its place, and it is more central than it looks. An agent cannot plan, summarize, classify, or decide without talking to a model. That makes the request path between the agent and the LLM the one chokepoint every agent action routes through at some point. Placing an identity-aware control point there means every model call is authenticated against a real identity, checked against policy for the data it carries and the model it targets, and written to a record. The OWASP LLM Top 10 has ranked prompt injection as a leading risk for a reason: the model is steerable by its inputs, so the content flowing to and from it is a security-relevant surface, not just a payload.

Identity for non-human actors

The hardest unsolved problem in agent deployments is attribution. When five agents share one API key, the log shows the key, and the forensic trail goes cold at the credential. NIST ran a comment window on AI agent identity and authorization that closed April 2, 2026, which signals how unsettled this is at the standards level. The control is to bind every agent to its own scoped identity and to carry that identity on every downstream call. A gateway that issues and checks identity on the model-call path gives you per-agent attribution for the AI traffic even before the broader identity fabric catches up.

Tool and action scoping

An agent should hold the narrowest set of tools its task requires, and each tool should carry its own authorization. This is app-side and integration-side work: the framework decides which functions are registered, and the target systems decide what a given identity may do. A policy gateway does not scope a filesystem tool or a database connector. What it does cover is the subset of tool calls that round-trip through an AI API, and the model calls that decide which tool to invoke. When those calls carry identity and hit policy, an agent asking a model to plan an action it has no authorization for becomes a decision you can block and log.

The audit trail requirement

Every regulated deployment eventually needs to answer, per action, which identity authorized it, what policy applied, and what the agent asked the model to do. That evidence has to exist at the moment of the call. Reconstructing it later from application logs fails, because application logs record the app's own state, not the identity and policy context of each AI request. A per-decision record written at the request boundary is the artifact that survives an audit or an incident review. Google Mandiant's M-Trends 2026 report put the median time from initial access to attacker handoff at 22 seconds in 2025, so the record also has to be machine-readable enough to reconstruct quickly.

Where a policy gateway fits, and where it does not

Set expectations honestly. A stateless HTTP gateway between agents and LLMs does not sandbox a compromised host, does not scope a local tool, and does not rotate a stolen cloud credential. Those are host-layer and tool-layer controls. What it does is authorize and record the model-call channel that every agent depends on. In a defense-in-depth program, that is one specific, load-bearing job: turning agent-to-LLM traffic from an unobserved, unauthenticated flow into an identity-bound, policy-checked, logged one. For the current catalog of agent-driven incidents, see the agentic AI news pillar.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline between your agents and the LLM APIs they call. For every request it evaluates the calling identity, the data involved, model authorization, and organizational policy, then makes a pass or block decision before the traffic reaches the model. It holds no long-lived provider keys and keeps no session state, so it adds a single identity-aware decision point on the agent-to-model path rather than another secret to steal.

The same point produces the evidence. Every agent call becomes a logged event naming the identity, the model, and the policy outcome, which gives you per-agent attribution and an audit trail for the one channel every agent has to use. It does not replace host isolation or tool scoping. It covers the model-call layer those other controls leave open.

If your agents are making model calls you cannot attribute to a specific identity, let's talk today.

Frequently asked questions

What does AI agent security actually cover?

Four layers: the host the agent runs on, the tools it can call, the identity it acts as, and the model-call traffic it depends on. They fail independently. Host isolation and tool scoping are handled in the OS and the agent framework. Identity and the model-call channel are where an AI policy gateway applies, by binding every agent-to-LLM request to a verified identity and a policy decision.

Can a policy gateway secure the whole agent?

No. A stateless HTTP gateway inspects the traffic between agents and LLMs. It does not sandbox a compromised host, scope a local filesystem tool, or rotate stolen credentials. Those are separate controls. The gateway's job is the model-call layer: authorization and per-decision logging on the one channel every agent routes through.

Why is agent identity so important?

Because attribution breaks when agents share credentials. If several agents run on one API key, the log names the key, not the agent, and nobody can say which agent took an action. Binding each agent to its own scoped identity, and carrying that identity on every model call, restores per-agent attribution. NIST's AI agent identity comment window, closed April 2, 2026, shows this is still being standardized.

How does this help with prompt injection?

Prompt injection steers a model through its inputs, which is why OWASP ranks it near the top of its LLM risks. A gateway on the model-call path can inspect the content going to the model and the actions coming back, apply policy to both, and log the decision. It does not make a model immune to manipulation. It gives you an enforcement and evidence point around the model rather than inside it.