The key is revoked. Why is the agent still working?

Imagine an agent starts a report export. The service accepts the job. A security operator then revokes the agent’s credential. A minute later, the export finishes.

Did revocation fail? The answer depends on the promise you were testing. Preventing a new request, canceling an accepted job and undoing a completed export are three different outcomes. A single “revoked” badge cannot tell you which one happened.

This is an illustrative engineering scenario, not a reported incident or an Ackuity test result. The standards below explain token behavior. The timeline and evaluation matrix are our proposed analysis.

NAME THE CREDENTIAL

Which key did you take away?

OAuth distinguishes access tokens from refresh tokens. An access token is presented to a protected resource. A refresh token is used to obtain access tokens. Establish which object your administrative action affects, and check the provider’s related-token policy rather than assuming that every credential disappears together.

RFC 7009’s revocation response uses HTTP 200 for both a successfully revoked token and an invalid token. It also describes propagation delays and different policies for related tokens. A successful response is useful evidence about the endpoint exchange. It is not a receipt for canceling every downstream operation.

Start with a small inventory: the initiating identity, credential reference, intended resource, permission scope and any separate session or delegated identity. Record references and expiry metadata, never secret token values. If the agent has several access paths, trace each one that matters to the task.

FOLLOW THE CHECK

Where does the next request meet the new state?

OAuth token introspection lets a protected resource ask whether a token is active and obtain authorization metadata. Its security considerations explain the trade-off in caching that response: fewer requests to the authorization server, but a possible interval of stale information. Cached responses must not outlive a supplied token expiration.

Draw the path from credential issuer to the service receiving the next action. Mark where current validity is checked, what can be cached and which component updates the cache. A valid signature on a self-contained token does not, by itself, demonstrate a fresh revocation check.

For a concrete provider example, Microsoft’s access-revocation guidance distinguishes access tokens, refresh tokens and application-controlled sessions. It notes that effective revocation can lag initiation. Its guidance is specific to the described Microsoft identity flows; do not assume the same behavior for every agent, service principal or API.

For token-validation responsibilities, Microsoft’s access-token documentation places validation at the resource server. Our evaluation question is narrower than “does the platform support OAuth?”: which component checks this operation, and which state did it actually use?

SEPARATE THE OUTCOMES

The job is accepted. Is it still yours to cancel?

A revocation endpoint and a job-cancellation interface solve different problems. For the illustrative export, inspect the target service’s documented job behavior and records. Determine whether it checks authorization again before execution, offers cancellation or continues accepted work under a service identity. Keep the answer specific to that service and job type.

The same discipline applies to delegation. If a child agent uses a separate credential, establish whether the revocation operation reaches that credential. A parent process exiting does not demonstrate that every child task or target-side job ended.

MAKE IT MEASURABLE

Use three clocks, not one green badge.

Our proposed record separates the revocation response, the first observed rejection at the protected resource and the last observed target-side effect. Keep request and job identifiers alongside timestamps, clock offsets and the observation window.

1. Authority changed. Record the administrative action, its scope, response and time. Establish what the provider says it invalidates.
2. Enforcement observed. Record when the relevant resource-side test first rejects the affected authority. Identify the path and validation configuration tested.
3. Effects checked. Inspect the destination for work already accepted, separate child credentials and completed effects through the defined window.

Do not subtract timestamps from unsynchronized clocks and label the difference a containment time. A missing destination event is inconclusive when collection is unhealthy. Include an allowed control to show that the route and evidence collector can observe legitimate completion.

Choose a risk-based acceptance criterion before the exercise. A customer-data export and a background summary may need different deadlines and recovery plans. There is no universal five-minute passing score in this worksheet.

Download the blank revocation worksheet

SIX PROPOSED CASES

Test the boundary and the useful work.

All six cases below are unrun. Use a disposable environment you own or are explicitly authorized to evaluate, with synthetic records and resource-side test fixtures. Production clients must stop using a token after its revocation response; do not turn this worksheet into production retries of revoked credentials.

1. Permitted control. Complete a harmless authorized operation and retain the destination record. If that fails, repair the exercise before interpreting denials.
2. Refresh-token revocation. Record the provider’s affected-token policy and observe the defined resource-side boundary. Keep existing access tokens separate from the ability to obtain new ones.
3. Access-token revocation. Use the authorized fixture to assess the receiving service’s enforcement and supported revocation mechanism. Record the exact configuration.
4. Cached authorization. Compare the documented cache setting with observed enforcement. Keep the token’s expiration and observation window in the record.
5. Accepted job. Start a harmless owned job before revocation. Examine cancellation behavior and final state separately from future-request rejection.
6. Separate child identity. Inventory a child task’s credential and evaluate the explicitly intended cascade. Also confirm that an unrelated, still-permitted control remains usable.

For each case, retain an expected outcome, actual outcome and an explicit unknown state. A denial is not proof of cancellation. An empty log is not proof of prevention. A failed legitimate control is not a successful security result.

PUT IT INTO PRACTICE

Who checks the action after the credential changes?

Credential lifecycle is one part of AI agent security. A complete design also identifies which component authorizes the next operation, which execution paths it covers and what happens to work already in motion. The kill switch versus control switch comparison separates whole-agent containment from intervention on one action.

Ackuity is the Agent Execution Control Switch AI builders add to their agents, verifying every action before it runs. Its Agent Security Context Graph brings identity, permissions and action context into that decision. The evaluation checklist and evidence kit help you ask for a connected request, policy, decision and target-system record.

That description does not establish that Ackuity passed these six cases or cancels jobs on every target platform. Product-specific conclusions require a supported integration, an actual run and independent outcome evidence. The Agent Exposure Assessment examines existing telemetry and exposure; inline enforcement needs a separate controlled evaluation.

PRIMARY REFERENCES

Read the implementation details.

• RFC 6749, OAuth 2.0: access and refresh tokens, October 2012.
• RFC 7009, Token Revocation: responses, propagation and implementation notes, August 2013.
• RFC 7662, Token Introspection: active state and caching trade-offs, October 2015.
• Microsoft Entra access-revocation guidance: provider-specific tokens and sessions.
• Microsoft identity-platform access tokens: resource-server validation responsibilities.