Enterprise security has spent decades answering an essential question:
Who is allowed to access this system?
Identity and access management systems answer that question by authenticating users, assigning roles, enforcing permissions, and recording access. Those controls remain necessary as organizations introduce AI agents into operational environments.
But they do not answer a second, increasingly important question:
Should this particular action be performed on this particular target right now?
That is the distinction between access control and execution governance.
IAM determines an identity’s potential authority. Execution governance determines whether exercising that authority is appropriate under the current circumstances.
For human users, organizations have traditionally relied on training, procedures, peer review, change-management processes, and professional judgment to bridge that gap. An administrator may possess permission to restart a production service, but that does not mean every restart is justified.
AI agents make this gap much harder to ignore.
Valid access does not make an action valid
Consider an AI operations agent tasked with restoring an unavailable application.
The agent detects that a service is not responding. Its credentials allow it to connect to the affected server, inspect the service, and issue a restart command. From an IAM perspective, everything appears correct:
- The agent has a recognized identity.
- Its credentials are valid.
- Its assigned role permits service management.
- The target falls within its authorized environment.
- The command is technically allowed.
But several operational questions remain unanswered:
- Is the service actually unhealthy, or is the monitoring signal stale?
- Is the server currently undergoing planned maintenance?
- Is the service part of a clustered application that requires a specific restart sequence?
- Could restarting it interrupt an active deployment or database migration?
- Has the agent already attempted this action several times?
- Could the restart increase the incident’s blast radius?
- Does the action require human approval during this time window?
- What evidence will establish that the application recovered afterward?
IAM can establish that the agent is permitted to restart the service.
It cannot, by itself, establish that restarting the service is the correct action at that moment.
Potential authority versus situational authority
Traditional permissions generally describe what an identity may be allowed to do across some defined scope.
An administrator might have permission to manage every service on a group of servers. An automation account might have broad access because its workflows could require several different operations. An AI agent may inherit the permissions of the person or service account under which it operates.
This is potential authority.
Execution governance evaluates whether that potential authority should become active authority for a specific operation. It considers the action in context:
- The requesting identity
- The operation being requested
- The intended target
- The target’s current state
- The reason for the action
- The expected impact
- The applicable policy
- The required approvals
- The permitted time window
- The evidence needed to verify the result
The distinction matters because risk does not reside only in access. Risk also resides in the combination of who, what, where, when, why, and under which conditions.
A production restart at 2:00 a.m. during an active outage may be appropriate. The same restart at 2:00 p.m. during peak transaction processing may require additional review. The identity, permission, target, and command could be identical while the operational decision is completely different.
Why human-centered controls do not transfer cleanly to agents
Most enterprise controls were designed around human behavior.
A human administrator is expected to interpret ambiguous conditions, recognize unexpected consequences, follow change procedures, and stop when the environment behaves differently from expectations. Even then, organizations add safeguards such as peer review, privileged access management, maintenance windows, and incident escalation.
An AI agent introduces a different operating model.
It can act continuously, execute quickly, interact with many systems, and repeat an operation across numerous targets. It may also produce a confident but incorrect interpretation of an incomplete signal.
If an agent is given the same standing access as a human administrator, the organization may unintentionally give it the ability to convert a reasoning error into an infrastructure change.
Limiting credentials helps, but it is not enough. A narrowly permissioned agent can still perform the wrong permitted action.
The problem is no longer simply unauthorized access. It is authorized but inappropriate execution.
Approval alone is not execution governance
A common response is to require a person to approve high-impact actions.
Approval gates are useful, but a generic approval button can create only the appearance of control. An approval is meaningful only when the reviewer understands exactly what is being authorized.
A strong approval should be bound to:
- A specific operation
- A defined target or target set
- The evaluated impact
- A stated justification
- A limited time window
- The policy conditions under which execution may proceed
If any of those elements change, the approval should no longer be valid.
An approval for restarting one service should not become reusable authority to restart several services. Approval for a tested target set should not remain valid if additional targets are added later. Approval granted during an incident should not become standing permission for unrelated future actions.
Execution governance must make approval precise, constrained, and non-transferable.
Logging an action is not the same as governing it
Organizations may also rely on audit logs to provide accountability. Logs are important, but they primarily describe what a system recorded.
An audit entry might show:
- The agent requested an operation.
- The policy engine permitted it.
- A command was dispatched.
- The command returned exit code zero.
- The agent reported success.
That history does not necessarily prove that the desired operational outcome occurred.
A service manager may accept a restart command even though the application never becomes healthy. A deployment script may complete while some instances continue running the previous version. A firewall command may succeed syntactically while the intended traffic remains blocked.
The agent’s own report is also not independent evidence. If the same actor chooses the action, performs it, and declares it successful, the audit trail may only prove that the actor believed its work succeeded.
Governed execution therefore requires outcome verification that is separate from command completion.
Evidence must describe the resulting state
A governed operation should begin with an observable precondition and end with independently collected evidence.
For a service restart, that evidence might include:
- The service entered the expected running state.
- The process remained stable for a defined period.
- The application health endpoint responded successfully.
- Dependent services remained healthy.
- Error rates returned to an acceptable range.
- No prohibited configuration drift occurred.
- The verified state matched the requested outcome.
This changes the meaning of success.
Success is no longer “the command ran.” It becomes “the intended state was achieved, verified, and recorded.”
If verification fails, the system should not silently label the operation successful. It should return a distinct outcome such as failed, partially completed, inconclusive, or awaiting review.
Governance should exist at the moment of action
Static policy reviews and periodic access certifications remain useful, but AI execution decisions occur in real time.
An agent may be permitted to inspect thousands of resources while being allowed to modify only a carefully constrained subset. Its authority may need to change based on the environment, the detected condition, the operation’s impact, and the presence of an active approval.
Execution governance should evaluate each consequential action immediately before it occurs.
A governed execution decision might ask:
- Is the requesting identity authenticated?
- Is the requested operation supported?
- Is the target within the authorized scope?
- Does current evidence satisfy the operation’s preconditions?
- What resources could be affected?
- Does policy permit this action under current conditions?
- Is human approval required?
- Is that approval bound to this exact operation, target, and time?
- What conditions require execution to stop?
- How will the resulting state be verified?
This decision cannot be reduced to a single permission check because it depends on live operational context.
The goal is bounded autonomy
Execution governance does not mean that every AI action should wait for a human.
That would eliminate much of the value of operational automation and eventually overwhelm reviewers with routine decisions.
Instead, organizations should define graduated levels of autonomy.
Low-risk, reversible operations with narrow impact and reliable verification may execute automatically. Moderate-risk operations may proceed only within an approved scope or maintenance window. High-impact or irreversible operations may require explicit human authorization or remain prohibited entirely.
For example:
- Reading service status may execute automatically.
- Restarting one noncritical service may be allowed after defined health checks fail.
- Restarting several production services may require approval.
- Changing identity policy may require multiple reviewers.
- Destructive data operations may remain outside the agent’s authority.
The objective is not unrestricted autonomy or universal human intervention. It is bounded autonomy supported by policy, context, evidence, and enforceable limits.
A new control layer is emerging
As AI agents move from answering questions to changing infrastructure, organizations need controls that operate between an agent’s intent and the systems it can affect.
That layer must do more than authenticate the agent. It must govern execution by evaluating the proposed action, binding authority to an explicit scope, enforcing approval requirements, limiting potential impact, recording the decision, and verifying the outcome independently.
IAM remains the foundation. Agents still require identities, credentials, roles, and access boundaries.
But identity establishes only who or what may potentially act.
It does not determine whether a specific action is safe, justified, and appropriate now.
That is the role of execution governance.
The central question for enterprise AI is therefore changing.
It is no longer enough to ask:
“Can this agent perform the operation?”
Organizations must also ask:
“Should this operation happen, against these targets, under these conditions, at this moment—and how will we prove the intended outcome occurred?”
That is the difference between giving an AI agent access and trusting it with execution.
Resource Shell, or resh, is being developed to explore this governed-execution layer for AI-assisted infrastructure operations. Its focus is on constrained authority, policy-enforced execution, bounded impact, durable evidence, and independent outcome verification.