SecOps / Response
AI incident response: contain, investigate, report
A runbook for the incident your existing plan did not imagine: an agent acted outside its limits, a model leaked data, or an attacker used your AI as the way in.
Conventional response plans assume a compromised host, account or application. AI incidents add new cases: an agent that took an unauthorised action, a prompt injection that exfiltrated data, a poisoned knowledge source, a tool server that changed behaviour. The steps are familiar. The evidence and the levers are different, and they need to be ready before the incident.
The problem: nobody can say what the agent did
When an AI system is involved in an incident, the first hour usually goes to questions that should have answers on file. Which agent was it, and who owns it? What was it connected to? What did it read and what did it do? Was it manipulated or malfunctioning? What else could the same credential reach? Without runtime records, these are reconstructed from fragments, and the reconstruction is the slow part.
The second problem is the clock. Regulation sets reporting deadlines for significant incidents. Under NIS2, entities in scope submit an early warning within 24 hours of becoming aware, an incident notification within 72 hours and a final report within a month of the notification. DORA sets its own classification and staged reporting for financial entities. The EU AI Act adds a serious-incident reporting duty for providers of high-risk AI systems, with deadlines that depend on the type of incident. A team that cannot establish scope quickly cannot report accurately.
The third problem is containment. Revoking a person's access is routine. Pausing an agent that is part of three workflows, holds its own credentials and may be mid-task is not, unless the lever was designed in.
The runbook, and the platform support for each step
This is a working outline. Adapt owners, thresholds and communications to your own plan.
1. Detect and classify
A policy block, an anomaly, a user report or a SOC alert opens a case. Classify it: agent as cause, as target or as tool. The inventory identifies the agent, its owner, its Trust Profile and its connections within seconds.
2. Contain
Pause or revoke the agent, rotate the credential it held, and detach compromised tools or knowledge sources. The identity graph shows blast radius, so containment is scoped to what the agent could reach. Revocation is recorded.
3. Preserve evidence
Freeze the audit ledger for the agent and sessions involved: prompts as fingerprints by default, tool actions, policy decisions, file changes, model and version. Preserving before changing anything keeps the record usable.
4. Investigate
Establish the cause: injection, poisoning, misconfiguration or model error. Reconstruct the chain from input to action. An investigation agent can assemble the timeline for an analyst to verify.
5. Eradicate and recover
Remove the cause: tighten the permission, fix the tool, clean the knowledge source, change the policy. Restore at a lower autonomy level and raise it only as the record supports.
6. Report and learn
Prepare the regulatory notifications from the case record, and turn the incident into a new policy rule, an approval gate and a regression test.
Where it sits on the platform
One platform with several entry points. Each product below plays a defined part in this capability.
| Platform entry point | Role in this capability |
|---|---|
| Nexus | Inventory, identity graph and blast radius; in-flight blocking; the audit ledger that makes the timeline reconstructable. |
| SecOps Agents | Investigation and response preparation under human approval. In beta; see the product page. |
| Studio | Response workflows with approval gates between steps. |
| Connect | Ticketing, paging and communications connections. <supported incident and paging connectors - founder to fill> |
| Trust Fabric | Traceability from data to model to agent to decision to action to outcome. |
What an incident-response agent can and cannot do
A Trust Profile for an agent that assists the response team. Note what it cannot do: an agent assisting response must not be able to destroy evidence.
Incident Response Agent
Assembles the timeline, proposes containment and drafts notifications for the incident lead.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
Controlled autonomy during an incident
Incidents tempt teams to relax limits. The opposite is safer: contain at the level of the evidence you hold.
- L1 Assist
Timeline building and evidence collection. The incident lead decides everything.
- L2 Approve
Containment is prepared; the lead approves each step, which is the default for production agents.
- L3 Supervise
Pre-agreed containment, such as pausing the agent that tripped a policy, runs within limits and is reviewed.
- L4 Autonomous
Narrow automatic stops for clearly defined conditions, for example a spend or action cap breach.
- L5 Adaptive
Post-incident, response playbooks are tuned from the record under gated, versioned change.
The five-level model is described in full on the controlled autonomy page.
Frameworks the design is mapped to
Mappings of intent between controls and published risk lists. Not an assessment result.
| Framework | Entry | How the design addresses it |
|---|---|---|
| OWASP Top 10 for Agentic Applications (2026) | ASI08 Cascading Failures; ASI10 Rogue Agents | Kill switches, caps and inventory are the levers for stopping a runaway or unregistered agent. |
| OWASP Top 10 for LLM Applications (2025) | LLM06 Excessive Agency; LLM10 Unbounded Consumption | Action caps and budgets limit damage while the cause is found. |
| MITRE ATLAS | Technique labels on observed behaviour | Label what was observed with ATLAS techniques so the incident record is comparable with other cases. Confirm current IDs at atlas.mitre.org. |
EU angle: the reporting clock
Reporting duties depend on whether you are in scope and on the incident's classification. The below describes what Swfte records that can support your reports, not who must report.
| Instrument | Reference | Supports evidence for |
|---|---|---|
| NIS2 | Art. 23 incident reporting: early warning at 24 hours, notification at 72 hours, final report within one month of the notification | Supports evidence for each stage: timestamps of awareness, scope, indicators, impact and root cause drawn from the case record. |
| DORA | ICT-related incident management, classification and reporting of major incidents | Supports a classified, time-stamped incident record and the data for initial, intermediate and final reports for financial entities in scope. |
| EU AI Act | Art. 73 serious-incident reporting (providers of high-risk systems); Art. 26 deployer monitoring and log retention | Supports retained logs, which deployers of high-risk systems must keep for at least six months unless other law says otherwise, and the information needed to establish and report an incident. Which role and article applies to you is a legal question. |
| GDPR | Art. 33 personal data breach notification to the supervisory authority within 72 hours where feasible; Art. 32 | Supports determining whether personal data was involved and what was accessed. |
Swfte is built compliance-by-design. It provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Nothing on this page is legal advice. Swfte's own security attestations are listed on the trust page.
What this page does not claim
- This is a runbook outline, not legal advice. Whether and when you must report depends on your sector, size, role and the facts.
- Reporting deadlines are quoted from the instruments as we understand them and change by classification. Verify against the current text and your regulator's guidance.
- We state no response-time improvement, because none is published here.
- SecOps Agents is in beta; the product page carries current status.
- Nothing here claims that your use of the platform is compliant with any regulation. Swfte's own security attestations are listed on the trust page.
Frequently asked questions
What counts as an AI security incident?
Any event where an AI system is the cause, target or tool of harm: an agent acting outside its permissions, data disclosed through a model or retrieval path, a successful prompt injection, a poisoned knowledge source, a tampered tool server, or an attacker using your AI to move inside the environment.
How do you stop an agent mid-task?
Through a kill switch designed in advance: the agent is paused or its credential revoked at the runtime layer, and the action is recorded. Containment is scoped using the identity graph, so you know what else the credential could reach.
What evidence should we preserve first?
The audit ledger for the agent and the sessions involved: tool actions, policy decisions, file changes, model and version, and the inputs as fingerprints or content as your privacy tier allows. Preserve before you change configuration.
Does Swfte file regulatory reports?
No. It records the data your team needs and can draft text for a person to review. A named person submits and remains accountable.
Can an AI agent run the response itself?
Within limits. Preparation and evidence gathering can be highly automated; containment typically needs approval, and notifications and root-cause declarations stay with people.
The rest of SecOps
Nine pages cover both halves. Each has a different job.
AI for security operations
Security for AI
Frameworks and evidence
Back to the SecOps hub.
Build AI incident response with Swfte
Start with one agent and one policy, or talk to the team about your environment, your data and your regulators.