SECURITY · ACCESS INSPECTION DESK
Tool authorization: scope and role must agree
Inspect credential claims, policy gates and the resource decision. Change a condition and follow the exact denial reason.
Your experiment
Request write access. Grant the write scope but keep the viewer role, then change to operator. Explain why either condition alone is insufficient under this policy.
Prediction is computed immediately; Play reveals each gate in order. A denial prevents every later gate from running. Capture a baseline before changing one field.
Illustrative claims
Decision trace
Offline policy exercise—not a JWT validator, OAuth server or production security boundary. Verification is an injected test result; no cryptography, real tokens, keys or records are used. Never rely on browser controls to enforce real authorization. Roles, gate order and strict same-tenant rules are application-specific assumptions, not universal OAuth requirements. Expiry is evaluated at a fixed instant; animation does not age the token. No revocation, clock skew or delegation is modeled. Bearer token reference · JWT claims reference.
Require both a tool grant and a permitted role
A tool invocation is represented here by read, write or delete against a tenant-local resource. The token scope and application role are independent constraints: a role cannot create a missing credential grant, and a broad grant cannot add an operation to a narrow role. This is an authorization experiment, not a throughput or capacity benchmark despite the historical URL. The model exposes exact gate decisions rather than invented requests-per-second results.
Supply the credential and resource facts
Bearer credential present and Trusted verification result control the first two authentication gates. The latter is an injected authenticator result, not an actual signature computation. Issuer selects a trusted or unknown issuer; Audience chooses this agent API or another API. Seconds until expiry is evaluated at a fixed instant, with zero already expired. Principal tenant and Resource tenant define the boundary. Role selects viewer, operator or admin; Requested action chooses read, write or delete. The read, write and delete scope checkboxes represent independently granted token scopes. Changing a fact resets inspection of the same ordered policy.
Build a least-privilege write request
Keep the default trusted, unexpired credential and matching tenants. Select write while keeping viewer role and no write scope. Required scope denies the invocation. Add write scope and repeat; the first denial moves to Role permission. Select operator and the write is allowed. Now request delete and enable delete scope. Operator remains insufficient, while admin permits the operation. Finally change only Resource tenant to team-b: even the admin credential is denied at the tenant boundary. Return the tenant to team-a and remove delete scope to demonstrate that privileged roles do not bypass explicit grants.
Understand the modeled tool boundary
Read scope is initially enabled, while write and delete scope are off. Scopes are exact action names, not wildcard expressions or hierarchical permissions. Viewer permits read, operator permits read and write, and admin permits all three actions inside its tenant. The exercise does not execute a tool, discover ADK annotations, exchange credentials or model delegated consent. It teaches the decision that must be enforced before a real operation is released; it is not a drop-in authorization library.
Inspect first denial and later gates
The desk evaluates token presence, verification, issuer, audience, expiry, tenant, required scope and role in that order. The first denial determines the displayed HTTP result. Later gates are not-run, not additional failures or successful checks. The credential JSON and policy preview describe the complete selected scenario before animation finishes. Play reveals eight gates over thirty-two seconds at normal speed; Pause holds progress, Step advances one gate, Restart rewinds and Speed chooses half, normal or double inspection pace. Edits start playback unless reduced motion is requested. The resource vault opens only after inspection reaches the final decision and every required policy has passed.
Keep the security boundary explicit
This is a deterministic application authorization policy over fixture claims. It does not parse a JWT, retrieve a JWK, verify a cryptographic signature, issue an OAuth token, run a real identity provider or contact a protected endpoint. The verification checkbox is evidence supplied to the policy, not a way to bypass real cryptography. Expiry is not a live countdown; no clock skew, refresh flow, revocation, multiple audiences or scope hierarchy is implemented. Admin privileges are tenant-local in this fixture. HTTP 401 and 403 are the chosen teaching policy outcomes, not a claim that every provider uses this exact gate order or error text.