Your auditor's sample this quarter includes one line from the identity provider log: at 2:14 a.m., the service desk agent added a contractor to a group that grants production access. The agent had permission to make the change. Months earlier, your team let it reset passwords without review after its suggestions kept matching your analysts' calls, and a platform engineer later connected it to group management so it could close access tickets too. The auditor wants to know who decided it could add people to groups without asking, and the honest answer is that no one did.

Agentic AI governance best practices are the routines that decide which decisions an AI agent may make without a person, on what evidence, who answers for each one, and when that permission ends. Autonomy is the newest entitlement in your environment, and it often arrives as a side effect of a mode switch, a new tool, or a vendor default. The practices that hold grant it one decision at a time, make agents earn it, record what they decide, certify it every cycle, and take it back when its evidence changes, which is the discipline your identity team already runs for access.

The five practices below all come back to the question at the heart of agentic AI governance: who let an agent act without asking, on what evidence, and who answers for it. They pick up where program-level AI agent governance best practices leave off, because an inventory, named owners, and AI agent access policies still don’t say what an agent may decide without a person. The practices build on one another, so the grant you write in the first is what the other four test, record, certify, and take back. Each one comes with something you can adopt as written, from a grant record and promotion bars to log fields, a review step, and demotion triggers.

1. Grant AI agent autonomy one decision at a time, like any entitlement

Grant an AI agent autonomy one decision at a time, like any entitlement, because one that can safely reset a password alone may be nowhere near ready to add someone to an admin group. If your program sets autonomy once per agent, as a mode, an auto-approve switch, or a tier, every tool or scope added later inherits autonomy nobody granted for it. That's how the service desk agent got from passwords to groups.

Access decides what an agent can do, and autonomy decides which of those things it does without asking. Of all the agentic AI governance best practices, this is the one the others hang on, because you can't earn, record, certify, or revoke a grant that was never written down.

Gartner made a version of this argument in a May 2026 prediction. It expects 40% of enterprises to demote or decommission autonomous AI agents by 2027 over governance gaps that surface only after production incidents, and it blames uniform governance applied to agents with very different autonomy. Gartner matches controls to each agent's autonomy level, and we'd go one step finer, since a single agent often spans several levels at once.

Albus, our identity AI agent, already sorts human access this way. When it mines roles from HR attributes and usage data, it groups access into four tiers: universal, birthright by attribute, requestable with approval, and restricted under tight controls. An agent's decisions map onto the same tiers. In the grant column below, universal and birthright decisions become ones the agent makes alone, requestable ones become recommendations a person approves, restricted ones stay with people, and one middle step covers decisions it makes and reports right away.

Write one row per decision, the way you'd write an entitlement. The rows are starting examples to tune, and "sampled" means a person checks a random sample of what the agent decided alone.

‍

One agent can hold very different grants. In Lumos's Identity Agent Force, the Access Review Agent certifies safe access on its own and escalates only the decisions that need a person, so it acts alone on one class of decision and hands the other to a reviewer. Intercom runs its people's access requests on the same split, with policies set by app and role that grant low-risk requests instantly and send sensitive access to an approval workflow. Agents need that split too, with a human in the loop wherever the stakes call for one.

In AI agent identity and access management, how far an action reaches and whether it can be undone decide where human approval belongs for agent actions. The grant row is where you write that answer down, decision by decision, with a name next to it.

List every decision your busiest agent made without a person last week. Write a grant row for each one before anyone adds another tool.

2. Use AI agent evaluation metrics to decide when an agent can act alone

An agent should earn each decision the way a new analyst earns signing authority, by making the call alongside the person who makes it today, and the evaluation metrics from that side-by-side run decide when it can act alone. If your engineers have switched an agent to auto-approve after a few good weeks, they've already run an informal version of this, minus the record and the probation step teams use when working out how to secure AI agents.

Medicine has a name for the formal version. In a silent trial, a clinical AI model makes predictions on real patients in real time while clinicians decide as usual without seeing them, so the model gets scored on live work before it can change anyone's care. A research team writing in Frontiers in Digital Health ran one on a model that predicts a kidney blockage in infants. It had scored 0.90 in development and fell to 0.50 on live patients, on a measure where 0.5 is no better than a coin flip.

The cause was drift the development data never showed, since patients' ages, which kidney was blocked, and the imaging format had all shifted. Once the team corrected for it, the model scored 0.85 to 0.91 on two separate silent-trial datasets. Governing agentic AI calls for the same discipline, because an agent that tests well on last quarter's tickets can still fail on this week's, and only a side-by-side run on live work will show it.

Our own review agent moved along this path in public. When we launched agentic access reviews in December 2025, Albus ran the first pass and recommended what to keep or remove with a reason for each, and reviewers acted on every recommendation. By June 2026, our review agent certified safe access without a reviewer and escalated the rest, and customers can start Albus in copilot mode, where every recommendation waits for a person, to run the same comparison on their own data.

Score that side-by-side run, often called a shadow period, before anyone switches autonomy on. Pick a decision your team makes at least 200 times a month, so one month gives you enough to score, and treat the bars below as starting points to tune, since none of them is an industry benchmark.

‍

A 97% agreement rate can hide the only errors that matter, so score the direction that costs you most on its own line. An agent that's too cautious costs you time, and an agent that says yes where your people said no costs you an incident.

These measures do one job, which is deciding promotion. Once an agent acts alone, the policy engine that rules on its calls needs decision metrics for AI agent access control of its own.

3. Keep AI agent audit logs that explain every decision made without a person

An AI agent's audit log should let someone check any decision the agent made without a person in about a minute, from the evidence it used and the rule it applied. The agent's own account of why it acted belongs in that log, but it can't be the part you rely on. Logs that show what an agent did while leaving out who allowed it are one of the core agentic AI governance challenges.

OpenAI's 2023 white paper on practices for agentic AI makes legibility of agent activity one of its practices. It also warns that an agent's visible reasoning can't yet be fully relied on, since models sometimes don't rely on the reasoning they show, and that an explanation requested after the fact is likely to be made up. It suggests a ledger of actions as a lighter touch than approvals, and says actions reviewed only afterward should be easier to undo than actions that need approval first.

Build each log entry around the evidence and the rule, and give the agent's narrative one field in it. Each entry should hold the following.

• The decision and the class it belongs to
• The autonomy grant in force, with its version
• The inputs and evidence the agent used
• The rule or policy version it applied
• Its reason, in plain language
• What would have made it escalate
• Who answers for that decision
• The undo path and its deadline
• The outcome, including whether anyone reversed it

Our review agent keeps reason and evidence side by side. Since that December launch, Albus has given a plain-language reason for each recommendation, such as "User hasn't logged in for 90 days" or "Matches peer group usage," after weighing role, department, access sensitivity, last activity, peer-group fit, and separation-of-duties conflicts. In Lumos user access review software, every decision is stored as audit evidence. That's the shape to copy for every agent, with the reason stored next to the evidence and the decision it explains.

For the coding agents it supports, MCP Governance records each tool call with the tool, server, inputs (stored by default), the person behind it, and the policy decision, and it never stores prompts, model responses, or tool results. At ChargePoint, audit reports come out of Lumos with one click, and the IT team sums up the result as "Happy IT team, happy auditors." A record built as the work happens never has to be rebuilt before an audit.

Chains of agents need one more step. When a decision passes through several agents, the record has to follow it from the person who asked to the last tool call, and tracing a decision across a chain of agents needs an ID that ties every hop together.

Pull ten decisions an agent made alone last week and time how long it takes to explain each one from the records. Any decision that takes longer than a minute is missing a field.

4. Bring agentic AI risk management into every access review cycle

Agentic AI risk management belongs in your access review cycle, because autonomy you granted last quarter needs the same certification as access you granted last quarter, signed by the person who owns the decision. Bank regulators made clear this year that you'll have to build the method yourself.

On April 17, 2026, the Federal Reserve, OCC, and FDIC issued SR 26-2, replacing the model risk guidance banks had run on since 2011. A footnote places generative and agentic AI models outside its scope, describing them as novel and changing fast, and leaves each institution to govern them through its own risk management. The guidance is most relevant to banks above $30 billion in assets, but its method fits any team that lets software make decisions.

That method covers traditional models and AI that isn't generative or agentic, and it maps cleanly onto autonomy. Outcomes analysis compares outputs with real-world results, reviewers need the expertise, independence, and standing to bring about change, rigor scales with materiality, and persistent slippage past an institution's own thresholds may warrant adjustment, recalibration, or redevelopment. Bank regulators kept that method for older models and left agents to each bank, so applying it to autonomy is your job.

Put every autonomy grant into the same certification campaign as the agent's access, and route it to the person who owns the decision. The team that built the agent shouldn't certify it, since that team benefits from the agent's speed. Give the certifier a random sample of decisions the agent made alone, sized to what a wrong one costs, along with the reversal rate, any costly misses, and every disagreement since the last cycle. The outcomes are keep, narrow, return to recommend, or retire.

Lumos access reviews put people, service accounts, and other non-human identities in one campaign, and delta reviews show only what changed since the last cycle. That's where autonomy grants belong too. Until your identity governance software tracks autonomy as its own review item, attach each grant to its agent's line with the sample as evidence, which keeps agentic AI oversight in the campaign your certifiers already run.

Chegg put approvals with the managers who know the work. Its IT team delegated administration to managers while keeping every approval path SOX-compliant, with every request tracked in Lumos audit logs. As Chegg's story puts it, "My team is no longer the mediator between app requesters and approvers." Certification works best with that split, where the decision's owner signs and IT keeps the record.

The rest of the procedure carries over from how you certify AI agent access today. The only new inputs are a named owner for each decision your agents make alone and last cycle's sample for each one.

5. Return AI agents to recommend mode when their model, tools, or rules change

An autonomy grant rests on evidence about one agent's model, tools, and rules, so when any of them changes, that decision returns to recommend mode until the agent earns it again. The group-management connection in the opening example should have sent the agent's new group decisions to recommend on day one, while its password resets kept their grant because nothing they rested on had changed. Demotion works per decision, and the agent keeps working.

Our CEO, Andrej Safundzic, has argued that an agent needs a domain "brain" that knows its goal, the tools it may call, and the rules it must follow. A change to any of the three should send the affected decisions back to be re-earned, and so should a handful of other events.

Most of those events never reach a change queue, so write them into every grant record. Each of these should drop the decision back to recommend.

• A new model or model version
• A new tool, scope, or data source
• A change to the policy the agent applies
• The decision's owner leaving or changing roles, a mover or leaver event your AI agent lifecycle management should already catch
• A reversal rate past the bar in the grant, or any costly miss
• A public incident involving the same kind of agent, at least until someone reviews it

Re-earning takes less time than the first promotion, since the history exists, so a shorter shadow period is enough unless the change touched the decision itself. Grants should also end on their own. Lumos's Access Request Agent grants access for as long as it's needed and revokes it automatically, and an autonomy grant should carry an end date in the same spirit.

In Roku's story, Lumos could automatically move a paid Zoom license holder who attends meetings but never hosts to a free license, cutting cost with no hit to productivity. Weaker evidence should move autonomy down just as gently, to the tier the evidence supports, while the agent keeps doing the work it still has evidence for.

Wire the first trigger, a model or tool change, into your change process this quarter. It's the one most likely to fire without anyone noticing.

Make best practices for agentic AI governance part of your next review cycle

Your next access review cycle is the place to start, because the pressure to let agents decide more won't ease, and sooner or later an auditor will ask who decided they could. The teams with an answer will be the ones that treated autonomy the way they already treat access.

These practices don't slow agents down. An agent with a written grant, a scored record, and a certifier behind it can take on new decisions faster, because each new grant arrives with evidence someone already trusts. Autonomy should be something you granted, not something you found.

Lumos gives you agents that certify safe access on their own and escalate the rest, a plain-language reason behind every recommendation, a record of every tool call from the coding agents it supports, and reviews that put people, service accounts, and other non-human identities in one campaign. See how Lumos approaches agentic AI security, or book a demo to put your first autonomy grants under review.

‍