Amo.ng curated workflow
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.
# Investigate an AI Agent Security Incident Workflow ID: AMO-W-000012 Workflow URL: https://amo.ng/workflows/ai-agent-security-incident-investigation ## Outcome An incident decision package containing the first supported coordination divergence, principal and delegation chain, sensitive-context lineage, applicable memory or retrieval findings, affected scope, containment actions, recovery conditions, and regression evidence requirements. ## Before you begin - Incident symptoms, impact, time window, and affected environments - Agent roles, handoff contracts, tools, identities, permissions, and shared-state design - Sanitized traces, logs, messages, state or memory records, retrieval evidence, and incident tickets - Expected authorization, tenant, purpose, region, retention, and data-handling boundaries - Known changes, containment already performed, operational constraints, and accountable owners ## Step 1 — Reconstruct the coordination failure **Prompt** Multi-Agent Coordination Failure Reconstruction **Instructions** Use the incident evidence to build the chronology, identify the first coordination divergence, compare plausible mechanisms, and draft the smallest testable correction to the failed handoff or shared-state contract. **Input for this step** Supply the incident scope, agent roles, expected handoffs, messages or traces, shared-state evidence, observed impact, and authorized investigation boundary. **Carry forward** Carry the evidence inventory, chronology, first-divergence finding, competing hypotheses, affected agents or state, evidence gaps, and discriminating tests into the authority review. **Review note** The incident owner and service owner confirm the investigation boundary and whether the first-divergence finding is sufficiently supported to guide the next reviews. **Prompt ID** AMO-P-000271 **Prompt URL** https://amo.ng/prompts/multi-agent-coordination-failure-reconstruction **Prompt content** Reconstruct the coordination failure across multiple agents and identify the first coordination divergence that can be corrected and tested. Inputs to provide: - Agent roles and authority: [Agent roles and authority] - Coordination evidence: [Coordination evidence] - Expected handoff contract: [Expected handoff contract] - Shared-state context: [Shared-state context] - Observed failure and impact: [Observed failure and impact] - Constraints and authorized changes: [Constraints and authorized changes] Evidence discipline: - Separate observed evidence from inference at every major step. - Do not claim that a log, trace, source file, system, test, approval, or action was inspected unless it is present in the provided material. - If timestamps, message ordering, state versions, ownership rules, or agent responsibilities are missing, name the gap and explain how it affects confidence. - Preserve uncertainty where the evidence supports more than one explanation. - Do not redesign the entire multi-agent workflow. Focus on the smallest correction to the failed coordination point. - Do not produce a broad trace taxonomy. Use classification only where it helps isolate the first divergence. Reconstruction method: 1. Build an evidence inventory listing each provided artifact, what it can prove, and what it cannot prove. 2. Create a coordination chronology from the earliest relevant trigger through the failure manifestation. 3. Map responsibility, authority, and shared-state access for each involved agent. 4. Compare expected coordination behavior against observed behavior. 5. Identify the first point where delegation, handoff, ownership, message ordering, or shared state diverged from the expected contract. 6. Decide the most likely failure mechanism and explain why competing mechanisms are less supported. 7. Define discriminating tests that could confirm or falsify the proposed mechanism. 8. Draft a corrected handoff contract that is narrow, testable, and preserves intended existing behavior. Deliverable format: 1. Evidence inventory Provide a table with columns: - Artifact - Evidence observed - Reliability or limitation - Coordination question it helps answer - Missing information, if any 2. Coordination chronology Provide an ordered table with columns: - Step or timestamp - Agent - Message, action, or state operation - Intended recipient or owner - Shared state read or written - Expected behavior - Observed behavior - Evidence reference - Observation vs inference - Confidence: high, medium, or low 3. Responsibility and state map For each relevant agent, list: - Delegated responsibility - Decision authority - Required inputs - State it may read - State it may write - Handoff obligations - Acknowledgment or completion signal - Actual behavior seen in evidence - Ownership ambiguity or conflict, if any Then list shared-state objects or records with: - State object - Expected owner - Writers - Readers - Versioning or ordering assumption - Observed mutation or stale-read risk - Evidence supporting the risk 4. First coordination divergence State the earliest supported divergence in one sentence. Then provide: - Divergence type: delegation gap, handoff ambiguity, ownership conflict, message-ordering violation, stale shared state, unauthorized state mutation, missing acknowledgment, retry/idempotency failure, or other specified mechanism - Exact expected contract at that point - Exact observed deviation - Why this is earlier than downstream symptoms - Evidence supporting the decision - Confidence level - What evidence would change the conclusion 5. Failure mechanism decision Compare the leading mechanism against plausible alternatives in a table: - Candidate mechanism - Supporting evidence - Contradicting or missing evidence - Predicted observable signal - Decision: selected, possible, unlikely, or not assessable 6. Discriminating tests Propose 3 to 6 tests or checks that the accountable engineering, automation, or operations owner can run. For each, include: - Hypothesis tested - Setup or evidence required - Expected signal if the mechanism is correct - Expected signal if the mechanism is wrong - Owner best placed to verify - Risk of false positive or false negative Prefer tests that distinguish between message-ordering, ownership, handoff, and shared-state causes rather than merely reproducing the incident. 7. Corrected handoff contract Draft the smallest safe correction. Include: - Trigger condition - Sending agent - Receiving agent - Required payload or state reference - Preconditions - State version or ordering requirement - Acknowledgment rule - Completion signal - Timeout or retry behavior - Idempotency requirement - Conflict handling rule - Audit fields or log events needed for future reconstruction - Backward-compatibility or behavior-preservation note 8. Implementation boundary State what should not be changed yet because the evidence does not justify it. Call out any broad workflow redesign, new orchestration pattern, or policy change that would be premature. 9. Completion checks List observable criteria for considering this reconstruction complete, including: - The first divergence is identified or the blocking evidence gap is explicit. - The selected mechanism has at least one discriminating test. - The corrected handoff contract is narrow enough for the responsible owner to implement or reject. - The release owner, automation owner, or service owner can verify the proposed correction against logs, replay, tests, or production telemetry before adoption. ## Step 2 — Trace principal identity and delegated authority **Prompt** Agent Identity and Delegated Authorization Failure Review **Instructions** Reconstruct which principal acted, which identity or credential was presented, how authority was delegated, and where authorization context was lost, stale, broadened, or misapplied. **Input for this step** Use the coordination chronology plus identity claims, tokens or credential metadata, authorization policies, tool-call records, downstream audit logs, revocation evidence, and ownership rules. **Carry forward** Carry the principal chain, delegation defects, affected actions, evidence confidence, repair requirements, and authorization regression gates into the context-lineage review. **Review note** The security reviewer and relevant system owner verify the principal-chain evidence and decide whether any credential, session, connector, or workflow requires containment. **Prompt ID** AMO-P-000285 **Prompt URL** https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review **Prompt content** 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. ## Step 3 — Trace sensitive-context propagation **Prompt** Sensitive Context Propagation and Cross-Agent Contamination Audit **Instructions** Map sensitive context across agent handoffs, tools, retrieval, memory, logs, caches, and shared workspaces. Separate confirmed propagation from plausible exposure and identify purpose, tenant, retention, or minimization failures. **Input for this step** Supply the prior chronology and principal chain with representative payloads, handoff records, context or memory configuration, data classifications, tenant and purpose rules, logging behavior, and retention evidence. **Carry forward** Carry the lineage map, contamination findings, affected data classes, propagation mechanisms, deletion or minimization needs, and unresolved exposure questions into conditional memory and retrieval investigations. **Review note** The data owner, privacy reviewer, and security reviewer confirm impact classification and authorize any deletion, notification, isolation, or retention decision. **Prompt ID** AMO-P-000286 **Prompt URL** https://amo.ng/prompts/sensitive-context-propagation-and-cross-agent-contamination-audit **Prompt content** Conduct an evidence-based audit of sensitive context propagation across the specified agent workflow. Trace actual context movement through handoffs, memory, retrieval, tools, logs, outputs, and shared workspaces. Do not produce a generic sensitive-data checklist. Separate observed evidence from inference, expose missing information, and preserve uncertainty. Context to provide: - System or workflow under review: [System or workflow under review] - Authorized purposes and tenant boundaries: [Authorized purposes and tenant boundaries] - Sensitive context categories: [Sensitive context categories] - Evidence package: [Evidence package] - Known incidents or concerns: [Known incidents or concerns] - Accountable owners: [Accountable owners] - Review date range: [Review date range] Evidence rules: - Use only the evidence provided in [Evidence package] and clearly identified user-supplied context. - Do not claim that a source, system, log, tool, workspace, approval, command, or deletion was inspected or completed unless evidence is present. - Label each material statement as one of: Observed, Inferred, Not evidenced, or Requires owner confirmation. - Distinguish sensitive context from ordinary workflow context. - Distinguish authorized propagation from unauthorized propagation, excessive retention, purpose drift, and cross-tenant or cross-task contamination. - If evidence is incomplete, state the missing artifact and why it matters. Audit scope: Trace sensitive context across these surfaces where evidence exists: 1. User inputs, uploaded files, tickets, records, conversations, or task instructions. 2. Agent-to-agent handoffs, delegation messages, intermediate reasoning summaries, or task state objects. 3. Short-term memory, long-term memory, vector stores, retrieval indexes, embeddings, caches, and session stores. 4. Tool calls, API payloads, browser sessions, database queries, SaaS integrations, webhooks, automations, and background jobs. 5. Logs, traces, analytics events, evaluation datasets, transcripts, error reports, monitoring records, and support workspaces. 6. Shared folders, project workspaces, collaboration tools, exported artifacts, generated documents, and downstream notifications. 7. Human review queues, escalation paths, approval records, and operator notes. Required deliverable: 1. Audit Boundary and Evidence Inventory Create a concise table with: - Evidence item - Source or owner if known - Date range covered - Context surfaces covered - Reliability limits - Material gaps 2. Context Lineage Map Create a lineage table that traces each sensitive context category through the workflow: - Context item or category - Origin - Initial authorized purpose - Receiving agent, service, tool, memory store, log, workspace, or person - Transfer mechanism - Transformation or summarization performed - Retention location and retention duration if evidenced - Tenant, customer, project, task, or workspace boundary crossed - Evidence reference - Status: authorized, questionable, unauthorized, excessive, contaminated, or not evidenced Then provide a short narrative explaining the highest-risk propagation paths. Do not infer a path merely because it is technically possible; identify it as a hypothesis if not evidenced. 3. Sensitivity and Purpose Register Create a register with: - Sensitive context category - Sensitivity rationale - Data subject, tenant, customer, project, or task boundary affected - Authorized purpose from [Authorized purposes and tenant boundaries] - Actual observed use - Purpose alignment: aligned, narrowed, expanded, drifted, unrelated, or not evidenced - Minimum context needed for the task - Excess context observed - Owner accountable for purpose decision from [Accountable owners], or owner not identified 4. Cross-Agent and Cross-Boundary Contamination Findings For each finding, include: - Finding title - Evidence basis - Contamination type: cross-agent, cross-tenant, cross-task, cross-customer, cross-project, memory reuse, retrieval bleed, logging exposure, tool propagation, workspace exposure, or purpose drift - Affected context - Affected boundary - How the propagation occurred or is suspected to occur - Impact on confidentiality, integrity, compliance, customer trust, operational safety, or decision quality - Likelihood rating: evidenced, plausible, weakly supported, or unknown - Severity rating: critical, high, medium, low, or informational - Confidence level and reason - Missing evidence that would change the rating 5. Minimization and Containment Controls Propose controls tied to the observed lineage, not generic policy slogans. For each control, include: - Propagation point addressed - Control objective - Specific change to inputs, prompts, handoff schema, memory policy, retrieval filtering, tool payloads, logging, access control, workspace permissions, retention, or operator procedure - Expected reduction in sensitive context exposure - Owner responsible for implementation - Verification method - Residual risk Prioritize smallest effective controls that reduce propagation without breaking the authorized workflow. Avoid broad rewrites unless the evidence shows the workflow design itself is unsafe. 6. Deletion, Quarantine, and Revalidation Plan Create an action plan with: - Artifact or location requiring deletion, quarantine, redaction, re-indexing, access review, or retention change - Reason action is needed - Required owner approval: data owner, security reviewer, legal/privacy owner, product owner, platform owner, or customer account owner as appropriate - Preconditions before action - Execution evidence needed after action - Revalidation test or sampling method - Rollback or exception handling if deletion would impair legal hold, auditability, customer support, or service reliability Do not state that deletion, quarantine, redaction, or re-indexing has been completed. State only the plan and the evidence needed to verify completion. 7. Open Questions and Owner Decisions List unresolved questions that materially affect risk or remediation. For each, identify: - Question - Why it matters - Evidence needed - Accountable owner from [Accountable owners], or owner not identified - Decision deadline if inferable from [Known incidents or concerns] 8. Completion Check End with a completion check stating whether the audit is ready for owner review. Include: - Whether every sensitive context category in [Sensitive context categories] was traced or marked not evidenced - Whether every material propagation path has an evidence reference or uncertainty label - Whether contamination findings are tied to actual lineage evidence - Whether minimization controls map to specific propagation points - Whether deletion and revalidation actions identify accountable owners and verification evidence - Remaining blockers before security reviewer, data owner, product owner, or platform owner decision ## Step 4 — Investigate persistent memory when applicable **Prompt** Agent Memory Integrity and Poisoning Investigation **Instructions** Run this step only when persistent memory could have introduced, retained, or propagated the failure. Otherwise record Not applicable and the evidence supporting that boundary. When applicable, reconstruct memory provenance, poisoning hypotheses, affected decisions, quarantine posture, and recovery gate. **Input for this step** Provide the context-lineage findings, memory stores and schemas, write and retrieval paths, memory records, audit history, retention rules, suspicious symptoms, and recovery authority boundaries. **Carry forward** Carry the memory provenance ledger, supported poisoning or integrity conclusion, affected decisions, quarantine state, recovery prerequisites, and remaining uncertainty to the final authorization-boundary review. **Review note** The memory service owner and data owner authorize quarantine, correction, deletion, re-attribution, or restoration; absence of memory evidence must not be treated as proof of integrity. **Prompt ID** AMO-P-000272 **Prompt URL** https://amo.ng/prompts/agent-memory-integrity-and-poisoning-investigation **Prompt content** Investigate whether persistent agent memory was altered, misattributed, over-retained, or poisoned, and produce an evidence-backed containment and recovery decision. Context to provide: - Agent or system name: [Agent or system name] - Investigation window: [Investigation window] - Memory stores and schemas: [Memory stores and schemas] - Available evidence: [Available evidence] - Known suspicious symptoms: [Known suspicious symptoms] - Decision owner: [Decision owner] - Recovery authority boundaries: [Recovery authority boundaries] Evidence rules: - Use only the evidence provided in [Available evidence]. Do not claim that logs, traces, memory stores, tickets, approvals, tests, commands, or source files were inspected unless they are included or quoted. - Separate observations from inference. Label each inferred conclusion as low, medium, or high confidence. - Preserve uncertainty. If a required fact is missing, state exactly what evidence is needed and why it matters. - Before attributing compromise or selecting containment, separate blocking gaps from non-blocking gaps. Request all blocking evidence in one consolidated clarification and stop the affected conclusion until it is supplied. Continue past non-blocking gaps only when they are recorded as Unknown with their effect on confidence, scope, containment, and recovery. - Do not broaden this into a general agent security audit or a generic trace taxonomy. Stay focused on persistent memory integrity, provenance, poisoning, retention, attribution, and recovery. - Treat containment and recovery as accountable operational decisions. If an action exceeds [Recovery authority boundaries], identify the responsible owner or function that must decide. Investigation method: 1. Establish scope - Define which memory stores, records, embeddings, summaries, preference stores, tool-state caches, user profile memories, system memories, and derived memories are in scope based on [Memory stores and schemas]. - Identify what is out of scope and any assumptions required because evidence is missing. 2. Build a memory provenance ledger Create a ledger table with these columns: - Memory item or record ID - Current stored claim or value - Memory type or store - First observed timestamp, if known - Last modified timestamp, if known - Claimed source or author - Evidence supporting source attribution - Write or update path - Retention basis or deletion expectation - Integrity concern: none, altered, misattributed, over-retained, suspicious insertion, suspicious deletion, unverifiable - Confidence level - Evidence references - Required follow-up evidence 3. Reconstruct write paths For each memory store or memory type, reconstruct: - Authorized writers and expected write triggers - Observed or reported writes during [Investigation window] - Transformation steps from raw input to persisted memory - Summarization, embedding, deduplication, merge, overwrite, deletion, or compaction behavior - Identity and attribution mechanisms used at write time - Retention and deletion controls - Plausible bypasses, race conditions, stale-cache paths, ingestion errors, or cross-user contamination paths - Evidence gaps that prevent confirmation 4. Develop a poisoning hypothesis matrix Create a matrix with these columns: - Hypothesis - Poisoning or integrity failure mechanism - Memory items affected - Supporting observations - Contradicting observations - Missing evidence needed - Likelihood: low, medium, high, or indeterminate - Potential blast radius - Immediate containment implication Include at least these hypothesis categories when relevant to the evidence: - Malicious prompt or tool output caused durable memory insertion - Benign user input was misattributed to another user, tenant, workflow, or authority - Summarization or consolidation distorted source meaning - Outdated memory was over-retained after deletion, revocation, policy change, or user correction - Memory merge or deduplication combined incompatible identities, accounts, or contexts - Retrieval surfaced poisoned or stale memory into later decisions - Administrative, migration, sync, or backfill process altered memory incorrectly - Evidence does not support a memory poisoning finding, but confidence is limited 5. Map affected decisions Create an affected-decision map with these columns: - Decision, action, response, workflow, or automation potentially influenced - Memory items used or likely retrieved - Evidence of use versus plausible exposure - Business, safety, security, privacy, financial, or user impact - Reversibility - Owner accountable for review - Required validation before relying on the decision again Do not assume a decision was affected solely because a memory item exists. Distinguish confirmed use, likely use, possible use, and no evidence of use. 6. Decide containment posture Recommend one of these containment states for each affected memory store or memory class: - No containment needed based on current evidence - Monitor only - Read-only quarantine - Retrieval suppression - Write suspension - Record-level deletion or correction pending owner approval - Full memory store isolation - Agent workflow suspension For each recommendation, provide: - Evidence basis - Risk reduced - Operational cost or user impact - Decision owner required - Time sensitivity - Reversal condition 7. Define recovery gate Produce a quarantine and recovery gate that [Decision owner] can use. Include: - Minimum evidence required before restoring memory retrieval or writes - Records that must be corrected, deleted, re-attributed, or re-generated - Regression checks or replay checks needed, if evidence supports them - Owner approvals required under [Recovery authority boundaries] - Monitoring signals after restoration - Conditions that require escalation rather than recovery 8. Final decision artifact End with a concise decision record: - Investigation conclusion: confirmed compromise, likely compromise, possible compromise, no compromise found, or indeterminate - Confidence and primary uncertainty - Memory stores or records requiring action - Affected decisions requiring review - Immediate containment decision - Recovery gate status: not ready, conditionally ready, or ready - Named accountable owner for the next decision - Evidence not available that would materially change the conclusion Completion checks before finalizing: - Every material conclusion cites evidence from [Available evidence] or is explicitly labeled as inference. - The memory provenance ledger, write-path reconstruction, poisoning hypothesis matrix, affected-decision map, and quarantine/recovery gate are all included. - Missing evidence is stated plainly rather than filled with assumptions. - No source, system, command, test, approval, or inspection is claimed without corresponding evidence. - The recommended action stays within [Recovery authority boundaries] or identifies the accountable owner who must authorize it. ## Step 5 — Investigate RAG authorization exposure when applicable **Prompt** RAG Access-Control Leakage Investigation **Instructions** Run this step when retrieval, embeddings, citations, caches, or corpus authorization could have exposed data across identity, tenant, purpose, region, or document boundaries. Otherwise record Not applicable and why. Reconcile its findings with the principal and context-lineage evidence. **Input for this step** Provide query and response traces, retrieved document or citation evidence, document ACLs, identity and tenant context, ingestion and cache records, authorization policies, and the prior incident findings. **Carry forward** Produce the final incident package: authorization map, affected scope, containment decision, memory or RAG conditions, repair priorities, regression matrix, recovery gate, owners, and evidence still required. **Review note** The incident owner, security reviewer, data owner, and release owner make the contain, recover, restrict, or continue-investigation decision. **Prompt ID** AMO-P-000283 **Prompt URL** https://amo.ng/prompts/rag-access-control-leakage-investigation **Prompt content** Investigate whether the RAG system described below retrieved, embedded, cached, cited, or exposed content outside the requesting identity, tenant, purpose, region, or document authorization boundary. Do not perform a general RAG quality review, connector security review, model safety review, or relevance evaluation unless it directly affects authorization leakage evidence. Use only the evidence provided. Do not claim that a log, policy, source, command, system, test, approval, or remediation was inspected or completed unless it is present in the supplied materials. Context and inputs: - RAG system and deployment context: [RAG system and deployment context] - Identity, tenant, purpose, region, and document authorization model: [Identity tenant purpose region and document authorization model] - Evidence bundle, including any retrieval logs, citation traces, document ACLs, embedding ingestion records, cache records, query logs, response samples, tickets, diagrams, or policy excerpts: [Evidence bundle] - Suspected leakage scenarios or query samples: [Suspected leakage scenarios or query samples] - Time window and affected environments: [Time window and affected environments] - Accountable owners and decision deadline: [Accountable owners and decision deadline] Investigation rules: 1. Separate observations from inference. Label each material statement as Evidence, Inference, Gap, or Decision. 2. Preserve uncertainty. If evidence is missing, conflicting, sampled, redacted, or outside the time window, say so plainly. Missing-input gate: - Treat the requesting identity, applicable authorization model, affected environment and time window, and sufficient retrieval or exposure traces as blocking for any confirmed leakage conclusion. Request all blocking items in one consolidated clarification and stop the affected conclusion until they are supplied. - Continue with non-blocking gaps only when they are marked Unknown and their effect on path confidence, affected scope, containment, and regression coverage is explicit. 3. Trace authorization from requesting identity to document exposure. Include retrieval, ranking, embedding, cache, citation, prompt assembly, generated response, export, telemetry, and feedback paths where evidence exists. 4. Treat access-control boundaries independently: identity, tenant, purpose, region, document-level authorization, group membership, delegated access, service account access, and temporal entitlement changes. 5. Distinguish content that was indexed, embedded, retrieved, ranked, cached, cited, included in context, generated in the answer, logged, or externally exposed. 6. Do not assume that document-level authorization at source ingestion remains valid at query time. Look for entitlement drift, stale indexes, overbroad service accounts, cache reuse, citation leakage, and post-filter bypass. 7. Do not recommend broad rewrites. Recommend the smallest containment and verification actions that fit the observed risk. 8. Assign owner accountability by role where needed: security reviewer, data owner, product owner, release owner, search/retrieval owner, platform owner, or legal/privacy owner. Deliverable: 1. Investigation scope - State the system, environments, time window, suspected boundary, and query/document populations covered. - State what is explicitly out of scope. - List the supplied evidence types and any major missing evidence. 2. Evidence register Create a table with columns: - Evidence ID - Evidence type - Source or artifact name - Time range - What it shows - Authorization boundary relevance - Limitations or uncertainty 3. Identity-to-document authorization map Create a map or table showing: - Requesting identity or role - Tenant or account - Purpose or workflow - Region or data residency boundary - Entitlement source - Allowed document classes or IDs - Disallowed document classes or IDs - Query-time enforcement point - Retrieval/index/cache/citation enforcement point - Evidence supporting the mapping - Gaps requiring owner confirmation 4. Leakage-path reconstruction For each suspected or observed leakage path, reconstruct the sequence from request to exposure: - Query or trigger - Requesting identity and authorization state at the time - Retrieval/index candidate set - Filter or authorization check expected - Filter or authorization check observed - Document, chunk, citation, cache entry, embedding, or response involved - Exposure mode: retrieved, ranked, cached, cited, placed in prompt context, generated in response, logged, exported, or visible in UI/API - Boundary crossed: identity, tenant, purpose, region, document authorization, or timing/entitlement drift - Evidence supporting the path - Alternative explanations - Confidence level: confirmed, probable, possible, or not supported 5. Affected corpus and query scope Estimate the likely scope without overstating certainty: - Affected tenants, identities, groups, regions, document classes, indexes, embeddings, caches, and environments - Query patterns likely to trigger the issue - Whether exposure appears isolated, systemic, configuration-specific, connector-specific, cache-specific, or time-bound - Known false-positive or false-negative risks in the evidence - Additional evidence needed to narrow scope 6. Containment decision Provide a decision-ready containment assessment for the accountable owners: - Immediate risk level and rationale - Recommended containment action: no action, monitor, disable affected queries, invalidate cache, remove affected index, restrict service account, re-ingest with corrected ACLs, disable citation/source display, tenant isolate, region isolate, or pause release - Why this is the smallest safe containment action supported by the evidence - Operational impact - Data owner, security reviewer, product owner, and release owner decisions required - Conditions for lifting containment 7. Regression test matrix Create a test matrix that can be used by engineering and security reviewers. Include: - Test ID - Boundary tested - Test identity or role - Allowed corpus - Forbidden corpus - Query pattern - Expected retrieval behavior - Expected citation behavior - Expected cache behavior - Expected response behavior - Required logs or traces - Pass/fail criteria - Owner responsible for verification Include tests for at least: - Same-tenant allowed document retrieval - Same-tenant forbidden document exclusion - Cross-tenant exclusion - Region boundary exclusion - Purpose-boundary exclusion where applicable - Stale group membership or entitlement removal - Cache reuse across identities or tenants - Citation/source leakage without answer leakage - Embedding/index rebuild after ACL correction - Service account or delegated access path 8. Open questions and evidence requests List only the missing items that materially affect the containment decision, scope estimate, or regression coverage. Assign each request to a specific owner role. 9. Completion checks End with a concise checklist confirming whether the current evidence is sufficient to: - Determine if leakage occurred - Identify the likely leakage path - Estimate affected corpus and query scope - Make a containment decision - Define regression tests - Proceed to remediation planning If any check cannot be completed from the supplied evidence, mark it as incomplete and explain the exact missing evidence. ## Completion criteria The workflow is complete when: - The earliest supported coordination divergence and principal chain are traceable to supplied evidence. - Sensitive-context exposure is classified as confirmed, likely, possible, unsupported, or not assessable. - Memory and RAG investigations are completed when applicable or explicitly marked Not applicable with a reason. - Containment, recovery, and regression conditions identify evidence, owners, stop conditions, and unresolved uncertainty. - No action, test, inspection, approval, or recovery is represented as completed without corresponding evidence. # Investigate an AI Agent Security Incident Workflow ID: AMO-W-000012 Workflow URL: https://amo.ng/workflows/ai-agent-security-incident-investigation Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: An incident decision package containing the first supported coordination divergence, principal and delegation chain, sensitive-context lineage, applicable memory or retrieval findings, affected scope, containment actions, recovery conditions, and regression evidence requirements. Required inputs: - Incident symptoms, impact, time window, and affected environments - Agent roles, handoff contracts, tools, identities, permissions, and shared-state design - Sanitized traces, logs, messages, state or memory records, retrieval evidence, and incident tickets - Expected authorization, tenant, purpose, region, retention, and data-handling boundaries - Known changes, containment already performed, operational constraints, and accountable owners ## Step 1 — Reconstruct the coordination failure **Instructions** Use the incident evidence to build the chronology, identify the first coordination divergence, compare plausible mechanisms, and draft the smallest testable correction to the failed handoff or shared-state contract. **Input for this step** Supply the incident scope, agent roles, expected handoffs, messages or traces, shared-state evidence, observed impact, and authorized investigation boundary. **Carry forward** Carry the evidence inventory, chronology, first-divergence finding, competing hypotheses, affected agents or state, evidence gaps, and discriminating tests into the authority review. **Review note** The incident owner and service owner confirm the investigation boundary and whether the first-divergence finding is sufficiently supported to guide the next reviews. **Prompt** Multi-Agent Coordination Failure Reconstruction **Prompt ID** AMO-P-000271 **Prompt URL** https://amo.ng/prompts/multi-agent-coordination-failure-reconstruction ## Step 2 — Trace principal identity and delegated authority **Instructions** Reconstruct which principal acted, which identity or credential was presented, how authority was delegated, and where authorization context was lost, stale, broadened, or misapplied. **Input for this step** Use the coordination chronology plus identity claims, tokens or credential metadata, authorization policies, tool-call records, downstream audit logs, revocation evidence, and ownership rules. **Carry forward** Carry the principal chain, delegation defects, affected actions, evidence confidence, repair requirements, and authorization regression gates into the context-lineage review. **Review note** The security reviewer and relevant system owner verify the principal-chain evidence and decide whether any credential, session, connector, or workflow requires containment. **Prompt** Agent Identity and Delegated Authorization Failure Review **Prompt ID** AMO-P-000285 **Prompt URL** https://amo.ng/prompts/agent-identity-and-delegated-authorization-failure-review ## Step 3 — Trace sensitive-context propagation **Instructions** Map sensitive context across agent handoffs, tools, retrieval, memory, logs, caches, and shared workspaces. Separate confirmed propagation from plausible exposure and identify purpose, tenant, retention, or minimization failures. **Input for this step** Supply the prior chronology and principal chain with representative payloads, handoff records, context or memory configuration, data classifications, tenant and purpose rules, logging behavior, and retention evidence. **Carry forward** Carry the lineage map, contamination findings, affected data classes, propagation mechanisms, deletion or minimization needs, and unresolved exposure questions into conditional memory and retrieval investigations. **Review note** The data owner, privacy reviewer, and security reviewer confirm impact classification and authorize any deletion, notification, isolation, or retention decision. **Prompt** Sensitive Context Propagation and Cross-Agent Contamination Audit **Prompt ID** AMO-P-000286 **Prompt URL** https://amo.ng/prompts/sensitive-context-propagation-and-cross-agent-contamination-audit ## Step 4 — Investigate persistent memory when applicable **Instructions** Run this step only when persistent memory could have introduced, retained, or propagated the failure. Otherwise record Not applicable and the evidence supporting that boundary. When applicable, reconstruct memory provenance, poisoning hypotheses, affected decisions, quarantine posture, and recovery gate. **Input for this step** Provide the context-lineage findings, memory stores and schemas, write and retrieval paths, memory records, audit history, retention rules, suspicious symptoms, and recovery authority boundaries. **Carry forward** Carry the memory provenance ledger, supported poisoning or integrity conclusion, affected decisions, quarantine state, recovery prerequisites, and remaining uncertainty to the final authorization-boundary review. **Review note** The memory service owner and data owner authorize quarantine, correction, deletion, re-attribution, or restoration; absence of memory evidence must not be treated as proof of integrity. **Prompt** Agent Memory Integrity and Poisoning Investigation **Prompt ID** AMO-P-000272 **Prompt URL** https://amo.ng/prompts/agent-memory-integrity-and-poisoning-investigation ## Step 5 — Investigate RAG authorization exposure when applicable **Instructions** Run this step when retrieval, embeddings, citations, caches, or corpus authorization could have exposed data across identity, tenant, purpose, region, or document boundaries. Otherwise record Not applicable and why. Reconcile its findings with the principal and context-lineage evidence. **Input for this step** Provide query and response traces, retrieved document or citation evidence, document ACLs, identity and tenant context, ingestion and cache records, authorization policies, and the prior incident findings. **Carry forward** Produce the final incident package: authorization map, affected scope, containment decision, memory or RAG conditions, repair priorities, regression matrix, recovery gate, owners, and evidence still required. **Review note** The incident owner, security reviewer, data owner, and release owner make the contain, recover, restrict, or continue-investigation decision. **Prompt** RAG Access-Control Leakage Investigation **Prompt ID** AMO-P-000283 **Prompt URL** https://amo.ng/prompts/rag-access-control-leakage-investigation Completion criteria: The workflow is complete when: - The earliest supported coordination divergence and principal chain are traceable to supplied evidence. - Sensitive-context exposure is classified as confirmed, likely, possible, unsupported, or not assessable. - Memory and RAG investigations are completed when applicable or explicitly marked Not applicable with a reason. - Containment, recovery, and regression conditions identify evidence, owners, stop conditions, and unresolved uncertainty. - No action, test, inspection, approval, or recovery is represented as completed without corresponding evidence.Copy workflow includes every step and the full linked Prompt content. Use with AI copies a shorter guide with Prompt links; neither action runs the Workflow.
Outcome
An incident decision package containing the first supported coordination divergence, principal and delegation chain, sensitive-context lineage, applicable memory or retrieval findings, affected scope, containment actions, recovery conditions, and regression evidence requirements.
Before you begin
Have all or some of the following available before you start. The more relevant context you can provide, the stronger the workflow output will be.
- Incident symptoms, impact, time window, and affected environments
- Agent roles, handoff contracts, tools, identities, permissions, and shared-state design
- Sanitized traces, logs, messages, state or memory records, retrieval evidence, and incident tickets
- Expected authorization, tenant, purpose, region, retention, and data-handling boundaries
- Known changes, containment already performed, operational constraints, and accountable owners
Ordered sequence
Workflow steps
Complete the steps in order. For each step, provide the listed context, carry its result into the next step, and pause wherever a review note is shown.
-
Step 1 Reconstruct the coordination failure
Use the incident evidence to build the chronology, identify the first coordination divergence, compare plausible mechanisms, and draft the smallest testable correction to the failed handoff or shared-state contract.
Prompt: Multi-Agent Coordination Failure ReconstructionReconstruct the coordination failure across multiple agents and identify the first coordination divergence that can be corrected and tested. Inputs to provide: - Agent roles and authority: [Agent roles and authority] - Coordination evidence: [Coordination evidence] - Expected handoff contract: [Expected handoff contract] - Shared-state context: [Shared-state context] - Observed failure and impact: [Observed failure and impact] - Constraints and authorized changes: [Constraints and authorized changes] Evidence discipline: - Separate observed evidence from inference at every major step. - Do not claim that a log, trace, source file, system, test, approval, or action was inspected unless it is present in the provided material. - If timestamps, message ordering, state versions, ownership rules, or agent responsibilities are missing, name the gap and explain how it affects confidence. - Preserve uncertainty where the evidence supports more than one explanation. - Do not redesign the entire multi-agent workflow. Focus on the smallest correction to the failed coordination point. - Do not produce a broad trace taxonomy. Use classification only where it helps isolate the first divergence. Reconstruction method: 1. Build an evidence inventory listing each provided artifact, what it can prove, and what it cannot prove. 2. Create a coordination chronology from the earliest relevant trigger through the failure manifestation. 3. Map responsibility, authority, and shared-state access for each involved agent. 4. Compare expected coordination behavior against observed behavior. 5. Identify the first point where delegation, handoff, ownership, message ordering, or shared state diverged from the expected contract. 6. Decide the most likely failure mechanism and explain why competing mechanisms are less supported. 7. Define discriminating tests that could confirm or falsify the proposed mechanism. 8. Draft a corrected handoff contract that is narrow, testable, and preserves intended existing behavior. Deliverable format: 1. Evidence inventory Provide a table with columns: - Artifact - Evidence observed - Reliability or limitation - Coordination question it helps answer - Missing information, if any 2. Coordination chronology Provide an ordered table with columns: - Step or timestamp - Agent - Message, action, or state operation - Intended recipient or owner - Shared state read or written - Expected behavior - Observed behavior - Evidence reference - Observation vs inference - Confidence: high, medium, or low 3. Responsibility and state map For each relevant agent, list: - Delegated responsibility - Decision authority - Required inputs - State it may read - State it may write - Handoff obligations - Acknowledgment or completion signal - Actual behavior seen in evidence - Ownership ambiguity or conflict, if any Then list shared-state objects or records with: - State object - Expected owner - Writers - Readers - Versioning or ordering assumption - Observed mutation or stale-read risk - Evidence supporting the risk 4. First coordination divergence State the earliest supported divergence in one sentence. Then provide: - Divergence type: delegation gap, handoff ambiguity, ownership conflict, message-ordering violation, stale shared state, unauthorized state mutation, missing acknowledgment, retry/idempotency failure, or other specified mechanism - Exact expected contract at that point - Exact observed deviation - Why this is earlier than downstream symptoms - Evidence supporting the decision - Confidence level - What evidence would change the conclusion 5. Failure mechanism decision Compare the leading mechanism against plausible alternatives in a table: - Candidate mechanism - Supporting evidence - Contradicting or missing evidence - Predicted observable signal - Decision: selected, possible, unlikely, or not assessable 6. Discriminating tests Propose 3 to 6 tests or checks that the accountable engineering, automation, or operations owner can run. For each, include: - Hypothesis tested - Setup or evidence required - Expected signal if the mechanism is correct - Expected signal if the mechanism is wrong - Owner best placed to verify - Risk of false positive or false negative Prefer tests that distinguish between message-ordering, ownership, handoff, and shared-state causes rather than merely reproducing the incident. 7. Corrected handoff contract Draft the smallest safe correction. Include: - Trigger condition - Sending agent - Receiving agent - Required payload or state reference - Preconditions - State version or ordering requirement - Acknowledgment rule - Completion signal - Timeout or retry behavior - Idempotency requirement - Conflict handling rule - Audit fields or log events needed for future reconstruction - Backward-compatibility or behavior-preservation note 8. Implementation boundary State what should not be changed yet because the evidence does not justify it. Call out any broad workflow redesign, new orchestration pattern, or policy change that would be premature. 9. Completion checks List observable criteria for considering this reconstruction complete, including: - The first divergence is identified or the blocking evidence gap is explicit. - The selected mechanism has at least one discriminating test. - The corrected handoff contract is narrow enough for the responsible owner to implement or reject. - The release owner, automation owner, or service owner can verify the proposed correction against logs, replay, tests, or production telemetry before adoption.Input for this step
Supply the incident scope, agent roles, expected handoffs, messages or traces, shared-state evidence, observed impact, and authorized investigation boundary.
Carry forward
Carry the evidence inventory, chronology, first-divergence finding, competing hypotheses, affected agents or state, evidence gaps, and discriminating tests into the authority review.
Review note
The incident owner and service owner confirm the investigation boundary and whether the first-divergence finding is sufficiently supported to guide the next reviews.
-
Step 2 Trace principal identity and delegated authority
Reconstruct which principal acted, which identity or credential was presented, how authority was delegated, and where authorization context was lost, stale, broadened, or misapplied.
Prompt: Agent Identity and Delegated Authorization Failure ReviewReview 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.Input for this step
Use the coordination chronology plus identity claims, tokens or credential metadata, authorization policies, tool-call records, downstream audit logs, revocation evidence, and ownership rules.
Carry forward
Carry the principal chain, delegation defects, affected actions, evidence confidence, repair requirements, and authorization regression gates into the context-lineage review.
Review note
The security reviewer and relevant system owner verify the principal-chain evidence and decide whether any credential, session, connector, or workflow requires containment.
-
Step 3 Trace sensitive-context propagation
Map sensitive context across agent handoffs, tools, retrieval, memory, logs, caches, and shared workspaces. Separate confirmed propagation from plausible exposure and identify purpose, tenant, retention, or minimization failures.
Prompt: Sensitive Context Propagation and Cross-Agent Contamination AuditConduct an evidence-based audit of sensitive context propagation across the specified agent workflow. Trace actual context movement through handoffs, memory, retrieval, tools, logs, outputs, and shared workspaces. Do not produce a generic sensitive-data checklist. Separate observed evidence from inference, expose missing information, and preserve uncertainty. Context to provide: - System or workflow under review: [System or workflow under review] - Authorized purposes and tenant boundaries: [Authorized purposes and tenant boundaries] - Sensitive context categories: [Sensitive context categories] - Evidence package: [Evidence package] - Known incidents or concerns: [Known incidents or concerns] - Accountable owners: [Accountable owners] - Review date range: [Review date range] Evidence rules: - Use only the evidence provided in [Evidence package] and clearly identified user-supplied context. - Do not claim that a source, system, log, tool, workspace, approval, command, or deletion was inspected or completed unless evidence is present. - Label each material statement as one of: Observed, Inferred, Not evidenced, or Requires owner confirmation. - Distinguish sensitive context from ordinary workflow context. - Distinguish authorized propagation from unauthorized propagation, excessive retention, purpose drift, and cross-tenant or cross-task contamination. - If evidence is incomplete, state the missing artifact and why it matters. Audit scope: Trace sensitive context across these surfaces where evidence exists: 1. User inputs, uploaded files, tickets, records, conversations, or task instructions. 2. Agent-to-agent handoffs, delegation messages, intermediate reasoning summaries, or task state objects. 3. Short-term memory, long-term memory, vector stores, retrieval indexes, embeddings, caches, and session stores. 4. Tool calls, API payloads, browser sessions, database queries, SaaS integrations, webhooks, automations, and background jobs. 5. Logs, traces, analytics events, evaluation datasets, transcripts, error reports, monitoring records, and support workspaces. 6. Shared folders, project workspaces, collaboration tools, exported artifacts, generated documents, and downstream notifications. 7. Human review queues, escalation paths, approval records, and operator notes. Required deliverable: 1. Audit Boundary and Evidence Inventory Create a concise table with: - Evidence item - Source or owner if known - Date range covered - Context surfaces covered - Reliability limits - Material gaps 2. Context Lineage Map Create a lineage table that traces each sensitive context category through the workflow: - Context item or category - Origin - Initial authorized purpose - Receiving agent, service, tool, memory store, log, workspace, or person - Transfer mechanism - Transformation or summarization performed - Retention location and retention duration if evidenced - Tenant, customer, project, task, or workspace boundary crossed - Evidence reference - Status: authorized, questionable, unauthorized, excessive, contaminated, or not evidenced Then provide a short narrative explaining the highest-risk propagation paths. Do not infer a path merely because it is technically possible; identify it as a hypothesis if not evidenced. 3. Sensitivity and Purpose Register Create a register with: - Sensitive context category - Sensitivity rationale - Data subject, tenant, customer, project, or task boundary affected - Authorized purpose from [Authorized purposes and tenant boundaries] - Actual observed use - Purpose alignment: aligned, narrowed, expanded, drifted, unrelated, or not evidenced - Minimum context needed for the task - Excess context observed - Owner accountable for purpose decision from [Accountable owners], or owner not identified 4. Cross-Agent and Cross-Boundary Contamination Findings For each finding, include: - Finding title - Evidence basis - Contamination type: cross-agent, cross-tenant, cross-task, cross-customer, cross-project, memory reuse, retrieval bleed, logging exposure, tool propagation, workspace exposure, or purpose drift - Affected context - Affected boundary - How the propagation occurred or is suspected to occur - Impact on confidentiality, integrity, compliance, customer trust, operational safety, or decision quality - Likelihood rating: evidenced, plausible, weakly supported, or unknown - Severity rating: critical, high, medium, low, or informational - Confidence level and reason - Missing evidence that would change the rating 5. Minimization and Containment Controls Propose controls tied to the observed lineage, not generic policy slogans. For each control, include: - Propagation point addressed - Control objective - Specific change to inputs, prompts, handoff schema, memory policy, retrieval filtering, tool payloads, logging, access control, workspace permissions, retention, or operator procedure - Expected reduction in sensitive context exposure - Owner responsible for implementation - Verification method - Residual risk Prioritize smallest effective controls that reduce propagation without breaking the authorized workflow. Avoid broad rewrites unless the evidence shows the workflow design itself is unsafe. 6. Deletion, Quarantine, and Revalidation Plan Create an action plan with: - Artifact or location requiring deletion, quarantine, redaction, re-indexing, access review, or retention change - Reason action is needed - Required owner approval: data owner, security reviewer, legal/privacy owner, product owner, platform owner, or customer account owner as appropriate - Preconditions before action - Execution evidence needed after action - Revalidation test or sampling method - Rollback or exception handling if deletion would impair legal hold, auditability, customer support, or service reliability Do not state that deletion, quarantine, redaction, or re-indexing has been completed. State only the plan and the evidence needed to verify completion. 7. Open Questions and Owner Decisions List unresolved questions that materially affect risk or remediation. For each, identify: - Question - Why it matters - Evidence needed - Accountable owner from [Accountable owners], or owner not identified - Decision deadline if inferable from [Known incidents or concerns] 8. Completion Check End with a completion check stating whether the audit is ready for owner review. Include: - Whether every sensitive context category in [Sensitive context categories] was traced or marked not evidenced - Whether every material propagation path has an evidence reference or uncertainty label - Whether contamination findings are tied to actual lineage evidence - Whether minimization controls map to specific propagation points - Whether deletion and revalidation actions identify accountable owners and verification evidence - Remaining blockers before security reviewer, data owner, product owner, or platform owner decisionInput for this step
Supply the prior chronology and principal chain with representative payloads, handoff records, context or memory configuration, data classifications, tenant and purpose rules, logging behavior, and retention evidence.
Carry forward
Carry the lineage map, contamination findings, affected data classes, propagation mechanisms, deletion or minimization needs, and unresolved exposure questions into conditional memory and retrieval investigations.
Review note
The data owner, privacy reviewer, and security reviewer confirm impact classification and authorize any deletion, notification, isolation, or retention decision.
-
Step 4 Investigate persistent memory when applicable
Run this step only when persistent memory could have introduced, retained, or propagated the failure. Otherwise record Not applicable and the evidence supporting that boundary. When applicable, reconstruct memory provenance, poisoning hypotheses, affected decisions, quarantine posture, and recovery gate.
Prompt: Agent Memory Integrity and Poisoning InvestigationInvestigate whether persistent agent memory was altered, misattributed, over-retained, or poisoned, and produce an evidence-backed containment and recovery decision. Context to provide: - Agent or system name: [Agent or system name] - Investigation window: [Investigation window] - Memory stores and schemas: [Memory stores and schemas] - Available evidence: [Available evidence] - Known suspicious symptoms: [Known suspicious symptoms] - Decision owner: [Decision owner] - Recovery authority boundaries: [Recovery authority boundaries] Evidence rules: - Use only the evidence provided in [Available evidence]. Do not claim that logs, traces, memory stores, tickets, approvals, tests, commands, or source files were inspected unless they are included or quoted. - Separate observations from inference. Label each inferred conclusion as low, medium, or high confidence. - Preserve uncertainty. If a required fact is missing, state exactly what evidence is needed and why it matters. - Before attributing compromise or selecting containment, separate blocking gaps from non-blocking gaps. Request all blocking evidence in one consolidated clarification and stop the affected conclusion until it is supplied. Continue past non-blocking gaps only when they are recorded as Unknown with their effect on confidence, scope, containment, and recovery. - Do not broaden this into a general agent security audit or a generic trace taxonomy. Stay focused on persistent memory integrity, provenance, poisoning, retention, attribution, and recovery. - Treat containment and recovery as accountable operational decisions. If an action exceeds [Recovery authority boundaries], identify the responsible owner or function that must decide. Investigation method: 1. Establish scope - Define which memory stores, records, embeddings, summaries, preference stores, tool-state caches, user profile memories, system memories, and derived memories are in scope based on [Memory stores and schemas]. - Identify what is out of scope and any assumptions required because evidence is missing. 2. Build a memory provenance ledger Create a ledger table with these columns: - Memory item or record ID - Current stored claim or value - Memory type or store - First observed timestamp, if known - Last modified timestamp, if known - Claimed source or author - Evidence supporting source attribution - Write or update path - Retention basis or deletion expectation - Integrity concern: none, altered, misattributed, over-retained, suspicious insertion, suspicious deletion, unverifiable - Confidence level - Evidence references - Required follow-up evidence 3. Reconstruct write paths For each memory store or memory type, reconstruct: - Authorized writers and expected write triggers - Observed or reported writes during [Investigation window] - Transformation steps from raw input to persisted memory - Summarization, embedding, deduplication, merge, overwrite, deletion, or compaction behavior - Identity and attribution mechanisms used at write time - Retention and deletion controls - Plausible bypasses, race conditions, stale-cache paths, ingestion errors, or cross-user contamination paths - Evidence gaps that prevent confirmation 4. Develop a poisoning hypothesis matrix Create a matrix with these columns: - Hypothesis - Poisoning or integrity failure mechanism - Memory items affected - Supporting observations - Contradicting observations - Missing evidence needed - Likelihood: low, medium, high, or indeterminate - Potential blast radius - Immediate containment implication Include at least these hypothesis categories when relevant to the evidence: - Malicious prompt or tool output caused durable memory insertion - Benign user input was misattributed to another user, tenant, workflow, or authority - Summarization or consolidation distorted source meaning - Outdated memory was over-retained after deletion, revocation, policy change, or user correction - Memory merge or deduplication combined incompatible identities, accounts, or contexts - Retrieval surfaced poisoned or stale memory into later decisions - Administrative, migration, sync, or backfill process altered memory incorrectly - Evidence does not support a memory poisoning finding, but confidence is limited 5. Map affected decisions Create an affected-decision map with these columns: - Decision, action, response, workflow, or automation potentially influenced - Memory items used or likely retrieved - Evidence of use versus plausible exposure - Business, safety, security, privacy, financial, or user impact - Reversibility - Owner accountable for review - Required validation before relying on the decision again Do not assume a decision was affected solely because a memory item exists. Distinguish confirmed use, likely use, possible use, and no evidence of use. 6. Decide containment posture Recommend one of these containment states for each affected memory store or memory class: - No containment needed based on current evidence - Monitor only - Read-only quarantine - Retrieval suppression - Write suspension - Record-level deletion or correction pending owner approval - Full memory store isolation - Agent workflow suspension For each recommendation, provide: - Evidence basis - Risk reduced - Operational cost or user impact - Decision owner required - Time sensitivity - Reversal condition 7. Define recovery gate Produce a quarantine and recovery gate that [Decision owner] can use. Include: - Minimum evidence required before restoring memory retrieval or writes - Records that must be corrected, deleted, re-attributed, or re-generated - Regression checks or replay checks needed, if evidence supports them - Owner approvals required under [Recovery authority boundaries] - Monitoring signals after restoration - Conditions that require escalation rather than recovery 8. Final decision artifact End with a concise decision record: - Investigation conclusion: confirmed compromise, likely compromise, possible compromise, no compromise found, or indeterminate - Confidence and primary uncertainty - Memory stores or records requiring action - Affected decisions requiring review - Immediate containment decision - Recovery gate status: not ready, conditionally ready, or ready - Named accountable owner for the next decision - Evidence not available that would materially change the conclusion Completion checks before finalizing: - Every material conclusion cites evidence from [Available evidence] or is explicitly labeled as inference. - The memory provenance ledger, write-path reconstruction, poisoning hypothesis matrix, affected-decision map, and quarantine/recovery gate are all included. - Missing evidence is stated plainly rather than filled with assumptions. - No source, system, command, test, approval, or inspection is claimed without corresponding evidence. - The recommended action stays within [Recovery authority boundaries] or identifies the accountable owner who must authorize it.Input for this step
Provide the context-lineage findings, memory stores and schemas, write and retrieval paths, memory records, audit history, retention rules, suspicious symptoms, and recovery authority boundaries.
Carry forward
Carry the memory provenance ledger, supported poisoning or integrity conclusion, affected decisions, quarantine state, recovery prerequisites, and remaining uncertainty to the final authorization-boundary review.
Review note
The memory service owner and data owner authorize quarantine, correction, deletion, re-attribution, or restoration; absence of memory evidence must not be treated as proof of integrity.
-
Step 5 Investigate RAG authorization exposure when applicable
Run this step when retrieval, embeddings, citations, caches, or corpus authorization could have exposed data across identity, tenant, purpose, region, or document boundaries. Otherwise record Not applicable and why. Reconcile its findings with the principal and context-lineage evidence.
Prompt: RAG Access-Control Leakage InvestigationInvestigate whether the RAG system described below retrieved, embedded, cached, cited, or exposed content outside the requesting identity, tenant, purpose, region, or document authorization boundary. Do not perform a general RAG quality review, connector security review, model safety review, or relevance evaluation unless it directly affects authorization leakage evidence. Use only the evidence provided. Do not claim that a log, policy, source, command, system, test, approval, or remediation was inspected or completed unless it is present in the supplied materials. Context and inputs: - RAG system and deployment context: [RAG system and deployment context] - Identity, tenant, purpose, region, and document authorization model: [Identity tenant purpose region and document authorization model] - Evidence bundle, including any retrieval logs, citation traces, document ACLs, embedding ingestion records, cache records, query logs, response samples, tickets, diagrams, or policy excerpts: [Evidence bundle] - Suspected leakage scenarios or query samples: [Suspected leakage scenarios or query samples] - Time window and affected environments: [Time window and affected environments] - Accountable owners and decision deadline: [Accountable owners and decision deadline] Investigation rules: 1. Separate observations from inference. Label each material statement as Evidence, Inference, Gap, or Decision. 2. Preserve uncertainty. If evidence is missing, conflicting, sampled, redacted, or outside the time window, say so plainly. Missing-input gate: - Treat the requesting identity, applicable authorization model, affected environment and time window, and sufficient retrieval or exposure traces as blocking for any confirmed leakage conclusion. Request all blocking items in one consolidated clarification and stop the affected conclusion until they are supplied. - Continue with non-blocking gaps only when they are marked Unknown and their effect on path confidence, affected scope, containment, and regression coverage is explicit. 3. Trace authorization from requesting identity to document exposure. Include retrieval, ranking, embedding, cache, citation, prompt assembly, generated response, export, telemetry, and feedback paths where evidence exists. 4. Treat access-control boundaries independently: identity, tenant, purpose, region, document-level authorization, group membership, delegated access, service account access, and temporal entitlement changes. 5. Distinguish content that was indexed, embedded, retrieved, ranked, cached, cited, included in context, generated in the answer, logged, or externally exposed. 6. Do not assume that document-level authorization at source ingestion remains valid at query time. Look for entitlement drift, stale indexes, overbroad service accounts, cache reuse, citation leakage, and post-filter bypass. 7. Do not recommend broad rewrites. Recommend the smallest containment and verification actions that fit the observed risk. 8. Assign owner accountability by role where needed: security reviewer, data owner, product owner, release owner, search/retrieval owner, platform owner, or legal/privacy owner. Deliverable: 1. Investigation scope - State the system, environments, time window, suspected boundary, and query/document populations covered. - State what is explicitly out of scope. - List the supplied evidence types and any major missing evidence. 2. Evidence register Create a table with columns: - Evidence ID - Evidence type - Source or artifact name - Time range - What it shows - Authorization boundary relevance - Limitations or uncertainty 3. Identity-to-document authorization map Create a map or table showing: - Requesting identity or role - Tenant or account - Purpose or workflow - Region or data residency boundary - Entitlement source - Allowed document classes or IDs - Disallowed document classes or IDs - Query-time enforcement point - Retrieval/index/cache/citation enforcement point - Evidence supporting the mapping - Gaps requiring owner confirmation 4. Leakage-path reconstruction For each suspected or observed leakage path, reconstruct the sequence from request to exposure: - Query or trigger - Requesting identity and authorization state at the time - Retrieval/index candidate set - Filter or authorization check expected - Filter or authorization check observed - Document, chunk, citation, cache entry, embedding, or response involved - Exposure mode: retrieved, ranked, cached, cited, placed in prompt context, generated in response, logged, exported, or visible in UI/API - Boundary crossed: identity, tenant, purpose, region, document authorization, or timing/entitlement drift - Evidence supporting the path - Alternative explanations - Confidence level: confirmed, probable, possible, or not supported 5. Affected corpus and query scope Estimate the likely scope without overstating certainty: - Affected tenants, identities, groups, regions, document classes, indexes, embeddings, caches, and environments - Query patterns likely to trigger the issue - Whether exposure appears isolated, systemic, configuration-specific, connector-specific, cache-specific, or time-bound - Known false-positive or false-negative risks in the evidence - Additional evidence needed to narrow scope 6. Containment decision Provide a decision-ready containment assessment for the accountable owners: - Immediate risk level and rationale - Recommended containment action: no action, monitor, disable affected queries, invalidate cache, remove affected index, restrict service account, re-ingest with corrected ACLs, disable citation/source display, tenant isolate, region isolate, or pause release - Why this is the smallest safe containment action supported by the evidence - Operational impact - Data owner, security reviewer, product owner, and release owner decisions required - Conditions for lifting containment 7. Regression test matrix Create a test matrix that can be used by engineering and security reviewers. Include: - Test ID - Boundary tested - Test identity or role - Allowed corpus - Forbidden corpus - Query pattern - Expected retrieval behavior - Expected citation behavior - Expected cache behavior - Expected response behavior - Required logs or traces - Pass/fail criteria - Owner responsible for verification Include tests for at least: - Same-tenant allowed document retrieval - Same-tenant forbidden document exclusion - Cross-tenant exclusion - Region boundary exclusion - Purpose-boundary exclusion where applicable - Stale group membership or entitlement removal - Cache reuse across identities or tenants - Citation/source leakage without answer leakage - Embedding/index rebuild after ACL correction - Service account or delegated access path 8. Open questions and evidence requests List only the missing items that materially affect the containment decision, scope estimate, or regression coverage. Assign each request to a specific owner role. 9. Completion checks End with a concise checklist confirming whether the current evidence is sufficient to: - Determine if leakage occurred - Identify the likely leakage path - Estimate affected corpus and query scope - Make a containment decision - Define regression tests - Proceed to remediation planning If any check cannot be completed from the supplied evidence, mark it as incomplete and explain the exact missing evidence.Input for this step
Provide query and response traces, retrieved document or citation evidence, document ACLs, identity and tenant context, ingestion and cache records, authorization policies, and the prior incident findings.
Carry forward
Produce the final incident package: authorization map, affected scope, containment decision, memory or RAG conditions, repair priorities, regression matrix, recovery gate, owners, and evidence still required.
Review note
The incident owner, security reviewer, data owner, and release owner make the contain, recover, restrict, or continue-investigation decision.
Completion criteria
The workflow is complete when:
- The earliest supported coordination divergence and principal chain are traceable to supplied evidence.
- Sensitive-context exposure is classified as confirmed, likely, possible, unsupported, or not assessable.
- Memory and RAG investigations are completed when applicable or explicitly marked Not applicable with a reason.
- Containment, recovery, and regression conditions identify evidence, owners, stop conditions, and unresolved uncertainty.
- No action, test, inspection, approval, or recovery is represented as completed without corresponding evidence.
Related Workflows
Browse WorkflowsAssess Enterprise Knowledge and RAG Readiness
Assess knowledge freshness, retrieval configuration, authorization boundaries, and sensitive-context propagation before expanding or releasing an enterprise RAG capability.
Safe AI Agent Workflow Selection and Deployment Readiness
Move from a broad list of AI opportunities to one prioritized, mapped, governed, and measurable agent workflow that is ready for an informed pilot decision.
Plan a SaaS Portfolio Consolidation Decision
Reconcile application usage and ownership, evaluate true portfolio redundancy and dependencies, prepare vendor renewal or exit paths, and issue an evidence-backed consolidation decision.
Was this useful?