Give AI agents access that expires with the task

The fastest way to connect an agent is to give it a service account, API key, or reusable user token with enough permission to finish the job. The integration works until the original task ends, the agent changes, the employee leaves, a prompt is compromised, or a copied credential appears in another runtime. The permission remains because it was attached to an account rather than to the reason for access.

Reducing a token's lifetime helps, but it does not solve the authorization problem by itself. A fifteen-minute token can still provide tenant-wide read access, permit an unrelated purpose, or be exchanged for a longer-lived downstream session. Temporary access needs a bounded decision as well as expiring credentials.

This note builds on the separation described in Your AI agent should not borrow a human identity: the agent that acts and the principal that authorizes the work are different facts. Temporary access is the grant that connects them for one bounded job.

A short token is temporary authentication. Temporary authorization also limits the task, purpose, resources, actions, and downstream authority.

Treat each access decision as a structured grant that a policy engine and an investigator can both understand. The grant should be narrow enough to deny adjacent work without depending on the model to remember a prose instruction.

Consider an illustrative post-sales agent preparing a renewal-risk review. The agent may read health scores, recent support cases, and the current contract for one account; write a draft summary to the customer-success workspace; and request human approval before creating a retention task. It may not export raw tickets, read unrelated accounts, change the contract, or contact the customer. The grant ends when the review is submitted or after two hours, whichever comes first.

The agent should not receive the union of everything it can technically request and everything the user can reach. Effective access should be the intersection of several independent bounds: the agent's approved policy, the delegating principal's authority, the current task, resource-level data rules, environmental conditions, and the requested action.

Microsoft's current authorization guidance for agent identities distinguishes delegated access from autonomous application access, blocks several high-privilege permissions for agents, and recommends granting only required application permissions. That is useful platform evidence, not a universal enforcement model. An enterprise still needs to decide which task and data slice justify each request.

Evaluate the intersection at request time whenever possible. The user may have changed roles, the account may have become restricted, the agent version may no longer be approved, or the case may have closed since the grant was issued. A valid token should not force the resource to ignore newer policy state.

Effective access = agent policy ∩ principal authority ∩ task scope ∩ data policy ∩ current risk conditions.

Microsoft Entra now documents access packages for agent identities that bundle resource roles, approval policy, expiration, extension, and sponsor oversight. Agents can request a package programmatically, sponsors can request on their behalf, or administrators can assign it. Approved assignments receive a start and end date, and an extension can trigger another approval cycle. These are reported product capabilities and may not cover every application or authorization pattern.

The reusable idea is valuable beyond one identity provider: package the smallest recurring access pattern, not the broadest job role. A support-summary package might allow read access to one assigned case and write access to one internal summary. A renewal-review package might add contract metadata for an approved account cohort. Each request still supplies the agent, task, resource selectors, purpose, and duration.

Keep the package definition versioned. If an administrator adds a new API permission or group, existing approvals should not silently authorize the expanded bundle. Treat the change as a new policy version and identify which grants or agents require re-evaluation.

A governance record cannot stop an API call. The grant must be translated into credentials and policy inputs that the resource server, data layer, tool gateway, or enforcement proxy actually checks. Put the narrowest practical selector into the decision: account ID, repository, folder, table or row policy, action, recipient, amount, environment, and tool audience.

Use short-lived, audience-bound credentials so a token minted for the support API cannot be replayed against the billing system. Avoid passing a reusable bearer token into the model context or downstream tool configuration. Where the target system supports only coarse roles, put a broker or gateway in front of it, enforce the finer task rule there, and record the legacy credential mapping as a compatibility risk.

SPIFFE defines short-lived, cryptographically verifiable workload identities that can strengthen machine authentication. Workload identity alone does not express the customer account, purpose, human authority, or permitted business action. Carry those facts in the authorization decision and bind them to the authenticated workload.

The question 'How do you ensure AI agents only access data they are authorized to see?' has no single model-layer answer. Retrieval filters, system prompts, and tool descriptions can reduce mistakes, but the final allow or deny decision belongs at an enforcement point that knows both the authenticated agent and the requested data.

For each read, evaluate the agent identity, principal, grant, purpose, resource, data classification, row or object scope, action, environment, and current risk. Return only the permitted fields or records, and log the policy version and selectors used. If the agent asks a search index, enforce the same boundaries before retrieval or filter against a security-trimmed index; do not retrieve broadly and hope the model omits forbidden passages.

Treat derived artifacts as data access too. A summary, embedding, cache entry, exported file, memory record, or downstream message can preserve information after the original read permission expires. Record where outputs are written and apply retention and deletion rules that match the source data and task.

Prompts tell the agent what it should do. Resource-side authorization decides what it can do.

Agents call tools and other agents. Every hop is a chance for a narrowly authorized task to reach a broadly privileged service. Do not hand the parent credential to the child. Mint or exchange it for a derived credential whose audience, resources, actions, and lifetime are no broader than the downstream job.

An active IETF Internet-Draft on AI agent authorization describes distinct agent identities, authorization grants, confirmation, and delegation considerations. Because it is draft standards work, details can change. The durable operational rule is that every child action must remain attributable to the child actor, parent agent, original principal, and reduced grant.

When the parent grant expires or is revoked, stop new child requests and revoke derived sessions where the technology permits. Cancel queued work that has not crossed an irreversible boundary. Mark in-flight actions whose cancellation is uncertain, and route them to containment rather than pretending revocation travels instantly through every system.

A timestamp in the identity console is not proof that access ended. Test the complete path with a long-running workflow, retry queue, cached token, browser session, subagent, exported artifact, and partial tool action. Expire the grant during each state and observe what stops, what completes, and what remains accessible.

Test revocation separately from expiry. A sponsor should be able to revoke one task grant without disabling the agent, one agent version without disabling the owner, and the entire agent identity without waiting for every grant to reach its natural end. Emergency containment should block authentication or enforcement at a boundary that does not depend on the compromised agent cooperating.

Most teams cannot replace every shared service account or legacy application at once. Start with one high-value workflow and inventory the current credentials, resources, actions, owners, and hidden downstream sessions. Create a distinct agent identity, put one narrow grant in front of the most consequential resource, and preserve the old path as an explicit exception with an owner and removal date.

Connect the grant and its runtime evidence to the broader AI agent governance record. Measure denied requests, unused scope, human approval time, expiry failures, and incidents. Expand only after the system can prove that access ends with the task under normal and hostile conditions.

The goal is not to make every permission ephemeral for its own sake. It is to ensure that an agent's authority remains explainable, no broader than the current job, and removable without collateral damage.