AI agent identity management: ownership, permissions and revocation

AI agent identity management means giving each agent a distinct identity and managing who owns it, how it proves its identity, what it can access and when that access ends. Keep the agent's identity separate from your personal login.

In short:

• Assign an owner. Give each agent a distinct identity and a responsible owner.
• Limit each grant. Use task-scoped permissions and short-lived credentials where supported.
• Check revocation. Test that access stops at each service, including access through already-issued credentials.

What an agent identity needs to cover

NIST's proposed agent identity design tenets call for distinct agent identities tied to their workload, environment and approved configuration. The identity identifies the agent, while a credential provides evidence of that identity. Authentication checks that proof. Authorization decides which resources and actions the agent can use.

Consider a hypothetical file-summary agent called notes-summary. Its credential lets it authenticate to a file service, while its permissions allow reading the Project Notes folder but not writing or deleting files. Its network connection lets it reach the service. That connection doesn't grant permission to read anything.

Microsoft's agent identity documentation distinguishes autonomous access from delegated access. An autonomous agent uses permissions assigned directly to its identity. A delegated agent uses rights that a user authorizes it to use on their behalf. Delegation doesn't mean giving the agent your password.

Map each agent to its owner and permissions

Create an access record before issuing credentials. Store credential references, never passwords or token values. Owner names and approval triggers are governance records, not proof of legal liability.

Copy this worksheet and replace the hypothetical examples with your agent's details.

Keep network access separate from application permissions, even when both belong to the same task. If authority passes to a downstream agent, record that identity and its narrower permissions too. Keep lifecycle records and service evidence somewhere the agent can't change them. For a service you don't administer, record which identity and permissions that service actually recognizes.

Give the agent only the access its task needs

Change only systems you own or administer. Keep the original configuration and an independent administrator recovery path. Treat NIST's tenets as proposed design goals, not binding certification requirements. Record gaps where your platform can't meet a goal.

1. Register a distinct identity and assign its owner.

Record the agent's purpose, workload, environment, owner and operator. For agents built in Copilot Studio, Microsoft Entra records the creator as the sponsor. Record an ongoing responsible owner separately if the creator won't keep that role.

2. Choose direct or delegated authority.

Use a direct grant when the agent should act under its own permissions. Use delegation when it should act on a user's behalf through the service's supported authorization process. Record whose authority applies to each task. Any downstream delegation should narrow that authority, not expand it.

3. Request credentials through the issuer's supported method.

Use the identity provider's documented process for the chosen identity and authority type. Store credentials in a protected location and put only the reference in your worksheet. NIST notes that anyone who gets a bearer token can present it. Treat that token as a secret, even if it carries limited permissions.

4. Enforce resource and action limits outside the model.

Give notes-summary read access to Project Notes, with no writes, deletion or access to Private Notes. Enforce those limits through the target service's access controls. An instruction telling the model not to delete files isn't a service access rule.

5. Set expiry and renewal rules where supported.

Prefer short-lived credentials and time-bounded grants tied to the intended service. Record who can approve renewal and which changes require another review. Use access checks during operations, not just at login, where the service supports them.

6. Test an allowed action and a denied action.

Read a harmless test file in Project Notes, then request a harmless test file in Private Notes. The successful read shows that the allowed grant works. An access denial shows that the folder boundary holds for that request. Successful authentication alone doesn't prove permissions are narrow.

If the denied request succeeds, inspect the effective grants and enforcement point before adding access. Fix the boundary, then repeat the checks.

You don't need a new identity product just because the workload is an agent. Keep your existing system if it supplies distinct identities, ownership records, suitable delegation and enforceable task permissions. Judge a dedicated service account by those controls, not just its label. A dedicated identity and shared credentials are different configurations.

Check that the agent's access really stops

Use this as a proposed verification procedure, not a vendor-tested runbook. Change only systems you own or administer. Keep the original configuration and an independent administrator recovery path.

1. Find every place the agent has authority.

Use the worksheet to identify credential issuers, direct grants, delegated grants and target services. Include downstream identities that received authority from the agent. Stop scheduled work so it doesn't keep making requests during retirement.

2. Remove grants and disable credentials or the identity.

Use each provider's documented controls for the relevant identity and grant type. Remove direct and delegated permissions, then disable credentials or the identity as appropriate. Don't assume that disabling an identity immediately cancels every issued token or active session.

3. Check whether the old identity can get a new credential.

After disabling the identity or its ability to authenticate, use the provider's documented credential-request flow. You should see a refusal to issue a new credential. That result shows new issuance is blocked for the tested flow. It doesn't show that existing credentials have stopped working.

4. Check an already-issued credential at each target service.

Use an already-issued credential to attempt the previously allowed read on a harmless test resource. You should see an access denial from the service, supported by relevant service evidence. That shows the credential can no longer make that request. A connection failure alone doesn't prove an authorization denial.

Don't print token values during these checks. Test each target service separately instead of treating a denial at one service as proof about another.

5. Investigate any access that still works.

Check remaining grants, cached authorization, active sessions and the provider's documented token validity. Follow the provider's controls for ending that access, then repeat the relevant test. Check downstream identities separately.

Remove network access separately where applicable. Where it's safe, check application denial before removing the network path. Otherwise, lost connectivity can hide whether application permissions still exist.

6. Keep a record of the result.

For each check, record the service, credential reference, revocation action, revocation time and check time. Add the expected denial, observed result and relevant service evidence. If access still works, record it as unresolved instead of marking retirement complete. Preserve the lifecycle record and independent evidence after access ends.

Where doxx.net fits. Agents configure the doxx.net private network through its application programming interface (API) and get controlled network access, which doesn't replace application permissions or a full identity-management lifecycle. If you need that network layer, create an account, download the app and connect a device or agent.