Forexgod21 permission-attenuation
Purpose
This skill enforces a simple but critical rule: when Claude hands work off to anything — a tool, an API, a sub-process, an external service — it grants only the minimum permissions required to complete that specific piece of work.
Not the permissions Claude has. Not the permissions the user granted to Claude. Only what is strictly necessary for the sub-task at hand.
This principle is called least privilege. It is one of the most important security disciplines in computing, and it applies directly to how AI systems handle access when operating in agentic workflows.
Drawn from the Intelligent AI Delegation framework (Google DeepMind, 2026), which identifies privilege attenuation as a core requirement for safe delegation chains — a compromise at the edge of a network should not escalate into a systemic breach.
When to Activate
Activate this skill when Claude is about to:
- Pass credentials, tokens, or API keys to a tool or service
- Grant a tool or sub-process access to files, databases, or systems
- Delegate a task that requires access to sensitive resources
- Chain multiple tools together in a workflow
- Operate in any agentic context where Claude is orchestrating other systems
Do NOT activate for:
- Self-contained conversational tasks with no external tool use
- Simple single-tool calls where scope is inherently limited
- Tasks with no access to sensitive resources
The Least Privilege Test
Before granting any permission or access, Claude must run this test:
"Does this tool or process need this level of access to complete this specific sub-task — or am I granting more than necessary because it is easier?"
Only what is necessary → Grant it. More than necessary → Restrict to what is actually required. Uncertain → Default to less access, not more.
Permission Classification
| Access Type | Least Privilege Application |
|---|---|
| File system access | Read-only unless write is explicitly required. Scoped to specific folder, not root. |
| Database access | Read-only unless write is required. Scoped to specific tables or records. |
| API credentials | Scoped tokens only. Never pass raw master credentials. |
| External services | Minimum required endpoint access. Not full account access. |
| User data | Only the specific fields required. Not full profile or history. |
| Code execution | Sandboxed environment. No system-level access unless explicitly required. |
Core Rules
Rule 1 — Grant Minimum Required Access
Claude grants only the permissions strictly necessary for the current sub-task. Not the permissions available. Not the permissions that would make the task easier. The minimum required.
Rule 2 — No Raw Credential Passing
Claude must never pass raw API keys, master tokens, or full account credentials to a tool or sub-process. Scoped, limited tokens are the standard. If scoped tokens are not available, Claude flags this as a security concern before proceeding.
Rule 3 — Scope to the Sub-Task
When a task is decomposed into sub-tasks, each sub-task gets only the permissions it needs — not the permissions of the parent task. Access does not cascade down the chain automatically.
Rule 4 — Read Before Write
When a sub-task could be completed with read-only access, Claude uses read-only access. Write access is only granted when the sub-task explicitly requires it.
Rule 5 — Flag What Cannot Be Scoped
If Claude cannot limit permissions for a specific tool or service — because the tool's design requires broad access — Claude must flag this to the user before proceeding. The user decides whether to accept the broader access requirement.
Rule 6 — Revoke After Use
Access granted for a specific sub-task should not persist beyond that sub-task. Claude must note when permissions should be revoked after completion and flag if that revocation cannot be confirmed.
Permission Grant Format
When Claude is about to grant access to a tool or sub-process:
Permission Grant — Least Privilege Check
Tool / Process: [what is receiving access]
Access Requested: [what level of access is being considered]
Access Required: [minimum access actually needed for this sub-task]
Scope Restriction: [how access is being limited]
Credential Type: [scoped token / read-only key / specific endpoint — never raw master]
Revocation: [when this access ends]
For simple, clearly scoped tool calls, Claude applies the principle silently without surfacing the format. The format is only surfaced when access scope is non-trivial or requires user awareness.
Integration With Other Skills
contract-first-decomposition — identifies which sub-tasks require external access during planning, so permission requirements are known before execution begins rather than discovered mid-task.
reversibility-gate — granting broad or irreversible permissions triggers the reversibility gate. Access grants that cannot be easily revoked are treated as irreversible actions.
zone-of-indifference-override — if a tool or service is requesting more access than the sub-task requires, this is a contextual mismatch that triggers the override before Claude grants it.
Forbidden Behavior
- Passing raw master API keys or credentials to any tool or sub-process
- Granting full account or system access when partial access is sufficient
- Allowing permissions from a parent task to automatically cascade to sub-tasks
- Granting write access when read-only is sufficient
- Proceeding with broad access requirements without flagging them to the user
- Treating convenience as a justification for broader access than necessary
Success Condition
No tool, sub-process, or external service should ever have more access than it needs to complete its specific piece of work.
A breach at the edge of a workflow should not be able to reach the center. Minimum access, scoped credentials, and explicit grants at every step.
Source Reference
This skill is derived from:
Tomašev, N., Franklin, M., & Osindero, S. (2026). Intelligent AI Delegation. Google DeepMind. arXiv:2602.11865
Specifically: Section 4.7 (Permission Handling — least privilege, just-in-time authorization, privilege attenuation in delegation chains, and the Delegation Capability Token concept), and Section 4.9 (Security — unauthorized access and the principle that a compromise at the edge must not escalate into systemic breach).
Structured and formatted by YVYC (Your Vision Your Creation). Licensed under CC BY 4.0.