Control Is the Missing Layer in AI Agents

A property insurance company launches an AI agent that helps adjusters update claim statuses. It is given the same service account the team has used for years. The pilot looks great.

Three weeks in, the agent gets a slightly malformed instruction and updates twelve thousand claim statuses in under an hour. No human would have done that. There was no rate limit, because the role had never needed one. There was no second approver, because the role had never required one. There was no audit log of the agent's plan, only of the database writes.

The cleanup took two months. The incident review took longer. The conclusion was the same one every team reaches sooner or later: permissions designed for humans do not survive contact with agents.

Humans get tired. Agents do not. Humans hesitate before clicking delete. Agents do not. Humans notice when something feels off. Agents do not.

Every access control framework most enterprises run today was designed for a world in which the actor on the other end of a credential was a person. The same permission, in the same role, behaves like a completely different risk depending on whether a human or a system is holding it.

Control is the second of the four C's, and it is the one that decides whether your AI program survives its first incident. Context tells the agent what things mean. Control tells the agent what it is allowed to do with that meaning.

Without Control, Context becomes a liability. The clearer your agent's understanding of the business, the more damage it can do at machine speed if you have not bounded its actions.

Access control answers: is this identity allowed to perform this operation? Action control answers a richer question: is this identity allowed to perform this operation, at this rate, on this volume, in this context, with this blast radius?

It is the difference between giving someone a building key and giving them a key plus a rule that says they can enter three rooms a day, never after 8pm, never in groups of ten, and never the server room without a second approver.

After the incident above, the same team rebuilt the agent with action control. The agent could still update claim statuses, but: maximum one hundred updates per hour, any batch over fifty triggered a human approval, all updates were dry-run first and logged as a 'plan' before execution, and an on-call engineer had a kill switch wired into chat.

The agent shipped again. Adjusters loved it. Compliance signed off. No more incidents.

List every action your agents can take. For each one, write down two numbers: the most an agent should ever do in an hour, and the most it should ever do without a human in the loop. If you do not know either number, your agent is operating with implicit limits — which means no limits.

Then implement the smaller of the two as a hard cap, and the larger as the approval trigger. Log everything: the prompt, the plan, the tools called, the arguments, the outcome.

Platform engineers and data engineers will own most of this layer, because it lives where the data lives. Governance and security teams will partner on the policy. AI engineers will design the agent loops to respect the constraints. Data leaders will measure success not by features shipped but by incidents avoided.

Giving the agent a service account with the same permissions as a senior human, and calling it a pilot. The permissions worked for the human because the human had judgment. The agent does not. It has speed.

Publish a one-page 'agent operating standard' that every AI feature must meet before it ships. Rate limits per agent. Volume caps on writes. Tool-level allowlists. Human-in-the-loop for irreversible actions. Full audit logs of plan and outcome. A kill switch any on-call engineer can pull without filing a ticket.

Make the standard boring. Boring survives an incident review.