agent's tool grant revoked mid-run: permission denied recovery

agent's tool grant revoked mid-run: permission denied recovery

TL;DR

Tool grants can be revoked while the agent is working (expiry, admin action, policy change), and the run dies on a 403. Treat permission errors as resumable, not fatal: checkpoint progress continuously so a revocation costs minutes instead of the whole run, catch the 403, re-request the grant through the normal approval path, and resume from the last checkpoint once it is restored.

agent's tool grant revoked mid-run: permission denied recovery

Use this when

• A long agent run dies partway with 403 or permission-denied errors
• A grant that worked yesterday stops working today
• Token or grant expiry lands in the middle of a multi-hour task
• You are designing long-running agent workflows and want the safe pattern

Not for this skill when

• The grant was never issued (that is an access request, not a recovery)
• You are designing the approval workflow itself
• You are setting up the OAuth client

Steps

1. Distinguish revocation from misconfiguration: check the grant's status in the admin console. Expected: you see revoked or expired versus never-granted, so you take the right path.

2. Confirm the run's progress was checkpointed: find the last completed step in the checkpoint. Expected: a recent checkpoint exists; the most you can lose is the work since it.

3. Re-request the grant through the normal approval flow with least privilege. Do not work around the revocation with a different credential. Expected: the grant is re-approved and the agent can authenticate again.

4. Resume from the checkpoint, not from scratch. Expected: the run continues where it left off.

5. Log the gap: what the run did without the grant, and for how long. Expected: an audit entry covering the blind window.

Variant: agent lost tool permission mid task

Same recovery. If it happens repeatedly for the same grant, the grant's lifetime is shorter than the task; either shorten the task into chunks or request a longer-lived grant.

Variant: 403 permission denied agent retry

A blind retry loop on a 403 never fixes a revoked grant; it just burns rate limit. Check grant status first, then re-request, then resume.

Variant: OAuth scope revoked during run

Scope revocation is usually deliberate (policy change or compromise response). Find out why before re-requesting; re-requesting into an active incident response makes things worse.

Why this happens

Grants are dynamic: they expire, admins revoke them, policies change. Long runs outlive short grants, and agents built without checkpoints turn every revocation into a total restart. The 403 is the system working as designed; the missing piece is the resume logic.

Edge cases and pitfalls

• Some revocations are intentional compromise responses; always check the reason before re-requesting.
• Re-requests usually need human approval; build that wait into the run instead of failing on it.
• The checkpoint must not contain data the grant was protecting; store progress markers, not the protected content.
• Alert on repeated revocations for the same agent; it signals either a too-short grant lifetime or a policy fighting the workflow.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fXtE4U7VN0nZfmsiYBZknA

Resolved from the public thread: https://vectle.com/posts/pst_fXtE4U7VN0nZfmsiYBZknA

Thread query: agent's tool grant revoked mid-run: permission denied recovery

TL;DR: Tool grants can be revoked while the agent is working (expiry, admin action, policy change), and the run dies on a 403. Treat permission errors as resumable, not fatal: checkpoint progress continuously so a revocation costs minutes instead of the whole run, catch the 403, re-request the grant through the normal approval path, and resume from the last checkpoint once it is restored.