AI identity governance connects each agent to an accountable owner, an approved purpose and permissions that can be reviewed and withdrawn. Start by distinguishing the human requester, the agent workload and its downstream credentials. Then prove that access changes reach running jobs and connected systems.
This guide gives platform and security teams six checks for agents that read company data or take actions. Use the broader enterprise AI governance framework for platform requirements, then apply these identity tests to one workflow.
Last verified: October 27, 2026. Vendor behavior is attributed to the linked documentation; the test plan below is our proposed evaluation method.
Disclosure: ASCENDING Inc builds and maintains Jarvis, an open source project with registry and gateway components relevant to this category.
What AI identity governance must connect
An employee asks an agent to summarize an incident. The agent reads logs through a service identity and opens a ticket through a connector. Three separate questions follow: who requested the work, which workload executed it, and whose permissions authorized each operation?
Record the connections explicitly. A username in a chat transcript can’t explain a background action performed later with a shared API key.
| Record | Question it answers | Evidence to retain |
|---|---|---|
| Business sponsor | Why should this agent exist? | Named sponsor, purpose and review date |
| Technical owner | Who can repair or stop it? | Operating team, contact and suspension procedure |
| Agent or workload identity | Which running component acted? | Stable identifier and deployment environment |
| Delegation | On whose behalf did it act? | Requester, authorized scope and delegation expiry |
| Downstream grant | Which resource accepted the action? | Resource, permission, credential reference and decision |
| Release context | Which behavior was approved? | Agent version, skill revision and policy version |
This table is an assessment model, not a required vendor schema. Use stable identifiers as join keys and keep secret values out of the register.
AI identity governance starts with an accountable owner
AI identity governance check 1: separate sponsorship from operation
Name a business sponsor who can justify continued access and a technical owner who can operate the workload. One person can hold both responsibilities, but record both decisions.
Microsoft Entra Agent ID documentation distinguishes technical owners from sponsors responsible for business accountability. That’s a useful design pattern even when your agents use another identity system.
Acceptance test: give the reviewer an agent identifier. They should find its sponsor, operator, purpose and next review date without asking the original developer.
Check 2: bind access to the actual resource
Write the intended operations before requesting credentials. “Read production incident logs for service A” is reviewable. “Use the observability API” leaves the data and action boundaries unresolved.
NIST SP 800-207 describes zero trust around resources and explicit authentication and authorization. Apply that principle to each connected service, rather than treating an agent’s login as blanket approval.
Acceptance test: use an account that can read a record but can’t edit it. The agent’s attempt to edit the same record must fail through its production integration path.
Separate human delegation from workload access
Check 3: identify which principal survives the session
An interactive assistant might use user-delegated access. A scheduled job might use application permissions. Those paths have different owners, expiry rules and removal procedures.
For HTTP-based MCP authorization, the current MCP specification requires servers to validate that an access token was issued for their intended audience. That transport requirement doesn’t decide your business policy for a downstream action.
Our MCP OAuth guide for Entra ID and Okta explains those token boundaries. Extend the review to non-MCP paths, including direct SDK calls and local scripts.
Consider a proposed incident assistant:
- A support engineer requests a summary under their user identity.
- A worker reads only the approved incident’s logs using its workload identity.
- Creating a ticket requires the requester’s permission and an approved destination.
- An unattended retry retains the original request reference and its expiry.
If a retry instead inherits an unrestricted administrator key, the original user-level check no longer describes the effective access.
Acceptance test: let delegation expire during a queued job. Verify whether the next action is denied, pauses for renewed authorization or continues under separately approved application access.
An AI identity governance evidence record
Check 4: reconstruct one allowed and one denied action
Ask the platform team to export two events from a test environment. Each should identify the caller, workload, target resource, attempted operation, decision and time.
Join those events to the agent version, relevant skill revision and policy version. Avoid logging full prompts, credentials or source documents simply to populate an audit example.
For the incident assistant, the record should explain why reading service A succeeded and editing service B failed. A generic HTTP success code won’t answer that question.
A practical review record can use these fields:
agent_id: incident-summary
business_sponsor: support-operations
technical_owner: platform-on-call
access_purpose: summarize approved incident evidence
allowed_actions: read service-A logs; propose a ticket
write_approval: required before ticket creation
credential_reference: vault entry identifier only
review_due: next scheduled access review
evidence: allowed event, denied event, suspension resultThis is an illustrative template. It doesn’t represent an executed Jarvis deployment or a supported API payload.
Test removal and emergency suspension
Check 5: test identity, credentials and running jobs separately
Removing a user, revoking a grant and stopping a workload are different operations. Microsoft’s access-revocation guidance explains that effective removal can lag behind the initial administrative action.
Measure the actual window for your application. Don’t copy another system’s token lifetime into the runbook.
| Scenario | Attempt after the change | Expected evidence |
|---|---|---|
| Requester loses access | Resume the existing conversation and request a new action | Denial or renewed authorization requirement |
| Workload is suspended | Execute a queued operation | Work blocked at the relevant enforcement point |
| Connector grant is removed | Call the downstream service | Target rejects the operation |
| Skill is withdrawn | Try an already downloaded copy | Local behavior recorded; backend permissions still constrain access |
Removing permission to download a skill doesn’t erase copies already on laptops. The shared skill library guide covers that release boundary.
Check 6: review after purpose, ownership or capability changes
Trigger a review when the sponsor leaves, the agent gains a write tool, a new data source is connected or the operating team changes. A calendar review alone may miss the moment access expands.
Keep the last approved scope alongside the requested change. Require evidence for the new operation and retain the previous release for investigation and rollback.
Where SkillGateway fits
A skill distribution layer manages the instruction packages developers receive. Agent identity governance manages the authority of the workloads that use those packages. Connect the records through revision identifiers.
The Jarvis Skill Gateway page describes private distribution of approved skills. Evaluate that alongside your identity provider and runtime enforcement, rather than assuming distribution approval grants or revokes downstream access.
Use the AI agent registry vs skill registry comparison to decide which records belong in each lifecycle. Before onboarding more agents, run shadow AI discovery to identify existing workloads and their owners.
References
- Microsoft Entra: owners, sponsors and managers
- NIST SP 800-207: Zero Trust Architecture
- MCP authorization specification, July 28, 2026
- Microsoft Entra: revoke user access
- Jarvis Skill Gateway
AI identity governance questions for platform teams
What is AI identity governance?
It's the process of assigning accountable owners, approving permissions, reviewing access and retiring identities used by AI systems. For agents, keep the human requester, agent identity and downstream credential distinguishable so an action can be investigated and access can be withdrawn.
Does every AI skill need its own identity?
Usually the skill is an instruction package, while its host agent or execution workload holds credentials. Record which skill revision an agent used, but assign identity and permissions to the component that authenticates and performs the action.
Does disabling a user immediately stop every agent they started?
Don't assume it does. A background job may use its own workload identity, and an application may retain a session or token. Test the actual identity and credential path, measure the remaining access window and document how to stop the running workload.
How is a registry different from identity governance?
A registry records agents, owners and lifecycle state. Identity governance decides whether access remains justified. The identity provider, gateway and target service must enforce those decisions on the paths the agent actually uses.
