Third-Party AI Agent Incident Response: A DFIR Playbook
Your incident commander receives a vendor notice at 09:15: an AI agent that processes support cases for your company may have performed unauthorized actions. The agent can read customer records through an approved integration and create tickets in your workspace. Your team can see API activity, but the vendor holds the agent’s task history, tool-call records, and some of the identity logs. The notice does not yet say whether customer data was accessed, copied, or changed.
This is the central problem in third-party AI agent incident response. Your organization must contain access and protect evidence while another company controls part of the system needed to establish what happened. Treat the vendor’s notice as a trigger for an investigation, not as proof that every connected dataset was exposed. Equally, do not accept “no confirmed exfiltration” as a complete scope determination when the underlying records have not been preserved and reconciled.
This playbook gives CISOs, incident commanders, IT leaders, and legal and compliance stakeholders a decision sequence for the first response, evidence collection, vendor coordination, and recovery. It applies whether the suspected cause is a compromised vendor account, an abused agent identity, an unsafe tool interaction, or a vendor-side incident that has not yet been explained.
Third-Party AI Agent Incident Response: The First Decisions
Open an incident record as soon as the notice or internal signal is credible. Record what is known, what is alleged, the reporting source, the time received, the systems connected to the agent, and the person authorized to approve containment. Assign one incident commander and establish a direct technical and legal contact at the vendor. A shared communication channel can help, but preserve formal notices and decisions in your own incident record.
The immediate goal is to stop potentially harmful activity without losing the only evidence that could distinguish an unauthorized agent action from an ordinary workflow. Have the identity and application owners identify the integration, its effective permissions, active sessions, credential types, connected tools, and any emergency stop control. Capture available configuration and logs before making changes where feasible. If activity is ongoing or material harm is imminent, contain it promptly and document what could not be preserved first.
Containment may mean disabling the agent integration, revoking its delegated grant, blocking a specific tool or destination, suspending a vendor account, or moving the workflow to a manual queue. These actions have different business costs. Revoking one grant may interrupt support processing; disabling a shared integration could stop unrelated services. The incident commander should choose the narrowest action that reliably limits the suspected path, then confirm it took effect in the downstream system. A vendor dashboard showing “disabled” is not, by itself, proof that an already issued credential stopped working.
If your team cannot establish the access path, preserve the relevant logs, or determine whether sensitive data was affected, involve remote digital forensics and incident response early. Agree on the investigative scope, access permissions, evidence handling, and reporting audience before handing over production records. A penetration test can follow later; it does not replace an investigation into suspected activity.
Set four immediate decision owners: the incident commander for containment, a technical owner for identity and logs, a vendor manager for contractual coordination, and counsel or the designated privacy lead for notification analysis. Their work should run together. Waiting for the vendor’s root-cause report before preserving your own records can let short-lived logs expire.
Determine what the agent could reach, and what it actually did
Separate possible access from observed activity. The former sets the investigation boundary; the latter supports findings. Start with the permissions granted to the vendor application, agent identity, service account, or delegated user. Then identify the data stores, tenant spaces, APIs, mailboxes, repositories, ticket systems, and administrative functions that those permissions reached during the relevant period.
An agent may operate under more than one identity. A user can initiate a task, the vendor can run the agent under its own principal, a tool connector can exchange a credential, and the destination can record only a service account. The team needs a mapping from the human or business trigger through the agent session and each downstream action. If one link is unavailable, state the gap rather than filling it with an assumption.
Use the following distinction to keep the scope defensible:
| Question | Evidence to seek | Decision it supports |
|---|---|---|
| What authority did the agent have? | Integration grants, effective roles, tool permissions, tenant boundaries, and configuration history | Which systems and records must enter the initial scope |
| Who or what initiated each session? | User trigger, agent identity, session and correlation IDs, approval record, and timestamps | Whether the activity was requested, delegated, or unexplained |
| What did it access or change? | Destination audit logs, object IDs, API events, before-and-after records, and export events | Whether confidentiality, integrity, or availability may be affected |
| Did data leave an approved boundary? | Vendor processing and retention records, output destinations, downloads, egress telemetry, and subprocessors | What additional investigation and notification analysis are needed |
| Did containment work? | Revocation events, rejected follow-on requests, disabled-tool records, and monitoring results | When the organization can move from containment toward recovery |
Do not equate a successful API request with confirmed data theft. A read event can establish that a record was returned to the integration; further evidence is needed to establish where it was processed, retained, exported, or disclosed. Conversely, the absence of an export alert does not establish that no data crossed a boundary. State confidence and limitations for each finding.
Check token and session lifetime as part of this work. A revoked user account may leave an application grant or previously issued credential active, depending on the integration. The existing guide to SaaS token lifecycle and revocation explains the validation questions for that part of the scope. For regulated business workflows, the map must also cover approvals and changes to records, as illustrated by financial-services agent workflow controls.
Third-Party AI Agent Incident Response: Preserve Evidence Across the Vendor Boundary
Most organizations can export their own identity, application, cloud, and endpoint records. They may not be able to collect the vendor’s agent traces, prompts, retrieved content, tool-call arguments, model or policy version, safety decisions, support access, and retention settings. Send a written preservation request promptly. Specify the affected tenant and integration, the time range with a reasonable buffer, the categories of records needed, the applicable retention or deletion hold, and the secure transfer process. Ask the vendor to identify records it does not possess or cannot produce.
Preserve original records where practical and work from controlled copies. Record who collected each item, its source, collection time and timezone, method, transfer history, integrity information where available, and any transformation used for analysis. Restrict access to sensitive content, especially prompts or tool results containing customer information. A screenshot can help triage, but it should not be the sole record when a structured export or original audit event exists.
Build one timeline from both sides. Normalize timezones and note clock differences. Correlate the vendor’s task or trace ID with your API request ID, destination audit event, affected object, and any human approval. A final chat response or vendor summary cannot substitute for the underlying sequence. Where a link is missing, mark the interval “unresolved” and request the specific record that could close it.
Preservation should extend beyond the agent platform if a connected system may have been affected. For example, a tool action that changed network configuration requires the relevant device or management-plane evidence. The edge-device evidence preservation checklist addresses that separate class of artifact. Coordinate collections so that a routine rebuild, log rotation, or vendor support action does not erase a source before the incident team records it.
Hypothetical illustration: A customer-support vendor reports suspicious activity in one agent workspace. Your tenant logs show 43 customer-record reads and three ticket updates under the integration identity during a two-hour window. The vendor has not yet supplied the initiating task IDs or output-destination logs. The defensible interim finding is that those records were accessed by the integration and three tickets changed. It is too early to say the 43 records were exfiltrated, and equally too early to clear them. The team preserves both log sets, restricts the integration, examines the changed tickets for operational impact, and updates its scope when the missing vendor records arrive. This is an illustrative scenario, not a client case or an observed incident statistic.
Coordinate with the vendor without surrendering the investigation
The vendor should appoint an incident lead who can answer technical questions, preserve records, and coordinate its subprocessors. Request a written account of the discovery time, suspected start and end times, affected tenants, agent and tool identities, known actions, containment performed, evidence sources, gaps, and next update. Ask which conclusions are confirmed and which are preliminary. Seek a secure way to exchange artifacts and a schedule for updates even if the vendor cannot yet determine root cause.
Review the contract, data-processing terms, incident-notice provision, audit and cooperation rights, subprocessor terms, retention commitments, and any insurance requirements with counsel. These documents may govern what the vendor must provide and when; they do not replace technical validation. “Vendor liability” is a separate legal and commercial question from the incident commander’s need to stop activity and establish impact. Avoid treating a contractual allocation of responsibility as proof of where the data went.
A practical evidence request should identify both sides of every important action: originating user or trigger; agent and service identities; approval or policy decision; tool and destination; object accessed; result or state change; and retention or onward transfer. The article on AI agent accountability evidence for SOC 2 describes the records an organization should be able to reconstruct before an incident. During an incident, that same trace helps distinguish permitted automation from a breach or an unintended action.
Protect investigation independence. Retain your own copies of notices, exports, configurations, and decisions. Reconcile vendor assertions against your destination logs and ask for the basis of statements such as “no other customers affected” or “no data retained.” A vendor may have a sound explanation, but your organization still needs enough evidence to make its own risk, notification, and recovery decisions.
What leadership should decide
The incident commander should present decisions as choices with evidence and consequences, not as a single technical status update. Leadership needs to know what remains operational, what cannot yet be ruled out, what additional evidence is expected, and when the next decision will be revisited.
| Decision | Threshold or question | Owner and record |
|---|---|---|
| Containment level | Is harmful activity ongoing, and can a narrower control reliably stop it? | Incident commander and integration owner; record the action, time, and service impact |
| Investigation scope | Which tenants, datasets, systems, identities, and periods are reachable or observed? | DFIR lead; maintain a scope register with evidence and confidence |
| Vendor escalation | Are critical records unavailable, expiring, or controlled by a subprocessor? | Vendor manager and counsel; record requests, responses, and preservation commitments |
| External communication | What facts are established, what obligations may apply, and who approves each statement? | Legal/privacy lead and communications owner; retain the decision rationale |
| Service restoration | Has the affected path been understood, corrected, and independently validated? | Business owner and security lead; approve a monitored, limited restart |
Notification duties depend on the applicable law, contract, data type, and facts established. Involve qualified counsel early and track deadlines from the relevant trigger, rather than assuming the vendor’s notice starts or settles every obligation. If facts are incomplete, prepare an evidence-based interim position and a scheduled reassessment. Do not make an absolute “no impact” statement while material log gaps remain.
Resourcing follows the evidence boundary. An initial remote triage may need identity, application, cloud, vendor-management, and legal participants. A broader investigation may add endpoint or network forensics, customer-record review, and independent analysis of vendor artifacts. Ask the DFIR provider to define phases, deliverables, dependencies, and decision gates in the scope. Any estimate of hours or price before the connected systems, log availability, and vendor cooperation are known would be unreliable.
Recover, validate, and improve the control boundary
Recovery begins when the team can explain the suspected path well enough to reduce recurrence risk and test the corrective action. Replace or revoke affected credentials and grants; review effective permissions, tool access, approval conditions, and data destinations; correct configuration or workflow weaknesses; and examine related integrations for the same pattern. If the root cause remains uncertain, document compensating controls and monitoring before limited restoration.
Test the control that matters in the destination system. Can the agent still read an out-of-scope record, act after revocation, cross a tenant boundary, or complete a high-impact action without the required approval? Can responders connect a permitted action to its initiating identity, purpose, tool call, and result? A policy document or screenshot cannot establish that a live integration enforces these boundaries. A scoped AI penetration testing assessment can validate the corrected workflow after the forensic phase, subject to production safety and vendor authorization.
Map the work to established guidance without treating a framework label as an incident conclusion. NIST SP 800-61 Rev. 3 places incident response within wider risk management, while NIST SP 800-86 addresses the integration of forensic techniques into response. In the OWASP LLM Top 10 for 2025, LLM01:2025 Prompt Injection is relevant when untrusted content may have influenced the agent, and LLM06:2025 Excessive Agency is relevant when its tools, permissions, or autonomy exceeded the intended task. The OWASP Agentic Top 10 adds ASI03 Identity & Privilege Abuse and ASI07 Insecure Inter-Agent Communication for delegated identity and agent-to-agent paths. These categories guide hypotheses and control tests; none proves that a specific mechanism caused the incident.
For organizations preparing SOC 2 evidence, the AICPA’s Trust Services Criteria provide the control context for incident detection and response under CC7. Record the incident, investigation, decisions, remediation, and evidence of operating effectiveness according to the organization’s defined system and commitments. The voluntary NIST AI Risk Management Framework can also help assign governance, map the workflow, measure controls, and manage residual risk. Neither framework substitutes for the underlying facts or legal analysis.
Close the incident with a report that distinguishes established events, plausible hypotheses, excluded paths, and unresolved limitations. Include the chronology, affected systems and records, collection and custody record, containment and restoration decisions, vendor dependencies, business impact, and recommendations. Assign owners and verification dates to each corrective action. The remediation ownership plan offers a model for converting findings into accountable fixes and retest evidence.
Frequently asked questions
Should we disconnect every integration from the vendor immediately?
Choose based on the suspected path and the harm of continued access. A full disconnect may be appropriate for ongoing unauthorized activity, but it can interrupt unrelated operations and complicate evidence collection. Document the decision, preserve available records where feasible, and verify that the selected control actually blocks the affected access.
Can we investigate if the vendor will not provide prompts or full traces?
Yes, but the conclusion may be narrower. Preserve your identity, API, destination, and data-access records; request alternative vendor metadata such as task IDs, tool calls, timestamps, and output destinations; and document precisely which questions the missing records prevent you from answering.
Does a vendor notice automatically mean we have a reportable breach?
No. A notice initiates fact-finding and legal review. The applicable notification analysis depends on the affected data, jurisdiction, contractual commitments, and what the evidence establishes. Counsel should assess obligations and deadlines while the technical team continues to determine scope.
What if the agent acted with a valid delegated credential?
Validity of a credential does not establish that an action was authorized for its purpose. Compare the initiating request, approved scope, effective permissions, policy decision, and destination event. Preserve the grant and revocation history, then test whether the credential remains usable after containment.
How do we assess a vendor statement that no data was exfiltrated?
Ask what records support the statement and which transfer routes were examined. Reconcile vendor-side output and retention records with your destination logs, downloads, and other available telemetry. Report any blind spots and the confidence level of the conclusion.
When should we resume the agent?
Resume only after the incident commander and business owner accept a documented restoration plan: the harmful path is contained, essential evidence is preserved, permissions and credentials are reviewed, corrective controls are tested, and enhanced monitoring is in place. A limited restart may be safer than immediately restoring every tool and dataset.
Conclusion: make the shared boundary investigable
A vendor-operated AI agent can create a difficult evidence split: your systems show the downstream effects while the vendor holds the context for the agent’s decisions and tool use. Effective third-party AI agent incident response joins those records, limits ongoing access, preserves a defensible chain of custody, and keeps uncertainty visible until it can be resolved.
If an agent-related vendor notice or unexplained delegated action is already on your incident channel, start a remote DFIR triage with Pentest Testing Corp. Share the affected integration, the first known event time, what access remains active, and which records each party can preserve. That gives the response team a concrete starting scope while containment and evidence collection proceed.