An AI agent is deployed to help the finance team process invoices.
Six months later, the employee who sponsored it has moved to another role. The original project is finished. The agent still has access to the finance system, its credentials still work, and nobody is quite sure who can approve a change to its permissions.
The agent has access. But who owns the agent?
This is where agent governance becomes an identity governance problem.
Most organizations know how to assign ownership to employees. A manager approves access, HR triggers lifecycle events, and termination starts a deprovisioning process. The model is imperfect, but the accountability chain is understood.
AI agents do not arrive through HR. They appear through software deployments, experiments, automation projects, vendor integrations, and lines of code. Their lifecycle follows technical events rather than employment events.
That means the traditional joiner-mover-leaver model does not map neatly to them.
An agent needs more than a credential
It is easy to confuse an agent’s credential with its identity.
An API key, token, or certificate proves that something may connect. It does not explain what that thing is, why it exists, who is accountable for it, or whether it should still be running.
An agent identity should carry enough context to answer five basic questions:
- Who owns it? A named human sponsor and an accountable team.
- Why does it exist? A declared business purpose, not simply “automation.”
- What may it do? Specific applications, actions, data, and limits.
- When should it be reviewed? A review date tied to the risk and purpose.
- How is it stopped? A tested way to revoke its credentials and terminate its activity.
If any of these answers is missing, the organization does not have a governed agent. It has an orphaned identity waiting to happen.
Ownership cannot be a free-text field
Many identity inventories technically include an owner. In practice, that owner may be the developer who ran the first deployment, a shared mailbox nobody monitors, or a team name that disappeared during a reorganization.
That is not accountability.
The human sponsor should be responsible for confirming that the agent still serves a valid business purpose. The technical owner should be responsible for how it operates. The application owner should decide which actions the destination system will accept.
These may be different people, but the relationships should be explicit.
Ownership should also be transferable. If the human sponsor changes roles or leaves the organization, the agent should not quietly continue under stale approval. It should move to a new accountable owner or lose its authority.
Review the purpose, not just the permissions
Traditional access reviews ask whether an identity still needs a particular entitlement.
For an agent, that question is too narrow.
An agent can hold individually reasonable permissions and still use them in a sequence that creates unacceptable risk. A purchasing agent might be allowed to read vendor records and create purchase requests. That does not mean it should also be able to change bank details and release payment.
An effective agent review should therefore ask:
- Does the original business purpose still exist?
- Is this the same agent behavior that was approved?
- Are its connected tools and applications still necessary?
- Has it created or delegated work to other agents?
- Are its credentials short-lived and attributable?
- Can its recent actions be traced back to a human request?
- Has the shutdown process been tested?
The goal is not to certify a list of permissions. It is to certify the continuing relationship between purpose, authority, behavior, and ownership.
Every agent needs an expiration condition
Human access has a natural lifecycle anchor: employment.
Agents need an engineered one.
Some agent identities should expire when a task ends. Others may remain active for a project, contract, or application lifecycle. Long-running agents should have recurring reviews and credentials that expire independently of the agent itself.
The important point is that “until someone remembers to remove it” is not a lifecycle policy.
At minimum, an agent should lose access when:
- Its business purpose ends
- Its sponsor leaves or can no longer attest to it
- Its connected application is retired
- Its behavior materially changes
- Its ownership cannot be established
- Its review becomes overdue
Expiration is not operational inconvenience. It is how the organization forces accountability back into the system.
The inventory is the beginning, not the control
Organizations will need a registry of agents: identity, owner, purpose, connected applications, permissions, credentials, review dates, and recent activity.
But an inventory only tells us what we believe exists. It does not stop an agent from acting outside that belief.
The registry has to connect to enforcement. Overdue review should affect access. Lost ownership should trigger restriction. Revocation should reach every credential and delegated child agent. Applications should be able to distinguish the human principal from the machine actor.
Otherwise, the registry becomes another dashboard that is accurate only on the day it was created.
The accountability question comes first
The industry is spending a great deal of time asking what AI agents can do.
Identity teams should ask a more uncomfortable question:
When this agent takes an action six months from now, who will still be accountable for it?
If the answer is unclear, the agent is already over-privileged. Not necessarily because it has too many permissions, but because it has more authority than the organization’s accountability model can support.
Before an agent receives access, give it an owner. Give it a purpose. Give it an expiration condition. And make sure someone knows how to turn it off.
