TL;DR: One tool call can involve three identities: the person who asked, the agent doing the work, and the credential the target system accepts. Use delegated user authority when the operation should be bounded by that person’s own rights, an agent workload identity for agent-owned background work, and treat a shared broad credential as a documented exception rather than a default. Scope every credential to a resource, an operation, an object and a time window, and keep the actor chain attached to the action.
Key takeaways
- A tool call can involve three distinct identities: the user requesting the work, the agent or workload executing it, and the service account or credential accepted by the target system.
- Use delegated user authority when the operation should be limited by the user’s rights. Use an agent workload identity for agent-owned work. Avoid a shared credential that erases both.
- Scope credentials to the target resource, operation, object and time window. A token valid for one API should not become a general credential for every tool.
- Retain the actor chain with the action: who requested it, which agent version acted, what policy allowed it, which credential was used and what the target returned.
- Revocation needs to work during long-running and asynchronous tasks. Removing a user or agent should stop new actions, not only the next login.
A user asks an agent to update a support case. The agent calls a customer system and the audit log says the change was made by ai-service-account.
That record does not tell you who requested the change. It does not distinguish this agent from every other workflow using the same account. It may also give the agent more access than the user has.
The question “whose permissions should the agent use?” has no single answer. It depends on whether the agent is acting for a person, performing its own assigned work or operating a shared background process. The design needs to preserve those distinctions rather than collapsing them into one credential.
This article presents an identity model for agent tool calls. The examples are illustrative and need to be adapted to the identity and authorization systems in your environment.
Separate identity from authority
Identity answers who or what is acting. Authority answers what that actor may do to a particular resource under current policy.
For an agent workflow, write down five fields before discussing credentials:
- Initiating subject: the user or system that requested the work.
- Software actor: the agent or workload executing the step.
- Delegated authority: any rights the subject has given the actor for this task.
- Target resource: the API, record, environment or tool receiving the request.
- Operation: the specific read or write being attempted.
A sixth field records the policy decision. A seventh records the target system’s result.
This model keeps a tool call from becoming “the agent used the user’s permissions.” It shows which user, which agent, which resource and which subset of authority were involved.
NIST’s zero-trust architecture states that network location and asset ownership should not create implicit trust. For agents, running inside a trusted cluster is therefore not an identity decision. The target still needs to authenticate the actor and authorize the requested operation.
The four common permission patterns
Most agent tool calls fit one of four patterns.
1. User-delegated access
The agent acts on behalf of the initiating user, within a limited scope. Use this when the operation should be constrained by the user’s own rights and attributable to their request.
Examples include retrieving a case the user can already view, drafting a change to a record they own or scheduling a meeting within their calendar authority.
The agent should not receive the user’s broad session token and reuse it across tools. Issue or exchange a credential for the intended target, operation and time window.
OAuth 2.0 Token Exchange explicitly distinguishes delegation from impersonation. With delegation, the software actor retains its identity while acting for a subject. That is usually the more informative model for agent actions because the target or audit layer can preserve both participants. For JWT-based delegation, RFC 8693 defines an act claim to identify the actor. Check that your authorization server and target integration preserve and interpret the subject and actor as intended.
2. Agent workload identity
The agent acts as its own software principal to perform work assigned to that agent. Use this for background retrieval, scheduled evaluation, queue processing or other tasks that do not depend on one user’s standing access.
The workload identity should identify a specific agent service and environment, not every agent in the organization. It should also be short-lived and attestable to the running workload where the platform supports that model.
SPIFFE is one open standard for workload identity across heterogeneous environments. It defines short-lived cryptographic identity documents called SVIDs (SPIFFE Verifiable Identity Documents) that workloads can use to authenticate. The relevant architectural lesson is to give software a first-class identity rather than treating a copied API key as the agent’s identity.
3. Service-owned operation with user context
The target system may accept only a service credential even though a user initiated the task. In that case, retain the user as request context and apply policy before the service credential is used.
This is weaker than native delegated authorization because the target may see only the service account. It can still be governed if the control plane records the actor chain, scopes the service account narrowly and writes the initiating user and approval reference into the target’s audit metadata where supported.
Do not describe this as “using the user’s permissions” if the target actually authorizes a service account.
4. Shared broad credential
Several agents use one long-lived credential with wide access. This pattern is convenient and difficult to defend.
It creates three problems:
- the target cannot distinguish agents or users;
- one credential compromise affects many workflows;
- revoking one agent’s access may require rotating every workflow using the account.
Sometimes a legacy system leaves no immediate alternative. Treat the credential as a documented exception. Put a narrow proxy in front of the legacy operation, restrict the allowed methods and resources, and migrate away from the shared account rather than making it the default pattern.
Whose permission should an agent use?
Use the authority that matches the ownership of the action.
- If a user asks the agent to do something the user is entitled to do, prefer delegated user authority with the agent preserved as the actor.
- If the agent performs assigned background work, use a workload identity with policy scoped to that job.
- If a named reviewer approves a consequential operation, issue authority for the exact approved action rather than elevating the agent generally.
- If a target supports only a service account, constrain it through a proxy or policy layer and retain the initiating subject separately.
Avoid selecting the most privileged identity simply because it makes tool integration easier. The correct credential may change within one workflow. An agent can read public documentation under its workload identity, retrieve a user’s private case under delegated access and apply an approved update through a one-operation credential. Graduated authority for AIOps agents works through the same idea for operational work, where authority widens one step at a time.
Scope a credential to where it will be used
Scope has at least four dimensions:
- Resource: which API or protected service accepts the credential?
- Operation: which methods or actions are allowed?
- Object: which records, projects, accounts or environments are in scope?
- Time: how long does the authority remain valid?
RFC 8707 defines OAuth resource indicators so a client can tell an authorization server which protected resource should receive the token. The authorization server can then restrict the token’s intended audience. That prevents a token issued for one resource from being treated as a general bearer credential elsewhere.
The same principle applies beyond OAuth. A database credential should be limited to the required schema and queries. A cloud role should name the resources and actions. An MCP server should expose only the tools this host is allowed to use, and the host should still authorize the individual operation. Taking MCP to production covers that tool-exposure boundary in more detail.
Scope is not a substitute for business policy. A token may permit updateCase, while policy still requires approval for changing the case owner or issuing a refund.
Follow one tool call end to end
Consider a fictional service-desk agent. A support lead asks it to move a high-priority case to another queue and add an internal note.
Establish the subject and agent
The support lead signs in through your identity provider. Her stable identifier, role and session context reach the agent runtime, which then presents its own workload identity to the control plane.
So the policy decision has both actors in front of it: the person asking for the work, and the approved agent version about to do it.
Evaluate each operation separately
The workflow contains two writes: change the queue and add a note. Policy may allow the note under the user’s delegated rights while requiring approval for moving a high-priority case.
Keep them as two decisions when their consequences differ, rather than folding both into one general case:write.
Issue narrow authority
For the note, the authorization service issues a short-lived token for the case API with the scope needed to add an internal note to this case.
For the queue change, the agent prepares the exact old and new queue values. A reviewer approves that proposal. The authorization service then issues authority for that operation, case and time window.
The agent never receives a general administrator token.
Recheck state before the write
The workflow retrieves the case again. If another person has already moved it, the approved action no longer matches the current state. The tool call stops and returns for review.
Retain the actor chain
The evidence record includes:
- initiating user and session reference;
- agent identity and version;
- policy version and decision;
- delegated scope and target audience;
- approval and approved parameters;
- credential identifier, not the secret value;
- tool request and target response;
- state before and after the action.
That record lets an investigator answer both “who asked for this?” and “which software actually did it?”
Both questions come up again when a decision turns out to be wrong, which is the subject of who is accountable when an AI agent makes a bad decision.
How does an AI control plane manage agent identities and permissions?
The control plane connects identity, policy and the running agent configuration.
At request time, it can evaluate:
- the initiating subject;
- the authenticated workload identity;
- the agent version and environment;
- the requested tool, operation and resource;
- the data classification and business context;
- any required approval;
- previous actions and rate or risk limits.
The result should be an explicit allow, deny or approval-required decision with the policy version and reason. The credential service then issues only the authority needed for the allowed step. Moring’s AI Control Plane works this way: each agent gets its own short-lived, target-scoped credential, the person behind every run is recorded alongside what the agent did, and the policy deciding which tools and resources it can reach sits outside the agent’s own code. What changes is the access path. Instead of raising a ticket per system per agent, and waiting on data-access and firewall approvals that often expire before the workflow ships, each agent is provisioned against a policy that was reviewed once.
Central policy helps when the same rule applies across frameworks. A support agent built in one runtime and a finance agent built in another can both use the same identity and approval requirements without copying policy into each codebase. What AI agent orchestration is and how to govern it from one place describes that single point of control, and what an AI control plane is and how to evaluate one sets out what to look for in a product that claims it.
The control plane also needs an inventory. Revoking an agent identity should show which deployed workflows and tool bindings will stop working. Changing a policy should identify the affected versions and environments before rollout.
How do we connect AI agents to existing SSO?
Use the existing identity provider to authenticate people and supply stable user and group claims. Keep authorization in the target system or a policy service that understands the requested resource.
The basic flow is:
- The user authenticates to the application.
- The application passes the minimum user context to the agent runtime.
- The agent authenticates separately as a workload.
- Policy evaluates the user, workload, target and operation.
- A token service issues a target-specific delegated or workload credential.
- The target records the actor and result.
Directory group membership may be one input, but it should not become the only policy. A user in the support group may still be restricted to certain regions, case types or actions.
How do we manage secrets for AI agents?
Treat secrets as credential material, not as the identity system itself.
A static API key proves possession of a value. It often does not identify the current user, workload instance, approved operation or target object. Prefer credentials issued after authentication and policy evaluation.
Where static secrets remain necessary:
- store them in an approved secret manager;
- restrict which workload can retrieve them;
- mount them only into the component that uses them;
- prevent prompt, trace and error logging from capturing them;
- rotate them and test revocation;
- give different agents different credentials;
- place a narrow service in front of broad legacy access.
Kubernetes’ secret guidance recommends encryption at rest, least-privilege access and short-lived service-account tokens through its TokenRequest API where possible. The implementation will differ across environments, but the design direction is consistent: reduce shared, long-lived bearer secrets. Keeping secret material out of traces and error payloads is also an instrumentation decision, covered in observability for AI agents.
Revocation is part of the workflow
Revocation is easy to describe at login time and harder during an agent run.
An agent may pause for approval, wait on a queue or resume a task hours later. During that interval:
- the user may leave the organization;
- the agent version may be withdrawn;
- the tool may be removed from the allowlist;
- the target record may change;
- the approval may expire;
- the credential may be rotated.
Re-evaluate authority before each consequential operation. Do not assume the authorization at task creation remains valid for the life of the workflow.
Short-lived tokens limit exposure, but expiration alone is not enough. The system needs to reject new token issuance for revoked users and agents. For urgent revocation, it may also need a way to invalidate active sessions or place a deny rule ahead of the target.
Test the identity design
Use a set of negative tests, not only the successful path:
- A user without access asks the agent to retrieve a protected record.
- An authorized user asks an unapproved agent version to perform the action.
- A token issued for one tool is presented to another.
- An approval is reused after the target record changes.
- A background job resumes after the initiating user’s access is revoked.
- Two agents share a target integration, and one identity is disabled.
- A tool returns an error containing secret material.
For each case, confirm that the operation fails at the expected control and that the evidence shows why. A generic tool error is not enough. Responders need to distinguish a policy denial, expired authority, wrong audience, target rejection and infrastructure failure.
Every tool call then has five things attached to it: the person behind it, the software actor doing it, the target, the operation, and the policy decision that allowed it. Write those five down for one workflow and the conversation with your security team gets shorter, because you are both looking at the same fields.
We think this is the piece most teams leave until last. When data-access and firewall tickets pile up faster than agents ship, identity design has become the bottleneck.
Frequently asked questions
Should an AI agent use the user’s permissions or its own?
Use delegated user authority for work performed on behalf of a person and an agent workload identity for agent-owned background work. Preserve both identities when a software actor operates for a user. Use one-operation authority after approval for consequential changes.
Is an API key an agent identity?
Usually not on its own. An API key may identify an integration or prove possession of a secret, but it often lacks the user, workload instance, target scope and policy context needed to govern a specific agent action.
How should agent permissions be revoked?
Stop issuing new credentials to the revoked user or agent, expire short-lived credentials, invalidate active sessions when required and re-evaluate authorization before consequential actions. Confirm which deployed workflows depend on the identity before changing it.