For humans, a bad access policy is a compliance problem. For agents, it's an incident.

At some point every security team has the same conversation. The agent needs broader access to be useful. Broader access is exactly what we cannot sign off on. The meeting ends without a decision, and the agent stays read-only.

"Because of the concern about agents behaving badly, we've scaled back the ambitions of what could be done with an agent."

The team didn't lose confidence in the technology. They lost confidence in the policy layer underneath it. And they were right to.

Why does allow/deny break down for agents?

Binary access control was designed for humans making deliberate decisions. A human connects to a database, runs a query, disconnects. The action is intentional. The blast radius is bounded by judgment.

Agents don't work that way. An agent runs a loop. It queries, evaluates, decides, queries again. Each step is reasonable in isolation. The aggregate can read ten times more than the task needed, touch tables nobody anticipated, and derive things the system prompt explicitly said not to derive.

Allow says yes to the connection. It does not say yes to every action that follows.

Deny kills the agent entirely. Most teams land here after one incident. The agent gets read-only access to a subset of what it needs, and the work that required an agent goes back to a human with a ticket.

The math stops working. The agent gets demoted to a dashboard summarizer.

What does a third answer look like?

The gap between allow and deny is not empty. It is full of actions that are not safe to approve automatically and not wrong enough to block outright.

A write to a production table during business hours. A query that joins customer PII with transaction history. A command that looks like a bulk delete with a WHERE clause the agent constructed itself.

These are not incidents. They are not routine. They are the actions that need a human in the loop before they run, not after.

Route for Review is the third answer. The gateway holds the action, fires a notification, and waits. A human looks at the command in context, approves or rejects it, and the session continues or stops. The whole exchange lands in the audit trail with both the agent's action and the human's decision attached.

The agent does not get blocked. The security team does not get bypassed. The action waits the thirty seconds it takes for a human to make a judgment the policy layer cannot.

How is this different from an approval workflow?

Most approval workflows operate at the access level. An engineer requests access to a database. A reviewer approves the role. The engineer connects.

That decision happens before the session opens. It cannot see the command the agent runs three steps into a loop, or the table it decides to join because the data was there.

Session-level review operates on the wire. The gateway reads the command as it crosses, evaluates it against a policy the security team wrote in plain language, and routes it for review if it matches. The decision happens at the moment the action is about to run, with full context: who is asking, what session this is, what has already run in it, what the command is trying to do.

Access-level approval answers: should this agent be here?

Session-level review answers: should this action run right now?

What does the security team actually configure?

A policy in plain language. Not a rule engine. Not a list of blocked commands.

The security team describes what a risky session looks like: an agent querying a PII table outside business hours, a write that targets more than a hundred rows, a command that combines data the agent should not be correlating. The gateway evaluates every command against that description in real time.

When something matches, the action pauses. The team gets a notification with the command, the session context, and a decision to make. One click to approve. One click to reject. The session record closes with both attached.

A two-person security team at a fintech described their position plainly: "We are a two-person security team. Our biggest focus right now is just the securing of AI agents."

A policy written once, evaluated at every session, with a human in the loop for the actions that matter. That is a workload two people can cover.

What this does not fix

Static policies lag behind agent behavior. An agent that finds a new way to derive something sensitive will not match a rule written before anyone anticipated that shape. The policy needs to evolve as the agents do.

Session-level review also introduces latency. An action that waits for a human approval waits as long as the human takes. For workflows where the agent needs to act in under a second, a review step is not compatible. Read-only plus guardrails is still the right default for those cases.

What changes for the security team this quarter

Stop trying to write a policy that anticipates every action an agent might take. That is a document with no end state.

Write a policy that describes what a risky action looks like. Route those for review. Let everything else run.

Binary access control put security teams in an impossible position: approve broad access and lose control of what happens inside it, or deny access and lose the productivity the agent was hired to deliver.

The third answer does not force that choice. Allow the session. Govern the action. Route the edge cases to a human who can decide in thirty seconds what no static policy could have written in advance.

A bad access policy is a compliance problem you find in the next audit. A bad agent policy is an incident you find in the next postmortem. The difference is not the agent. It is whether the policy layer was built for the way agents actually behave.