How do I re-check agent authority at execution time, not only at plan time?

What should I check, step by step?

1. Split plan from execute: planning/read-only work can use a broad explore mode; anything that writes, pays, sends, or reaches the network needs an execution-time check.

2. When you approve (human or policy engine), mint a grant: grant id, agent id, action type, argument hash, policy_version (or hash of permissions.json / spend policy / CLAUDE settings), issued_at, expires_at (minutes, not days), and single-use.
3. Store the grant outside the agent's editable session (server DB, ledger, or checkpointer the agent's tools cannot UPDATE). Give the agent only the grant id.
4. In the tool runner, on every risky call: load grant by id → reject if missing/expired/consumed → recompute argument hash → reject on mismatch → load current policy_version → reject if ≠ grant.policy_version → then run and mark the grant consumed.
5. Wire client-native per-call checks too: Claude Code permission modes and /permissions rules are enforced per tool call; Cursor Run Modes (Auto-review / Allowlist) gate shell, MCP, and Fetch before execution — do not disable them because you already "approved the plan."
6. On policy edits (spend caps, deny rules, allowlists, mode changes), bump policy_version so in-flight grants fail closed instead of silently following the old yes.
7. Log allows, denies, expiries and policy-mismatch failures with the grant id and policy_version so you can audit which authority was live at the moment of execution.
8. Never treat chat memory, a checkbox in the prompt, or approved=true in session JSON as the authority check at execution time.

Why isn't plan-time approval enough?

Between "looks good" and the write/pay call, the user can tighten deny rules, lower a spend cap, revoke a credential, or the agent can change arguments (amount, path, recipient) after the yes.

• Claude Code's docs: when you add or remove a /permissions rule while Claude is working, the change applies starting with the next tool call in the same turn — which only helps if every call is checked again, not once per plan.
• Cursor's Run Modes page: Auto-review applies to each shell, MCP, and Fetch call in order (allowlist → sandbox when possible → classifier). Cloud Agents are a separate trust boundary; local Run Modes still expect per-call evaluation.
• OpenAI Agents SDK human-in-the-loop guidance keeps approval state server-side and verifies before resume; a client-uploaded RunState is not authorization.

How do short-lived grants tie to a policy version?

Policy version is a monotonic integer or content hash of the rules that mattered: spend caps, tool allow/deny lists, permission mode, and network allowlists. Stamp it on the grant at approve time.

• At execution: if live policy_version !== grant.policy_version, refuse — even if the grant has not expired. That is how a mid-run lockdown wins.
• Keep TTLs short (often under 30 minutes for high-risk actions). Single-use for payments, deletes, and production deploys; bounded reuse only for identical argument hashes you deliberately allow.
• Combine with product controls: request_human_approval binds a hash of the action; set_spend_policy + authorize_spend re-check caps at spend time; verify_* tools fail when the receipt no longer matches.

What can go wrong?

The plan was approved in Plan/ask mode, then the session switched to bypassPermissions or Run Everything and no second check ran.

• Argument hash is skipped, so an approved "transfer $25" becomes "$2500" with the same grant id.
• Policy is edited (new deny rule, lower daily cap) but existing grants keep working until wall-clock expiry.
• The only copy of approved=true lives in the agent's session file, which the next turn overwrites.