Agent Permission Layers: Why RBAC Isn't Enough
Description and use
Implementing layered permissions—identity, tool, data, action—alongside session‑scoped credentials and audit logs prevents accidental misuse, enables traceability, and reduces blast radius compared to shared service accounts.
Problem
Agents with broad, static permissions can access sensitive data and perform irreversible actions without accountability, leading to accidental or malicious misuse.
Outcome
Implementing layered permissions—identity, tool, data, action—alongside session‑scoped credentials and audit logs prevents accidental misuse, enables traceability, and reduces blast radius compared to shared service accounts.
Workflow
- 1. User initiates an agent run. 2. System mints a short‑lived credential scoped to the user’s role and task. 3. Tool gateway checks the API against an allowlist. 4. Row‑level filters inject data scope per request. 5. Action type (read, draft, send) is evaluated; irreversible actions queue for human approval. 6. All tool calls are logged with identity, tool, data, action, and session ID. 7. Denied actions are logged with reason codes and trace IDs. 8. CI runs permission regression tests to ensure no scope escalation or data leakage. 9. Quarterly cross‑team reviews audit agent scopes and update PR templates with permission diffs. 10. Incident response drills practice kill switches, session revocation, and forensic tracing.
Evidence
Marcus gave the agent a service account because RBAC was "too hard." Now it could read HR records, write tickets, and email customers — because those scopes came bundled with the integration user created in 2019.
Agents amplify whatever permissions you lazily attach. A human with broad access exercises judgment. An agent with broad access executes probability — and probability doesn't know which actions are irreversible.
Implement layers: Tool gateway — MCP or proxy that enforces allowlists centrally; Row-level filters — injected per request; Human gates on send/delete; Audit everything — permission denials are signals, not noise.
Each run gets credentials minted for that job — narrow scopes, short TTL, bound to initiating user context. When the session ends, tokens die.
Marcus's fix was simple: every agent run gets a temporary credential with scopes derived from the initiating user's role and the specific task.
Build permission regression tests alongside feature tests. Agent attempts forbidden action — expect logged denial, not silent success.
- Record date: 2026-10-13T03:41:23.127Z