AI tool access security review: test authority from grant to revocation

An AI tool access security review should answer a narrower question than “can the agent be manipulated?”: when the system acts, whose authority is it using, for which tenant and resource, for which exact action, under what approval, and for how long? The answer often changes between an interactive chat, a queued job, a retry, and the moment an administrator removes access.

Fictional scenario — Harbor Finance. A finance assistant reads invoices on behalf of signed-in employees. It also uses an application identity to post approved records into an accounting system overnight. A manager approves a draft for supplier A and account X. Before the queue runs, the draft is edited to supplier B and account Y. The employee then leaves the company and their delegated grant is revoked. The design review must establish whether the queued write still runs, which identity authorizes it, whether the old approval remains valid, and what tokens, exports, task results, or application sessions survive.

That is an authority-lifecycle problem. It is related to excessive agency and MCP security, but it is not another prompt-injection checklist. The review follows authority from grant, through use and approval, to revocation and cleanup. It gives a buyer concrete acceptance criteria for an assistant, copilot, or agent that can read or change real systems.

Map who can act, where and for how long

A tool name says little about access. “Search files” may read one project folder or an entire tenant. “Create draft” may be harmless until another service automatically submits every draft. For each callable operation, record the access context: acting identity, client or agent, tenant, target resource, allowed action, material parameters, approval context, validity window, and execution channel. The execution channel distinguishes a foreground request from a queue, scheduled job, retry, webhook, or replay.

OAuth scopes commonly describe a kind of access. They do not always identify the exact resource instance or business object. OAuth Resource Indicators provide a standard way for a client to state the target resource, while Rich Authorization Requests can carry structured authorization details. These are optional mechanisms in the broader OAuth ecosystem, not properties every deployed system has. The review should therefore inspect what the actual authorization server, resource server, connector, and application enforce.

This access record also exposes three different decisions that teams often collapse into one. Consent grants a client a class of access. A runtime policy decides whether a particular call is allowed now. Transaction approval confirms a particular consequential action. A broad consent screen is not approval for every future payment, message, permission change, or data export.

Separate delegated authority from application authority

In delegated access, an application acts on behalf of a signed-in user. In Microsoft Graph’s documented model, the effective privilege is constrained by both the application’s delegated permission and the user’s own access. In application access, the application acts under its own identity without a signed-in user; such permissions can cover organizational data and are treated as highly privileged. Other platforms use different names, but the design question is the same: does the downstream system know the human subject, or only a workload identity?

This distinction matters when background work begins. A queue worker cannot honestly claim “the user approved it” merely because the original chat had a user. The job may run under a service principal with broader rights, after the user’s role changed, or in a different tenant chosen from mutable task data. The review should trace the identity on the original request, the identity stored with the task, the credential used by the worker, and the subject visible in downstream audit logs.

Resource-specific permissions can reduce the gap between a broad tenant grant and the object actually needed. Microsoft’s selected-permissions model, for example, requires the relevant scope, an explicit assignment to the resource, and a token carrying the scope. That is a product-specific design, not a universal OAuth guarantee. Its general lesson is useful: verify the intersection of client permission, resource assignment, human or workload identity, and requested action.

For HTTP-based MCP deployments using the authorization specification dated 25 November 2025, that specification requires servers to validate that inbound tokens were issued for them and forbids passing the same token through to a downstream API. A server calling another API should use a separate token for that resource. The existing MCP server security assessment guide covers that protocol boundary in depth; this review follows the authority further, into approval, delayed execution, revocation, and residual state.

Bind approval to the action that will execute

An approval control is meaningful only when it covers the significant transaction data. For a payment, that can include beneficiary, account, amount, currency, source account, tenant, and operation type. For a message, it can include channel, recipients, attachments, classification, and whether the action is a draft or a send. The approver should see those values from a trusted server-side record, not from editable client text.

OWASP’s transaction-authorization guidance provides a strong general pattern: enforce the decision server-side, keep the state transitions in order, invalidate approval if significant data changes, use a limited validity window, make the authorization unique to one operation, and perform a final gate at execution. Applied to an AI system, approval should be a short-lived capability for one canonical action, not a durable “user said yes” flag attached to a conversation.

Test stale approval with harmless variants. Obtain approval for a canary action, then change one significant parameter, switch the target tenant, reuse the approval for a second operation, execute after expiry, and race cancellation against execution. Each test needs a positive control first: prove that the unchanged canary succeeds under the intended account. Then verify not only the agent’s response but also the downstream system, because a friendly error in chat does not prove that no side effect occurred.

1. ConstructCanonicalize identity, tenant, resource, action and significant parameters on the server
2. ApproveShow those values to the approver and issue a short-lived, single-use decision
3. Re-evaluateAt execution, check current grants, task owner, policy, parameters and cancellation state
4. ReserveAtomically assign the single-use approval to one operation before dispatch; reject competing claims
5. ReconcileDispatch with an operation identity, record the downstream outcome and resolve uncertain results before retrying

Treat queued and background work as a new authorization moment

Queues stretch time between intent and effect. During that interval a user can leave, a role can change, an app grant can be removed, a resource can move between tenants, an approval can expire, or a task body can be edited. A secure worker does not equate “accepted into the queue” with “still authorized to run.”

The safest default is to store immutable intent: subject, client, tenant, resource, operation, normalized parameters, approval identifier, creation time, expiry, and a digest or version. At execution, the worker validates task ownership and state, checks cancellation and expiry, and re-evaluates the relevant current authorization. If business rules intentionally allow a job to survive a user’s departure, that should be an explicit application-authority design with a named owner and bounded service identity—not an accidental consequence of a worker credential.

Retries deserve separate tests. A network timeout may occur after the downstream action succeeded but before the worker recorded success. Our recommended design atomically reserves the approval for one operation before dispatch, so competing workers cannot spend it twice. The downstream call needs an idempotency mechanism or another proven duplicate-prevention strategy; an identifier alone cannot provide that guarantee. If the outcome is unknown, reconcile it before retrying. Checking an already committed result is different from authorizing another effect, and expired or revoked approval must not permit a new action.

Cancellation that arrives after a downstream commit cannot undo that action; record the race outcome and any separately authorized compensation. Task lookup, result retrieval, cancellation, and list operations also need per-task authorization; an unguessable task identifier is not an access-control decision.

Review a minimum matrix: run before and after user disablement, delegated-consent removal, application-permission removal, resource-specific grant removal, approval expiry, task cancellation, tenant change, and worker credential rotation. Record which control is expected to stop which path. This keeps a successful revocation test in one layer from masking a still-active path in another.

Measure revocation latency and distinguish what was revoked

“Revoked” can refer to different objects: a refresh token, an access token, an application session, a delegated consent grant, an application role assignment, a resource-specific grant, a worker credential, or the task itself. Removing one does not prove that every other object has stopped working.

OAuth Token Revocation requires support for revoking refresh tokens and recommends support for access-token revocation. If an authorization server does not revoke access tokens, they may remain usable until another enforcement point rejects them or they expire. Token Introspection lets a resource ask whether a token is active, but the standard explicitly recognizes a tradeoff: caching introspection reduces load and can create a window in which revoked state is stale. These standards define mechanisms and considerations; they do not promise an identical revocation time across products.

Microsoft’s documentation illustrates the same practical boundary. Blocking a user and revoking refresh tokens prevents new tokens, while an existing access token can remain effective until expiry unless the application and resource support a mechanism such as Continuous Access Evaluation. An application-issued session is controlled by that application and cannot be directly revoked by the identity provider. Application permissions belong to the application identity, so removing a human user does not by itself remove an app-only grant.

A review should measure rather than assume. Start with a valid, low-impact positive canary. Trigger one revocation event at a recorded time. Repeat the exact request with the existing access token, then attempt a refresh or new token, then repeat through the application session and background worker. Stop at an agreed safe bound. Report the last successful attempt and first denial for each path, sampling intervals, later outcomes, the denying component and the observation limit. Repeated denials narrow the uncertainty; one denial does not establish a permanent cutoff across every replica or route. “Denied within the test window” is defensible; “revocation is instant” usually is not.

Check residual authority, credentials, tasks and artifacts

Revocation ends some future actions. It does not necessarily erase what the agent already obtained or created. Cached documents, downloaded exports, vector entries, conversation attachments, generated reports, queue payloads, task results, logs, browser downloads, and downstream drafts may remain. A worker might also retain a refresh token, API key, client secret, or application cookie outside the identity system that an administrator changed.

Create a residual-state inventory for each connector. Identify where credentials are stored, who can read them, how they are rotated or deleted, and whether logs capture token material. Then map data artifacts to their owner, tenant, classification, retention, access rule, and deletion path. Removing a grant should stop new retrieval under that grant once the applicable revocation controls take effect; it should not be described as deleting earlier copies unless deletion was separately executed and verified.

This is where a lifecycle review differs from a login test. The assessor checks that a task whose authority ended cannot be resumed under that authority, that cached results are not available to an unauthorized user or tenant, that a revoked connector cannot be reactivated with a retained refresh token, and that downstream drafts or links do not preserve a capability to complete the action. Where retention is required, the report should state the surviving artifact and compensating access control rather than claiming full removal.

Scope the review around decisions and evidence

A useful scope includes the identity provider, agent or client, authorization and approval service, tool gateway, queue and worker, credential store, representative downstream APIs, tenant boundaries, and artifact stores. Provide test users for materially different roles, one narrow application identity, resource-specific grants where used, a non-production tenant, harmless canary objects, relevant logs, and named stop contacts. Destructive actions, bulk extraction, and real external messages stay outside scope unless separately authorized.

The assessment should begin with architecture and configuration, then use controlled tests. For each denial, first establish a valid positive path so an invalid token or broken test object cannot masquerade as a security control. Preserve the policy decision, identity claims or introspection result where available, queue event, worker identity, downstream response, and final object state. Evidence should show both that the request was denied and that no prohibited side effect appeared. Keep only the fields and identifiers needed for the report; redact live tokens and secrets, and restrict access to assessment evidence.

The deliverable should contain an authority map, grant inventory, approval-binding results, queue and retry results, measured revocation observations, residual-state findings, and a retest plan. Conclusions stay bounded to the identities, products, configurations, and observation windows tested. The companion article on excessive-agency security testing is useful when the broader question is what the agent can be induced to do; this review is for proving how authority changes over time.

An independent assessment is especially useful before enabling write-capable tools, moving from delegated access to an application identity, adding background execution, or changing revocation and approval controls. Pentest.red can test the agreed AI, identity, queue, and downstream boundaries through an AI and RAG security assessment. The scope planner helps inventory roles, tenants, tools, and safe canaries, while the sample pentest report shows the level of reproducible evidence to request. A review does not certify every future configuration; it gives the owner concrete findings and retest criteria for the authority lifecycle that was actually examined.