An agent can inherit authority from a user, service account, API token, connector or another agent. Its written role may therefore be narrower than its effective permissions. Governance must reconstruct what the agent can actually reach and do.
Give the agent a governable identity
A distinct workload identity makes activity attributable and revocable. Shared credentials weaken both control and evidence. Buyers should ask whether agent actions can be separated from the human who initiated the task and from the platform that executed it.
Manage the non-human identity lifecycle
Create the identity for an approved purpose, bind it to the agent and owner, issue scoped credentials, rotate them, suspend access during investigation and revoke them at retirement. A disabled application record is not enough if tokens, service accounts or downstream permissions remain active.
Map effective authority
Review direct permissions, inherited group access, delegated user rights, connected tools and the permissions of downstream services. Then distinguish read, create, modify, approve, publish and delete actions. The result should be a map of possible action, not only configured intent.
Trace delegated authority
Preserve the chain from human or service requester to parent agent, specialist agent and tool. Each step may narrow authority but must not silently expand it. Correlation data should allow a reviewer to connect the initiating request, approval, downstream token and final action.
A service agent asks a specialist agent to issue a refund. Show the initiating user, both agent identities, the permitted value, approval decision, tool credential and final transaction in one trace.
Design bounded autonomy
- Use least-privilege tool access and short-lived credentials.
- Require approval for irreversible or high-impact actions.
- Limit transaction size, destination and frequency.
- Separate planning from execution where practical.
- Prevent an agent from modifying its own limits.
- Log the request, decision, tool call and result.
Protect credentials and tokens
Assign credential ownership, store secrets outside prompts and agent memory, restrict audience and scope, use short duration where possible and rotate on change or incident. Test whether a platform can identify credentials associated with a retired or unowned agent.
Review and revoke access
Review access periodically and after owner change, new tools, wider data, role change, inactivity, incident or failed control. Revocation should reach the identity provider, connectors and target systems rather than updating only the governance record.
Treat change as a new decision
New tools, connectors, prompts, models and delegation paths can materially expand authority. A governance platform should detect or record these changes and trigger reassessment rather than assuming an old approval still applies.
Test Identity Controls in a Vendor Demonstration
| Identity/control question | Expected control | Evidence | Failure condition |
|---|---|---|---|
| Who is acting? | Distinct agent and upstream requester identity | Correlated authentication and action record | Shared service identity hides the actor |
| What may it do? | Effective permissions across tools and inherited access | Permission map and tested action | Configured role omits downstream authority |
| How is delegation limited? | Scope, value, time and action boundaries | Token claims, policy and enforcement result | Child agent receives unrestricted parent access |
| Can access be removed? | End-to-end suspension and revocation | Failed post-revocation action and updated record | Existing token continues to work |
Use the agentic AI governance playbook to place these tests inside the full pilot-to-production process.