A 200-person company runs on Microsoft 365 and Entra. An AI agent flags an account that looks inactive and decides disabling it would cut unnecessary access. It knows how to make the change, and it has the access to do it.
What it doesn’t know is that the account belongs to a contractor whose contract was extended yesterday. Or that it’s a service account that only runs once a month.
That’s the AI agent governance gap: ability and access don’t add up to authority.
AI agent authority is different from access
An agent can understand the problem and know the next step. It can even have the permissions needed to carry that step out.
That still doesn’t answer whether it should.
In the inactive-account example, the identity system may only tell part of the story. The person’s employment status could have changed. There could be a business owner who still needs the account. A company policy could require someone to approve the change first.
The agent needs a limit on when it can use that access.
Give the agent one job and only the access it needs
For an identity workflow, that job can be narrow: review a specific Entra environment, look at a defined set of identity and access data, and surface accounts that need attention.
If the agent only needs to review information, it doesn’t need permission to change it.
And if it eventually needs permission to take one action, that shouldn’t turn into broad administrative access across the environment.
As agents connect to more systems, the problem gets harder. An agent can read identity data, open a ticket, notify a manager, and trigger another workflow somewhere else.
Every connection adds to what the agent can do. None of them automatically adds to what it’s allowed to do.
Decide what the agent can do without asking
Some actions are low risk. Others affect someone’s access to the systems they need to do their job.
An agent can gather evidence, prepare a recommendation, or open a ticket on its own. Disabling an account is different.
Some actions need a person’s approval. For others, a standing company policy already says when the action is allowed. Anything outside those rules gets escalated.
At a smaller company this can be simple: the same IT admin who owns the environment reviews the finding and approves the change.
Who approved disabling that account?
Once software can make a real change, teams need to be able to reconstruct what happened.
You should be able to see what the agent saw, why it recommended the action, who authorized it, and what changed.
If the wrong account gets disabled, the admin investigating the problem shouldn’t have to piece the story together from application logs, a ticket, and someone’s memory.
Check that the right account changed
An API call can succeed and the workflow can still be wrong.
After an authorized change, check the source system again. Confirm that the correct account changed and that its new status matches what was approved.
A success message from the API only says the request went through. It doesn’t say the right account changed.
Finding an issue, deciding what to do, making the change, and checking the result are separate steps. AI can speed up all four, but someone still has to confirm the last one worked.
How this relates to Trust Player Zero
We’re starting with identity and access risk in Microsoft Entra. Today, TPZ can read and surface portions of identity and access information. It doesn’t currently perform customer-side remediation actions in Entra.
The Beta is designed to move from evidence-backed findings toward customer-authorized remediation in Microsoft Entra, with independent read-back verification and retained evidence.
The point is to keep the finding, the decision, the action, and the proof in one place instead of scattered across tools and people.
Learn more about the TPZ Beta Product Program.
The mistake can happen before the action
Go back to that 200-person company. One administrator handles identity, endpoint security, cloud access, employee onboarding, and whatever urgent problem came up that morning.
Now the agent disables the contractor whose extension never made it into the identity system. The command succeeds, the contractor loses access mid-project, and the administrator has to work backward to understand why.
The agent did what its permissions allowed. Nobody had decided whether it should.
When agents can make real changes, teams need to know who approved the action and whether the change worked. Without that, automation can make the wrong call sooner.
