In March, your platform team approved a coding agent with one condition: it asks before running any command that changes infrastructure. By October, half your engineers have switched on auto-approve for the commands they consider safe. A model upgrade lets the agent work for 40 minutes without checking in, two new MCP servers have joined its toolset, and the engineer who signs off on its requests does it from Slack in four seconds. Nobody filed a change request, yet the agent now does far more alone than anyone approved.

Each of those changes looked reasonable to the person who made it. Together they moved the agent's autonomy, how much of its access it uses with no one signing off, and the original approval never wrote that part down. Keeping autonomy where you set it is the job of agentic AI governance.

This article works through each part of that job, from what it covers to how you'd take autonomy back in a hurry. It follows the order the work happens, so you can start with a single agent and keep going. Along the way, you'll find steps small enough to try on your own agents this week.

What is agentic AI governance?

Agentic AI governance is the practice of deciding how much an AI agent may do without a person, for which actions, and on whose authority, then holding it to that decision as it changes, with records to prove it. Autonomy is what makes AI agentic. It also grows after approval, through routes that never file a request.

In practice, the work comes down to a written setting for each kind of action an AI agent takes, from acting alone to waiting for sign-off, with a named person behind each one. Those settings hold the agent in place as its model, tools, and people change, and each one can be raised or pulled back on evidence.

Agentic AI governance builds on AI agent governance, the program that approves agents, names their owners, and scopes what they can reach, and it reuses the same records and review cycles. Identity programs are built to govern that reach, so the newer work is recording, raising, and pulling back autonomy. Model governance still covers what an agent says, while this work covers what it may do alone.

How do you implement agentic AI governance?

A working agentic AI governance framework starts by recording autonomy for each action class an agent handles, with the person who granted it and the evidence behind it. Then watch the five routes autonomy drifts through: local auto-approve settings, upgrades, new tools, widening borrowed access, and approvals that become clicks.

Raise autonomy only on a clean track record, with someone outside the agent's team signing for actions that reach other teams. Reopen the record whenever the agent or the people around it change, and keep a pullback ready that drops one kind of action back to sign-off while the rest of the agent's work keeps running.

None of these steps needs a new team. Autonomy settings live next to the agent's owner and grants, and the evidence for a raise comes from the approval history you keep today. Reopen triggers for owners and the people behind an agent ride on the joiner, mover, and leaver events you already track for employees, so autonomy gets a second look whenever one fires.

What does agentic AI governance decide that access controls don't?

AI agent access control decides what an agent can reach, and agentic AI governance decides how much of that reach it may use with no one signing off. Every agent has both dials. Reach covers the agent's own grants plus whatever it borrows from the person it works for. Identity programs are built to trace it, and you can follow the ways an agent gets its access with controls you already run.

Autonomy usually lives in a vendor default or an engineer's local config, where no review can see it. A read-only agent that never asks can do less harm than an admin-capable agent that checks in before any change. Agentic governance that watches only reach is reviewing half the decision.

Researchers at the University of Washington draw the same line in an essay for the Knight First Amendment Institute at Columbia University. Autonomy, they argue, is a design decision separate from how capable an agent is, so a highly capable agent can be built to run with very little of it. They sort agents into five levels of autonomy and propose certificates that cap an agent's level, which a change to its model, tools, or environment can void. Those levels rate a whole agent, while in practice the dial has to be set one action at a time.

Some companies already put an autonomy condition on the AI they buy for identity work. When Netskope looked for AI to automate role mining and simplify access analysis, it asked for people to stay in the loop. Its story describes Lumos using assignment data, usage data, and business context to build access policies while keeping humans in the loop for high-risk scenarios. The rest of your agents deserve a condition like that, written into your AI agent access policies.

Deciding which agents may run, and who signs for each kind, belongs to your operating model for enterprise AI agent governance. Autonomy is what you govern after that approval. Start by picking your five busiest agents and writing down which actions they take today without asking anyone.

Five ways AI agent autonomy drifts after you approve an agent

The autonomy you approve is rarely what an agent ends up with, because five routes widen it without anyone filing a change. Research Anthropic's Societal Impacts team published in February 2026 shows the first route clearly. In Claude Code, new users (under 50 sessions) ran with full auto-approve in about 20% of sessions, while users past 750 sessions did so in more than 40%.

Runs got longer too. The longest turns (the 99.9th percentile) grew from under 25 minutes to over 45 minutes between late 2025 and early 2026, smoothly across model releases. Capability rose too: on internal users' hardest tasks, Claude Code's success rate doubled between August and December, while average human interventions per session fell from 5.4 to 3.3.

The authors call the distance between what models can handle and what people let them do a "deployment overhang." Experienced users also interrupt more often, shifting from approving each step to watching and stepping in, a reasonable way to trust an agent that's earned it. People grant that trust one session at a time, though, and nothing your program can read shows where it landed.

That's where agentic AI risk management breaks down. Three more routes work the same way, and the drift table lays out all five.

‍

The first three rows show up only in what the agent does, so they need a log of its calls. In the coding agents it supports, Lumos MCP Governance records every call with the tool, the server, the inputs, the person behind it, and the policy decision, including Bash commands, file edits, and browser use. An unapproved server surfaces there the first day an agent calls it, while prompt settings and run length have to come from the agent client itself.

The fifth route is the hardest to see, because the approval still happens. A person who can't see what a request does approves it anyway, and the University of Washington researchers call the result rubber-stamping. Our Entitlement Analyst translates permissions into plain English so approvers can see what a grant allows, and our user access review software gives reviewers usage patterns and prior decisions for the same reason. Every rubber stamp is autonomy nobody granted.

Strays are a different problem. Agents that leave the approved path get caught with a time-to-notice number, the last of the AI agent governance best practices, while drift happens on the path itself. To measure drift on your busiest agent, pull last month's actions, count how many ran with no one signing off, and check that number against the conditions you set at approval. Track the human approval rate beside it for the fifth route.

Record AI agent autonomy for each kind of action

You can't tell whether an agent's autonomy has drifted unless someone wrote down what it was, action by action, with a name next to each setting. A typical agent record lists the agent, its owner, and its access, and none of those fields says how much it may do without a person. These six fields belong in your AI agent registry, on the same record as the owner and the grants.

‍

Start each action class at the default your approval matrix sets for its risk, which auto-approves some reads and holds anything irreversible for a sponsor. That matrix belongs to AI agent identity and access management and says where a class should start. The record says where it sits today and who moved it there.

We run our own agents this way, inside our identity governance software. In Lumos's Identity Agent Force, people set the policies, guardrails, and approval thresholds the agents apply, and each job carries its own setting. The Access Review Agent certifies safe access on its own and brings people only the items that need a human call, while the Role Mining Agent drafts roles for a person to approve. The Access Request Agent revokes a grant by itself when its time runs out, so the actions that keep or narrow access run alone and the ones that change roles wait for a person.

The record also gives you the number worth reporting, which we call the autonomy gap. It counts actions an agent took without sign-off in action classes where the record requires it. It should be zero. Treat any nonzero row as a drift finding with an owner to call, and start by adding the six fields to your five busiest agents this month, with the gap reported beside them.

When should an AI agent get more autonomy?

An AI agent should get more autonomy when it has a clean track record on one kind of action, that action can be undone, and a named person signs the raise. That's how a new hire earns signing authority, one kind of decision at a time. We want agents doing more without a person, because sign-off on every routine action is how approvals turn into clicks, yet today most raises happen one auto-approve setting at a time.

Keep this dial apart from the reach dial. Probation for new agents, a standard answer to how to secure AI agents, decides when an agent's grants grow. Governing agentic AI also means deciding when a person can step out of the way, in its own field on the same record. Treat the evidence below as starting defaults to tune to your risk.

‍

These are the thresholds we'd start with, and anything touching money, customer data, or access deserves tighter ones, such as the scored shadow period that agentic AI governance best practices call for. Fifty clean sign-offs is a modest bar on purpose. The trial window and the rollback catch what a short track record misses.

Chegg treats automation as a number to move on purpose. Lumos is now the number one ticket closer on its IT team, and the team has set a higher share for Lumos to resolve without a person as its next target. Autonomy should grow for agents the same way, toward a target someone owns, raised as the evidence comes in.

Pick one reversible, routine action class your busiest agent handles and start its track record this week. Name the person who'll sign the raise before the first sign-off counts.

Six triggers that send an AI agent back to sign-off

An autonomy decision holds only for the agent you approved, so any change to the model, its tools, or the people around it reopens it. The certificates in the University of Washington essay lapse when an agent's model, tools, or environment change. People-side changes belong on the same list.

Autonomy an agent stops using should also lapse without waiting for a trigger, the way unused access does. With Lumos, Checkr employees request an app for a set period, such as Lucidchart for a month-long project, and inactivity workflows reclaim licenses people stop using. Apply the same logic to an agent, so an action class it hasn't exercised in 90 days drops back to sign-off automatically.

Six triggers should reopen the record, three about the agent and three about the people around it. A reopened record drops each affected action class back to sign-off until the owner confirms it.

1. The agent gets a new model or version

A new model or agent version can run longer and do more per task than the one you approved, so the record's unattended limit and action classes need a fresh look. The owner can confirm a minor change, such as a point release of the same model, with a signature alone.

2. The agent picks up a new tool or server

A new MCP server, connector, or skill widens what an approved agent can do without anyone approving the addition. Start the tool at sign-off until the agent's owner approves it, and check whether it reaches data the original approval never covered.

3. The same kind of agent fails in public

A public incident involving an agent like yours is evidence about yours, even before anyone confirms the details. Hold the action classes the incident touched at sign-off until the owner checks that the same failure can't happen in your setup.

4. The owner leaves or changes roles

With its owner gone, an agent has no one to sign its raises, confirm its changes, or answer for what it does alone. Name a new owner before anything else, because every other trigger on this list routes to that person.

5. The person behind the agent changes roles

An agent that borrows a person's access gains or loses reach whenever that person changes roles. Lumos lifecycle workflows grant, adjust, and revoke access as HRIS events fire, with Albus, our identity AI agent, watching role, department, manager, and status changes. Send the mover event for the person behind an agent to that agent's record too, alongside the joiner, mover, and leaver triggers that AI agent lifecycle management sets for the agent itself. Wire it before the other five, since nobody files a ticket when a person's role changes.

6. Approvals slide into clicks

Approvals that arrive in seconds and almost never change the request are the fifth drift route, and they mean sign-off has stopped doing its job. A median approval time under 10 seconds for a month is a fair threshold, and crossing it should move routine approvals into rules so the rest get read.

How do you pull back AI agent autonomy without a kill switch?

You pull back AI agent autonomy by dropping one kind of action to sign-off or deny across all agents of the same kind, while the rest of their work keeps running. Make that your first move, ahead of any kill switch. A kill switch also stops the reads and routine work that were going fine, so teams hesitate to pull it, and every minute of hesitation is a minute the agent keeps acting.

The EU AI Act expects both kinds of control for high-risk uses. Article 14 of the Act calls for oversight commensurate with the risks, the level of autonomy, and the context of use. The AI has to let the people assigned to oversight override or reverse its output, interrupt it through a stop button or a similar procedure, and stay alert to over-reliance on it, which the Act calls "automation bias."

The fifth drift route is automation bias in practice. These oversight rules cover high-risk uses such as screening candidates or scoring credit, and the EU's Digital Omnibus amendments moved them for those uses to December 2, 2027. Most of your agents fall outside that scope, and agentic AI oversight still needs the dial for them.

For the coding agents it supports, MCP Governance puts that dial in front of the tool calls themselves. Each call goes to Lumos for an allow or deny decision before it runs, so a policy change applies on every agent's next call without anyone touching a client config. MCP Governance returns allow or deny, so turning the dial down there means denying that class while other classes keep running, ideally with a deny that tells the agent and the person what to do next.

Run the pullback in a fixed order. Drop the affected action class to sign-off or deny for all agents of that kind, keep reads running, and tell the owners why. Restore autonomy only through the evidence that raised it, starting the track record over.

Decide now which action class you'd pull first for each kind of agent. Then rehearse the pullback on one you'd be willing to slow for an hour.

Govern AI agent autonomy so your agents can earn more of it

Your business wants agents doing more without a person, and security can grant only the autonomy it can see, attribute to a person, and pull back. Write down the autonomy you granted this month, start a track record on one routine action class, and rehearse a pullback before you need one.

Do those three things and the next request for more autonomy gets a real answer, with evidence behind it and a name on it. Good governance was never about keeping the dial low. It's about knowing where it sits for every action, and who turned it.

The next request for more autonomy will arrive with a deadline, and your answer depends on knowing whose access each agent spends and what it already does alone. Lumos maps every agent’s access to the person behind it and records each tool call from the coding agents it supports, with the policy decision beside it. Our own identity agents run the same way, under thresholds people set. Book a demo to see your agents mapped to the people behind them before that request lands.

‍