Agent Identity Privilege Reviewer

---
name: agent-identity-privilege-reviewer
description: Review agent identities and privilege paths under the Open Worldwide Application Security Project (OWASP) agentic identity identifier ASI03. Check distinct least-privilege identities, scoped credentials, delegation that only reduces authority, confused-deputy paths, and attribution to both human and agent. Complements secrets-identity-hardener for custody and rotation. Use for agent identity and delegation design or privilege-escalation review. Do NOT use for secret storage, per-tool enforcement, software-development lifecycle (SDLC) merge/deploy authority, or end-user role-based access control (RBAC); those have separate owning skills.
---

# Agent Identity & Privilege Reviewer

**Reading key:** Open Worldwide Application Security Project (OWASP) agentic
identifier ASI03 covers identity and privilege here. An application
programming interface (API) is a software access boundary; the software
development lifecycle (SDLC) covers build through release; role-based access
control (RBAC) grants permissions through roles; identity and access
management (IAM) governs accounts and permissions; DB means database.

## Purpose

Review the identity architecture of an agent system (ASI03): what identity
each agent runs as, what privileges that identity holds, and how authority
flows when work is delegated — user to agent, agent to sub-agent, agent to
tool. The output is findings ranked by escalation path: shared or over-broad
agent identities, long-lived standing credentials, delegation that amplifies
instead of attenuates, confused-deputy paths where a low-privilege requester
harvests an agent's higher privilege, and actions that cannot be attributed
to both the human principal and the acting agent. Credential custody and
rotation mechanics belong to `secrets-identity-hardener`; per-tool
enforcement belongs to `agent-tool-safety-guard` — this skill reviews the
identity model those enforce against.

## Use When

- Use when: reviewing what identities/credentials agents and sub-agents run
  as, or designing them for a new agent system.
- Use when: agents share a service account, hold admin/broad API keys, or
  keep standing credentials that outlive tasks.
- Use when: designing delegation or on-behalf-of semantics — how a user's
  authority is carried through agents to actions — or hunting
  privilege-escalation / confused-deputy paths in a multi-agent system.
- Use when: audit/attribution can't answer "which human and which agent did
  this?"
- Do NOT use when: the finding is how secrets are STORED, exposed, or
  rotated — `secrets-identity-hardener` (this skill decides what identities
  and scopes should exist; that one fixes custody).
- Do NOT use when: the question is whether a specific tool call runs with the
  calling user's authority (`agent-tool-safety-guard`), what a dev-agent may
  merge/deploy in the SDLC (`agent-authorization-matrix`), or end-user
  roles×permissions (`authorization-matrix-designer`).

## Inputs to Inspect

1. The agent inventory and what identity each runs as: per-agent identities,
   shared service accounts, or the platform's ambient credentials.
2. Credential material per agent: scopes, lifetime, issuance (static keys vs
   short-lived tokens), where they live (route custody findings to
   `secrets-identity-hardener`).
3. The delegation design: how a user's request becomes an agent's authority —
   on-behalf-of tokens, impersonation, session propagation — and what
   happens at each hop (agent → sub-agent → tool).
4. The permission each identity actually holds vs what its tasks need
   (IAM policies, API scopes, DB roles), including tenant reach.
5. Attribution: logs/audit records for agent actions — do they carry BOTH
   the human principal and the acting agent (`audit-log-architect` schema)?
6. Existing authority artifacts: `agent-authorization-matrix` (SDLC standing
   authority), `authorization-matrix-designer` output (end-user RBAC the
   delegation must respect).

## Workflow

1. **Inventory identities.** List every agent/sub-agent and the identity it
   executes under. Flag immediately: multiple agents on one identity, agents
   on a human's personal credentials, or ambient platform credentials. No
   identity information available → Stop Conditions.
2. **Map privilege vs need.** For each identity: what can it actually do
   (scopes, roles, tenant reach) vs what do its tasks require? Excess is a
   finding with an escalation path, not a style note.
3. **Trace delegation chains** using
   [references/agent-identity-patterns.md](references/agent-identity-patterns.md):
   for each chain (user → agent → sub-agent → tool), write who authorized
   the hop, what authority crosses it, and whether it attenuates. Authority
   must never grow along a chain; a sub-agent holding more than its parent
   is an amplification finding.
4. **Hunt confused-deputy paths.** Anywhere an agent performs privileged
   actions on requests from less-privileged sources (users, peer agents,
   queued jobs): can the requester steer the agent's privilege to targets
   they couldn't touch themselves? Cross-tenant variants first
   (`tenant-isolation-reviewer` composes).
5. **Check credential lifetime and binding.** Standing long-lived credentials
   on agents are findings when task-scoped short-lived issuance is feasible;
   tokens should bind to the task/principal context so a stolen credential
   doesn't outlive or outrange the task.
6. **Verify dual attribution.** Every side-effecting action must be
   attributable to the human principal AND the acting agent (and the chain
   between them). "The service account did it" is an attribution failure.
7. **Rank findings by escalation path.** Each finding: identity → excess or
   chain flaw → concrete abuse (what an attacker or manipulated agent
   reaches) → fix (split identities, narrow scopes, attenuate hop, add
   attribution). Custody fixes route to `secrets-identity-hardener`;
   per-tool enforcement to `agent-tool-safety-guard`.

## Output Format

```
AGENT IDENTITY & PRIVILEGE REVIEW — <system>
Identity inventory: <agent → identity → shared? → credential type/lifetime>
Privilege vs need: <identity → holds vs needs → excess>
Delegation chains: <user → agent → sub-agent → tool; authority at each hop; attenuates?>
Findings (severity-ranked):
  [SEV] <identity/chain> — Escalation path: <requester/attacker → abuse → reach>
    Fix: <split identity | narrow scope | short-lived issuance | attenuate hop | add attribution>
Confused-deputy paths: <requester → agent privilege → target they couldn't reach>
Attribution: <dual (principal + agent) attribution status per action class>
Handoffs: custody → secrets-identity-hardener | tool enforcement → agent-tool-safety-guard
Not reviewed: <areas + why>
```

## Validation Checklist

- [ ] Every agent/sub-agent's executing identity is inventoried; shared and
      ambient identities are flagged.
- [ ] Privilege vs need compared per identity; excess carries an escalation
      path, not just a "too broad" label.
- [ ] Every delegation chain is traced hop-by-hop and attenuates; no
      sub-agent or tool hop holds more authority than its delegator.
- [ ] Confused-deputy paths checked wherever privileged agents serve
      less-privileged requesters; cross-tenant variants first.
- [ ] Credential lifetime/binding reviewed; standing credentials justified
      or flagged with a short-lived alternative.
- [ ] Dual attribution (human principal + acting agent) verified for
      side-effecting actions.
- [ ] Custody/rotation findings routed to `secrets-identity-hardener`, not
      re-solved here.

## AI Security Rules

- Agent identities are scoped and least-privilege: one agent, one identity,
  the minimum scopes its tasks need, for the minimum time.
- Delegation attenuates: authority may narrow at each hop of
  user → agent → sub-agent → tool, never widen. Amplification is a finding
  by definition.
- No confused deputy: an agent must not let a requester achieve through the
  agent's privilege what the requester's own authority forbids.
- Every action is attributable to the human principal AND the acting agent;
  anonymous service-account attribution fails the review.

## Gotchas

- The shared "agents" service account is the default failure: convenient at
  setup, it makes every agent as powerful as the strongest one and turns any
  single compromise into fleet-wide privilege. Split it before scoping it.
- Delegation by prompt is not delegation: passing "acting for user X" as
  text grants nothing and attenuates nothing — authority must travel as
  verifiable context (token, signed claim), or the deputy is confused by
  design.
- Sub-agent spawning quietly amplifies: a child agent inheriting the
  parent's full credentials for a narrower task violates attenuation — mint
  narrower, shorter-lived credentials per spawn.
- Confused deputy hides behind helpfulness: "fetch this URL for me,"
  "summarize that tenant's doc" — the agent's privilege makes it a proxy for
  reaches the requester lacks. The check is the REQUESTER's authority, not
  the agent's.
- Machine identity sprawl: agents accumulate roles over time (each incident
  adds one); nobody subtracts. Review holds-vs-needs against current tasks,
  not historical ones.
- Attribution that stops at the agent ("agent-7 deleted it") is half an
  answer — without the principal and chain, incident response and
  `agent-governance-audit` dead-end.

## Stop Conditions

- No identity/credential information is available for the agent system —
  stop; this skill reviews concrete identity architecture, not intentions.
- A live over-privileged path with active abuse indicators is found
  (credential used from unexpected context, cross-tenant reach exercised) —
  route to the human incident owner and the approved response runbook;
  revocation is a human call. Use `incident-response-runbook` later to
  author or improve the procedure and `secrets-identity-hardener` to design
  credential controls, rather than asking either skill to run the response.
- Fixes require creating/splitting identities or changing IAM/scopes in a
  live system — propose the target model; applying it is a classified,
  approved step (`human-approval-boundary`).
- The question turns out to be end-user RBAC, SDLC merge/deploy authority,
  or per-tool argument enforcement — hand to the owning skill and stop.

## Supporting Files

- [references/agent-identity-patterns.md](references/agent-identity-patterns.md)
  — identity-per-agent patterns, short-lived task-scoped issuance, the
  delegation/attenuation trace method, the confused-deputy catalog, and the
  dual-attribution audit schema.
- `evals/evals.json` — trigger + behavior cases.
- `evals/trigger-evals.json` — discrimination within the agentic cluster and
  against `secrets-identity-hardener`, `agent-tool-safety-guard`,
  `agent-authorization-matrix`, and `authorization-matrix-designer`.