Automation Expert Claude

Agent Identity and Delegated Authorization Failure Review

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

Browse more prompts
Best forSecurity
ToolClaude
DifficultyExpert
Copied7 times
Full Prompt
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.

Put this Prompt to work

Add the required information and run this Prompt with your selected AI provider.

Opens in a new tab.

Variables to Replace

Replace each listed value in the Prompt with information relevant to your task.

  • Incident or workflow name
  • Time window
  • Agent and tool boundary description
  • Evidence bundle
  • Delegation policy sources
  • Accountable owners

How to Use This Prompt

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.

Was this useful?

Build stronger AI systems

Use Amo.ng prompts as reusable building blocks, then go deeper with RichlyAI.

Used in Workflows

Browse Workflows
AMO-W-000012 5 steps

Investigate an AI Agent Security Incident

Reconstruct an AI agent incident, trace delegated authority and sensitive context, conditionally investigate memory or RAG authorization, and prepare evidence-based containment and recovery gates.

Browse Skills

Related Prompts

Browse all
Automation Expert Codex

Implement and Verify an n8n Workflow in Staging

Convert an approved n8n blueprint into a disabled importable workflow or staging implementation, with node-level traceability, synthetic execution evidence, retry tests, and rollback instructions.

Updated Sep 9, 2026

View prompt Verified ✓ 249 views · 2 copies
Automation Expert ChatGPT

Agent Escalation Threshold Calibration

Tune agent escalation triggers using incident severity, uncertainty, false-positive and false-negative evidence, queue capacity, delay, and owner authority.

Updated Aug 25, 2026

View prompt Verified ✓ 222 views · 22 copies
Automation Expert Claude

Model Fallback Failure Analysis

Reconstruct a failed model fallback decision, test contract compatibility across routes, and determine whether to repair, restrict, or disable fallback behavior.

Updated Aug 25, 2026

View prompt Verified ✓ 256 views · 10 copies
Automation Expert Claude

Tool Permission Drift Investigation

Compare approved and effective agent tool permissions over time, reconstruct permission drift, contain excess access, and define evidence-based recertification actions.

Updated Aug 25, 2026

View prompt Verified ✓ 302 views · 9 copies