Revoke the prior grant when narrowing access

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

audit-bot’s old token has read/write; scope is now read-only. Issuing another narrow token leaves the old grant usable. Narrow the same principal and revoke it.

Mechanism

Resolve stable identity/all active grants, use supported same-principal narrowing/revocation and state effective time/reconnection. Verify old credentials rejected, new reads allowed and new writes denied across JS/aliases too. Sequence rotation under actual service semantics without a lingering broad window and record safe IDs, not credentials.

Bad example

Issue a read token but leave old writes active, or mint another principal and call it restriction.

Good example

Restrict the same audit-bot to read, revoke old broad sessions and reconnect under the contract. Probe controlled reads/writes for new-read pass and new-write/old-token denial, recording effective scope/time/gaps.

Why the change matters

Credentials coexist; a narrow addition does not subtract a broad grant. Identity-bound revocation changes actual capabilities rather than configuration appearance.

Observable expectation

Old-token writes mean failure regardless of new labels. Old denial/new read/new write denial supports tested scope. A new principal with the original active does not narrow it. Log safe identifiers only.

Limits

Prose cannot revoke server grants; caches/in-flight calls/other sessions affect scope. Frozen pairing features need actual-runtime verification, and read-named commands do not exclude JavaScript effects.