Reusable AI capability
Reconstruct Agent Delegation and Authority Chains
Apply a repeatable principal-chain method to determine which identity acted, what authority was delegated, where context changed, and which actions require repair or review.
This Skill packages a reusable way to use the linked Prompt or Workflow; Amo.ng does not run it for you.
# Reconstruct Agent Delegation and Authority Chains Skill ID: AMO-S-000010 Skill URL: https://amo.ng/skills/reconstruct-agent-delegation-and-authority-chains Purpose: Give security, platform, and service owners a reusable capability for tracing agent, user, service, connector, tool, and downstream-system authority across incidents, design reviews, and access-control investigations. Required inputs: - Agent, user, service, tool, connector, and downstream-system identities in scope - Delegation contracts, permission policies, token or credential metadata, and revocation rules - Tool calls, traces, messages, audit logs, state changes, and affected actions - Expected principal propagation and authorization boundaries - Investigation window, known impact, accountable owners, and decision constraints How to use: When to use: - A system may have acted as the wrong principal or exceeded delegated authority. - Agent, tool, connector, or downstream audit records disagree about the initiating identity. - A design or release review needs an explicit principal and delegation chain. When not to use: - General agent readiness with no identity or authorization question. - Credential rotation or access changes without evidence and owner authorization. - Treating token possession as proof that an action was permitted. Reusable method: 1. Define the action and authorization question before inspecting evidence. 2. Build a principal ledger for the initiating user or service, agent, tool, connector, and downstream actor. 3. Trace each delegation edge: issuer, recipient, scope, purpose, resource, time, revocation state, and evidence. 4. Compare expected identity propagation with logs, claims, policy evaluation, and downstream authorization. 5. Classify each edge as supported, contradicted, unresolved, stale, broadened, confused-deputy, or missing context. 6. Identify affected actions without assuming every action in the time window used the defective path. 7. Define the smallest repair, revocation or reauthorization test, audit-correlation requirement, and restart gate. Expected output: A principal and delegation map, evidence ledger, first failed boundary, affected-action register, uncertainty, repair controls, regression checks, and an owner-bound proceed, contain, or investigate decision. Boundaries: Do not claim token inspection, policy evaluation, revocation, containment, or remediation without evidence. The security reviewer and relevant system or service owner decide containment and risk acceptance; the release owner controls restart or deployment. Source grounding: AMO-P-000285. Applicable Workflow: AMO-W-000012. Powered by Prompt: Agent Identity and Delegated Authorization Failure Review Source ID: AMO-P-000285 https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review Completion criteria: Complete when every material action has a supported, contradicted, or unresolved principal chain; delegation scope and revocation state are explicit; the first failed boundary is evidence-linked; affected actions and uncertainty are bounded; and repair plus regression gates have accountable owners. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Reconstruct Agent Delegation and Authority Chains Skill ID: AMO-S-000010 Skill URL: https://amo.ng/skills/reconstruct-agent-delegation-and-authority-chains Purpose: Give security, platform, and service owners a reusable capability for tracing agent, user, service, connector, tool, and downstream-system authority across incidents, design reviews, and access-control investigations. Required inputs: - Agent, user, service, tool, connector, and downstream-system identities in scope - Delegation contracts, permission policies, token or credential metadata, and revocation rules - Tool calls, traces, messages, audit logs, state changes, and affected actions - Expected principal propagation and authorization boundaries - Investigation window, known impact, accountable owners, and decision constraints How to use: When to use: - A system may have acted as the wrong principal or exceeded delegated authority. - Agent, tool, connector, or downstream audit records disagree about the initiating identity. - A design or release review needs an explicit principal and delegation chain. When not to use: - General agent readiness with no identity or authorization question. - Credential rotation or access changes without evidence and owner authorization. - Treating token possession as proof that an action was permitted. Reusable method: 1. Define the action and authorization question before inspecting evidence. 2. Build a principal ledger for the initiating user or service, agent, tool, connector, and downstream actor. 3. Trace each delegation edge: issuer, recipient, scope, purpose, resource, time, revocation state, and evidence. 4. Compare expected identity propagation with logs, claims, policy evaluation, and downstream authorization. 5. Classify each edge as supported, contradicted, unresolved, stale, broadened, confused-deputy, or missing context. 6. Identify affected actions without assuming every action in the time window used the defective path. 7. Define the smallest repair, revocation or reauthorization test, audit-correlation requirement, and restart gate. Expected output: A principal and delegation map, evidence ledger, first failed boundary, affected-action register, uncertainty, repair controls, regression checks, and an owner-bound proceed, contain, or investigate decision. Boundaries: Do not claim token inspection, policy evaluation, revocation, containment, or remediation without evidence. The security reviewer and relevant system or service owner decide containment and risk acceptance; the release owner controls restart or deployment. Source grounding: AMO-P-000285. Applicable Workflow: AMO-W-000012. Powered by Prompt: Agent Identity and Delegated Authorization Failure Review Source ID: AMO-P-000285 https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review Completion criteria: Complete when every material action has a supported, contradicted, or unresolved principal chain; delegation scope and revocation state are explicit; the first failed boundary is evidence-linked; affected actions and uncertainty are bounded; and repair plus regression gates have accountable owners.Copy skill copies the Skill details. Use with AI adds a short instruction for your preferred AI tool; neither action runs the Skill.
Purpose
Give security, platform, and service owners a reusable capability for tracing agent, user, service, connector, tool, and downstream-system authority across incidents, design reviews, and access-control investigations.
Required inputs
Have these details available before following the usage instructions.
- Agent, user, service, tool, connector, and downstream-system identities in scope
- Delegation contracts, permission policies, token or credential metadata, and revocation rules
- Tool calls, traces, messages, audit logs, state changes, and affected actions
- Expected principal propagation and authorization boundaries
- Investigation window, known impact, accountable owners, and decision constraints
How to use this Skill
When to use:
- A system may have acted as the wrong principal or exceeded delegated authority.
- Agent, tool, connector, or downstream audit records disagree about the initiating identity.
- A design or release review needs an explicit principal and delegation chain.
When not to use:
- General agent readiness with no identity or authorization question.
- Credential rotation or access changes without evidence and owner authorization.
- Treating token possession as proof that an action was permitted.
Reusable method:
1. Define the action and authorization question before inspecting evidence.
2. Build a principal ledger for the initiating user or service, agent, tool, connector, and downstream actor.
3. Trace each delegation edge: issuer, recipient, scope, purpose, resource, time, revocation state, and evidence.
4. Compare expected identity propagation with logs, claims, policy evaluation, and downstream authorization.
5. Classify each edge as supported, contradicted, unresolved, stale, broadened, confused-deputy, or missing context.
6. Identify affected actions without assuming every action in the time window used the defective path.
7. Define the smallest repair, revocation or reauthorization test, audit-correlation requirement, and restart gate.
Expected output:
A principal and delegation map, evidence ledger, first failed boundary, affected-action register, uncertainty, repair controls, regression checks, and an owner-bound proceed, contain, or investigate decision.
Boundaries:
Do not claim token inspection, policy evaluation, revocation, containment, or remediation without evidence. The security reviewer and relevant system or service owner decide containment and risk acceptance; the release owner controls restart or deployment. Source grounding: AMO-P-000285. Applicable Workflow: AMO-W-000012.
Powered by an Amo.ng Prompt
Agent Identity and Delegated Authorization Failure Review
Open the linked prompt to use the instructions that power this Skill.
Completion criteria
Complete when every material action has a supported, contradicted, or unresolved principal chain; delegation scope and revocation state are explicit; the first failed boundary is evidence-linked; affected actions and uncertainty are bounded; and repair plus regression gates have accountable owners.
Was this useful?
Explore related Workflows
Browse WorkflowsInvestigate 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.
Related Prompts
Browse PromptsBuild an AI Support Triage Integration from an Approved Pilot
Implement a bounded AI-assisted support-triage integration in a sandbox or shadow environment, with abstention, grounded drafting, routing, injection tests, manual fallback, and disablement evidence.
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.
Automate CRM Lead Capture and Routing in a Sandbox
Implement and verify CRM lead capture, consent, deduplication, qualification, routing, and SLA behavior in an authorized sandbox using synthetic test leads and disabled production activation.
Agent Escalation Threshold Calibration
Tune agent escalation triggers using incident severity, uncertainty, false-positive and false-negative evidence, queue capacity, delay, and owner authority.
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.
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.