Engineering teams have spent the last eighteen months adopting AI coding agents at a pace nobody predicted. Cursor, Claude Code, internal agent frameworks running in CI. These tools have changed how production work gets done. Code review, debugging, schema migrations, incident response, all of it now includes a model in the loop. Security teams have not had the same upgrade, and the gap is what makes agent-on-agent governance the conversation worth having right now.
The controls security teams reach for are the ones that worked five years ago. Static IAM policies. Role definitions written in YAML. Audit logs read after the fact. Approval workflows designed for a human engineer with a Slack thread and a ticket number. These controls assume the actor is slow, deliberate, and predictable.
Agents are none of those things.
This gap is the thing showing up in every security conversation right now. The dev team is shipping agents into production. The security team is being asked to govern them. And the tools the security team has are not the tools the situation calls for.
What's actually breaking in the field?
A pattern from sales conversations over the past quarter: security teams describe themselves as "extremely overwhelmed." Not by AI itself, but by the mismatch between the speed of agent adoption and the speed of policy authorship.
A static policy is a guess about future behavior. When the actor is a human engineer, the guess is good. Humans repeat patterns. They run the same queries, hit the same endpoints, follow the same playbooks. A policy that says "engineers in the platform group can run these commands on these databases" covers most of what the human will actually do.
When the actor is an agent, the guess gets harder. Agents generate commands that nobody on the team has seen before. They explore. They chain operations in ways the prompt did not anticipate. The surface of possible actions is creative enough that enumerating it as policy stops being practical.
Security teams notice this fast. They write more policy. They block more paths. They get more tickets from developers who hit walls the security team did not intend to put up. The friction goes up on both sides. Adoption keeps moving anyway, because the business value of AI in development is real.
The honest read: static governance is losing to dynamic action. Not because the governance model is wrong, but because the speed mismatch is too large to close with more rules.
What does "agent-in-the-loop" mean for security?
The term human-in-the-loop has been around for years. It describes a workflow where a human reviewer sits between an automated system and a consequential action. The system proposes, the human approves.
Agent-in-the-loop is the same shape, with the reviewer changed.
When a dev team's agent acts on production infrastructure, that action flows through some kind of gateway or control point. Today, the control point is usually a static policy engine. The policy was written weeks or months ago by a human security engineer. It approves or rejects based on rules.
What if the control point was itself an agent?
Not to replace policy. Policy still defines what is allowed in the abstract. But to evaluate specific actions in context, to read the actual command, understand what it would do, and decide whether the situation warrants approval, escalation, or block. To do that at the speed the dev agent is operating, not at the speed a human reviewer would.
This is the move. The security team gets the same class of tool the dev team has been using. The static policy becomes a prompt, with context. The reviewer becomes an agent the security team controls. The reviewer reviews in real time, against the actual action, not against a guess about future actions.
How does it work in practice?
Hoop sits between humans, AI agents, and the production systems they touch. Every action, human or agent, passes through. RBAC, masking, approval gates, audit logging all run on the same path.
Two weeks ago we shipped the user MCP server, which lets a dev team's agent operate with the identity of the human user who started the session. Last week we shipped OAuth federation, which means that identity comes from the same IdP the security team already trusts. Both of those launches answered the same question: who is the agent.
The next question is what is the agent doing right now, and is that okay.
Session Analyzer is the answer. It is an agent the security team configures. It runs against the live stream of commands flowing through the gateway. The security team writes a prompt instead of a policy. The prompt says, in natural language, what kinds of action are sensitive, what context matters, what should trigger escalation. The Session Analyzer reads each session as it happens and decides, in real time, whether to flag it, pause it, or let it run.
The dev team's agent and the security team's agent operate at the same speed. Same generation of tooling. Same model class. The asymmetry that has been making security teams miserable for the last year goes away.
What about specific, controlled actions?
There is a second half to this picture that we will go deeper on later this week. Most of the conversation about AI agent governance assumes the agent is given broad permissions and then restricted by policy. There is another direction worth exploring: giving the agent specific, named actions instead of broad permissions.
Hoop's Runbooks feature already supports this pattern. A runbook is a defined, parameterized action that an agent can invoke as a tool, with the parameters validated and the action audited alongside any other session. The agent does not have permission to do whatever it wants in the database. It has access to three runbooks. The runbooks are the entire surface.
That inversion changes the security model. We will write more on it this week.
What we want security teams to take from this
The work of governing AI agents in production is not a smaller version of the work of governing human engineers. It is a different shape, at a different speed, with a different surface of action. The controls need to match the shape of the problem, not the shape of last decade's problem.
Agent-on-agent governance is one way to do that. The security team gets an agent. The dev team's agents pass through it. The conversation about access stops being about static rules and starts being about real-time judgment, made by a system the security team owns and configures.
Same generation of tooling. Same speed. Same playing field.