Governance before autonomy

An agent that can read a system can usually act on it too. That is the whole point of agentic AI, and it is also the reason a demo that impresses a room is not yet something you can run in production. The gap between the two is governance. Before you give an agent the keys, three controls need to be in place: policy that decides what it may do, approval that keeps a person on the consequential moves, and audit that lets you prove what happened. Get those three right and autonomy becomes something you can expand with confidence. Skip them and every new use case is a new liability.

Why autonomy outpaces control

Most teams reach for autonomy first because it is the exciting part. An agent drafts the report, files the ticket, updates the record, and the value is obvious in the room. The trouble shows up later, when the same agent has quiet access to data it should never touch, takes an action no one signed off on, or produces an outcome no one can reconstruct. None of those are model problems. They are governance problems, and they do not fix themselves as the model improves. A more capable model that is still ungoverned simply fails in more capable ways.

The safer order is to invert the instinct. Decide what an agent is allowed to see and do, decide which actions need a human, and decide how every step gets recorded. Autonomy then expands inside those boundaries rather than outrunning them. The boundaries are not there to make the agent timid. They are there so that when the agent does something surprising, and it will, the surprise stays inside a fence you drew on purpose.

Three failure modes governance has to answer

It helps to name what actually goes wrong, because each failure maps to a control.

The first is over-broad access. An agent is handed a service account or an API token that can see far more than the task requires, and for a while nothing bad happens. Then a prompt, a document, or a chained tool call steers it toward data it was never meant to read. The exposure was there the whole time; the trigger just arrived late.

The second is the unapproved action. The agent does something consequential, sends the message, moves the file, closes the case, that a person would have wanted to check first. In a demo this reads as initiative. In production it reads as an incident.

The third is the unreconstructable outcome. Something happened, a record changed or a document went out, and no one can say exactly which agent did it, on whose behalf, using which inputs, or why. Without that, you cannot defend the action, learn from it, or rule out that it happened again somewhere you did not notice.

Three controls to put in place first

Policy: attribute-based access control

Role-based permissions are too coarse for agents. A person logs in once and mostly stays in a lane. An agent acts across tenants, classifications, and contexts within a single run, so access has to be decided per action, not per login. Attribute-based access control (ABAC) evaluates who the agent is acting for, what the data is, and what the action would do, then decides. In Trunnion, ABAC and a six-layer tool authorization check sit in front of every action an agent takes, so a read or a write clears policy before it happens rather than after. The difference is subtle but decisive: an after-the-fact check tells you about a breach, a before-the-fact check prevents one.

The practical payoff is scoped blast radius. When access is evaluated per action against real attributes, an agent that is steered off course hits a wall instead of a data set. The workflow fails safe, and the failure is a denied action in the log rather than a disclosure you have to report.

Approval: a human on the consequential moves

Not every action deserves a human, but the consequential ones do. A human-in-the-loop approval gate pauses those actions for a named operator to approve, edit, or reject, with the policy checks and the agent’s reasoning attached. Agents propose; people decide. This is what lets a team put autonomy into a real workflow without handing over final judgment on the moves that carry risk.

The design question is where to put the gates, and the answer is not everywhere. Gate the actions that are hard to reverse or externally visible: sending, publishing, spending, deleting, releasing. Leave the reversible interior steps to run on their own. A gate on every step turns an agent into a slow form; a gate on the moves that matter turns it into a colleague who checks in before doing something you would want to know about. The operator sees what the agent proposes, why it proposed it, and which policies it already cleared, then makes the call in seconds rather than reverse-engineering the decision later.

Audit: a record you can prove

If you cannot reconstruct what an agent did, you cannot defend it to a reviewer, a regulator, or your own security team. A useful audit trail is more than a log file that an application writes and can therefore rewrite. Trunnion writes every step to a SHA-512 hash-chained record, where each entry is linked to the one before it, so altering a past entry breaks the chain and shows. That property, tamper-evidence, is what turns a log into evidence. Full reasoning traces and execution replay mean an auditor can follow not just what happened but why, and can re-run the sequence to see the decision unfold rather than taking a summary on faith.

Audit also pays for itself long before an auditor asks. When an agent does something unexpected, the same record is your fastest path to understanding the failure, containing it, and fixing the policy that let it through.

What the three look like together

Consider a procurement package moving through review. An agent retrieves the solicitation and two prior awards, but ABAC scopes the read to the records this operator is cleared for, so nothing outside scope is ever in context. The agent drafts the package and flags a missing clause. Because sending the package to the contracting officer is consequential, the workflow pauses at an approval gate: the operator sees the draft, the flagged clause, the reasoning trace, and confirmation that policy and tool authorization already passed, then approves. Every one of those steps, the scoped read, the draft, the flag, the human approval, the send, lands in the hash-chained trail. No single control carries the workflow. Policy keeps the inputs in bounds, the gate keeps a person on the decision, and the audit makes the whole run reconstructable. That is what governed autonomy looks like in practice.

Governance is not a brake

The common objection is that all of this slows agents down. In practice the opposite tends to be true. Teams that ship agents without governance stall the first time something goes wrong, because they cannot explain the failure or contain the blast radius, and a single bad incident can freeze a program for months. Teams that put policy, approval, and audit in first can expand scope with confidence, because every new use case inherits the same controls instead of relitigating them. Governance is what makes autonomy repeatable, and repeatability is what lets a pilot become a platform.

There is a trust dimension too. The people who have to sign off on putting AI near real work, security, compliance, the operators themselves, are far more willing to say yes when they can see the fence. Governance is often the thing that gets a project approved at all.

Where to start

Pick one workflow that matters and map three things: what data the agents touch, which actions are consequential enough to need a person, and who will review the audit trail. Wire ABAC and an approval gate around that workflow, prove it against real work with a human in command, then widen. Resist the urge to start with the flashiest use case; start with one where the boundaries are clear enough to draw well, because that first workflow becomes the template every later one inherits.

The goal is not to make agents cautious. It is to make autonomy safe enough to trust in the places where the stakes are real, and to build it so the second workflow, and the tenth, arrive already governed rather than each reopening the question. Decide what the agent may do, keep a person on the moves that carry weight, and keep a record you can stand behind. Autonomy grows naturally from there.