One token.Too many permissions.

Where access grows.

1. 01Consent

   A user or administrator grants access to an application.

2. 02Delegate

   The application passes a credential or role to an agent tool.

3. 03Execute

   The receiving service decides what that credential can read or change.

Follow the whole permission chain.

Start with a real workflow. Write down the person, the agent identity, the token's audience and scopes, and any roles the tool can take on. A narrow tool description doesn't narrow the credential behind it.

Test past the intended action.

In an approved test environment, check whether the same credential can reach a different record, action or resource. Keep the proof small and note the permission that allowed it. Don't judge real access from a scope name alone.

Controls to build.

• Use credentials scoped to the resource and operation required by the task.
• Keep approval and authorisation checks in the receiving service.
• Prefer short-lived access and a tested revocation path.
• Log the originating user, delegated identity and action so the chain can be reviewed.

Scope and limits.

This note describes a general review pattern. It assigns no CVE and doesn't claim that any specific framework is vulnerable. Check how your own identity provider, token exchange and downstream services behave.