# Agent Identity and Delegated Authorization Failure Review

Amo ID: AMO-P-000285
Version: 1.0.0
Public URL: https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review

Summary: Investigate wrong-principal agent actions and delegated authority failures across agent, tool, and downstream-system boundaries.

Use this for: Use this to reconstruct which principal acted under which delegated authority and identify where that binding failed.

Category: Automation
Tool: Claude
Difficulty: Expert
Prompt type: security

## Best Use Cases

1. Wrong-Principal Incident Review
2. Confused-Deputy Failure Analysis
3. Delegated Authority Chain Reconstruction
4. Agent Tool-Call Authorization Review
5. Stale Delegation Containment Planning
6. Identity-Control Repair Gate Definition

## Prompt Body

Review the supplied evidence to determine which principal acted, under which delegated authority, at each agent, tool, and downstream-system boundary, and where that principal-authority binding failed.

Focus on agent identity spoofing, confused-deputy behavior, stale delegation, wrong-principal actions, and authorization-context loss. Do not perform a broad agent security audit. Do not infer inspection, execution, approval, containment, or remediation unless the supplied evidence supports it.

Context to provide:
- Incident or workflow name: [Incident or workflow name]
- Time window: [Time window]
- Agent and tool boundary description: [Agent and tool boundary description]
- Evidence bundle: [Evidence bundle]
- Delegation policy sources: [Delegation policy sources]
- Accountable owners: [Accountable owners]

Evidence discipline:
- Separate observed facts from inference, hypothesis, and missing information.
- Treat logs, traces, request IDs, token claims, policy excerpts, configuration snapshots, audit events, tickets, and owner statements as evidence only when supplied.
- Preserve uncertainty when timestamps conflict, identities are aliased, policies are incomplete, or downstream enforcement behavior is not evidenced.
- Do not assume that the initiating user, agent runtime identity, tool credential, service account, and downstream effective principal are the same.
- If a claim depends on unavailable evidence, state what evidence would be needed and which owner should provide or verify it.

Authority boundaries:
- Do not declare the issue fixed, contained, approved, or closed without evidence tied to a security reviewer, system owner, data owner, release owner, or service owner named in the supplied context.
- Do not recommend bypassing authorization checks, expanding privileges for convenience, or relying on logging as a substitute for enforcement.
- Prefer the smallest containment and repair steps that restore correct principal binding while preserving legitimate workflow behavior.

Produce the following deliverable.

1. Review scope and evidence inventory
- State the workflow, systems, principals, tools, downstream services, and time window actually covered by the evidence.
- List supplied evidence by type and relevance.
- List important evidence not provided, including why it matters.
- State confidence level for the review and the main reasons for that confidence.

2. Principal and delegation chain
Create a step-by-step chain showing how authority was carried or transformed across boundaries. Use a table with these columns:
- Step
- Timestamp or sequence marker
- Boundary crossed
- Request, trace, job, or session identifier
- Initiating principal
- Agent runtime principal
- Tool or connector principal
- Downstream effective principal
- Delegated authority claimed
- Delegation source or policy reference
- Token, credential, session, or capability involved
- Observed action
- Evidence citation from supplied material
- Confidence
- Missing evidence or ambiguity

Call out every point where identity was asserted, translated, delegated, cached, proxied, impersonated, or lost.

3. Authorization failure chronology
Build a concise chronology of the failure path. For each event, identify:
- What happened
- Which principal appeared to act
- Which principal should have been authoritative, if determinable
- What delegated authority was present, stale, missing, overbroad, or misapplied
- Whether the event indicates spoofing, confused deputy behavior, stale delegation, wrong-principal action, authorization-context loss, or another clearly named failure mode
- What evidence supports the classification
- What remains uncertain

4. Action-to-authority matrix
Create a matrix mapping each consequential action to the authority required and the authority actually observed. Use these columns:
- Action or operation
- Resource or data scope
- Required principal or role
- Required delegation condition, scope, audience, tenant, time limit, or consent
- Observed principal
- Observed delegated authority
- Enforcement point expected
- Enforcement point evidenced
- Decision observed, such as allowed, denied, skipped, inherited, cached, or unknown
- Mismatch type
- Potential impact
- Evidence citation

Highlight actions where the system accepted an authority context that was missing, stale, meant for another audience, meant for another tenant, too broad, inherited from the wrong actor, or not revalidated downstream.

5. Affected scope
Separate confirmed, likely, possible, and not evidenced impact. Cover:
- Users, tenants, accounts, workspaces, repositories, environments, datasets, secrets, transactions, or external systems affected
- Time interval of exposure
- Data or operations reachable under the mistaken authority
- Whether unauthorized read, write, execute, approve, delete, publish, spend, or disclose actions are evidenced
- Whether lateral movement, replay, token reuse, cached delegation, or downstream propagation is evidenced or merely plausible
- Constraints that limit impact

6. Containment and identity-control repair gates
Define repair gates that accountable owners can use to decide whether the workflow may resume or continue operating. Include immediate containment and durable control gates.

For each gate, provide:
- Gate name
- Failure it addresses
- Required control or change
- Owner accountable for verification
- Evidence required to pass
- Pass criteria
- Fail or block condition
- Residual risk if accepted

Include gates where relevant for:
- Principal provenance at agent start and tool-call time
- Delegation freshness and revocation handling
- Audience, tenant, resource, and scope binding
- Prevention of confused-deputy delegation reuse
- Downstream reauthorization rather than blind trust in upstream context
- Service account and connector credential separation
- Audit correlation across user, agent, tool, and downstream identifiers
- Token, session, capability, or cached grant invalidation
- Least-privilege restoration without breaking legitimate workflow paths

7. Owner decision record
Prepare a decision-ready summary for the named accountable owners. Include:
- Most likely root cause, stated with confidence and evidence basis
- Highest-risk unresolved uncertainty
- Minimum containment required before further use
- Minimum identity-control repair required before normal operation
- Verification tasks by owner role
- Open questions that block a defensible decision
- Items that can be safely deferred, with rationale

Completion checks:
- Confirm that the principal and delegation chain covers each supplied boundary or states why a boundary could not be assessed.
- Confirm that every consequential action is mapped to required and observed authority, or marked unknown with missing evidence.
- Confirm that affected scope distinguishes observed impact from plausible but unproven exposure.
- Confirm that each repair gate has an accountable owner, evidence requirement, and pass/fail criterion.
- Do not present remediation as complete unless evidence supplied in the prompt demonstrates completion.

## Variables to Replace

1. Incident or workflow name
2. Time window
3. Agent and tool boundary description
4. Evidence bundle
5. Delegation policy sources
6. Accountable owners

## How to Use

Open Claude and paste this prompt. Replace every bracketed placeholder with the incident name, time window, boundary map, logs or traces, token or policy excerpts, configuration snapshots, tickets, and named accountable owners. Run the prompt, then have the security reviewer, relevant system owner, data owner, and release owner verify the evidence basis, affected scope, and repair-gate pass criteria before using the output for an operational decision.

## Example Use Case

A product team discovers that an automation agent used a connector credential to update records in a downstream CRM after the initiating user's permission was revoked. The security reviewer uses this prompt to reconstruct the principal chain, identify stale delegation and downstream reauthorization gaps, quantify affected records, and define gates for token revocation, scope binding, audit correlation, and safe workflow restart.

## Tags

1. incident-response
2. access-control
3. claude
4. verification
5. ai-agent-security
6. authorization
7. incident-analysis
8. trust-boundaries

## Dates

Published: 2026-08-19
Updated: 2026-08-19