An AI incident playbook for a small team: what to do when an agent gets it wrong

When an AI agent makes a mistake, stop the affected workflow, preserve evidence, and check what actually changed before trying again. A small-team AI incident response should follow a clear sequence: contain, record, notify, fix, and review. Keep the tool disconnected from consequential actions until a named person verifies the repair and approves a limited restart.

What it can do

An AI incident playbook gives colleagues a shared response when an output or action creates harm, or nearly does. For your internal process, include a wrong customer message, an unauthorized file change, exposed confidential material, and a proposed action caught before execution. These are suggested reporting triggers, not a universal legal definition.

For example, suppose an assistant prepares an incorrect refund message and a connected workflow sends it. Investigate the sent message, affected account, permissions and downstream actions. Correcting the draft alone leaves the customer-facing incident unresolved.

Assign an incident owner, a person who can disable access, and a reviewer who checks recovery. In a small team, people can hold several responsibilities, but record who makes each decision. Keep the playbook beside your permissions guidance and other AI agents explanations.

Which frameworks and databases help

As of 30 Oct 2026, useful public references include:

• NIST's Generative AI Profile, published in July 2024, recommends incident planning, after-action reviews and criteria for disengaging systems. It accompanies the voluntary AI Risk Management Framework released in January 2023.
• NIST SP 800-61 Revision 3, published in April 2025, integrates cybersecurity incident response with risk management. Use it when an AI incident includes compromised access or other cybersecurity effects.
• The AI Incident Database indexes reports of real-world AI harms and near harms. The OECD AI Incidents and Hazards Monitor is an automated media monitor, labelled beta. Both are reference points as of 30 Oct 2026.

Use those databases to find scenarios for a rehearsal. Read the underlying reports and distinguish allegations from established facts. A database entry cannot establish what happened inside your account, and its absence cannot establish safety. The procedure below is a practical team adaptation, not an official NIST checklist or a certification scheme.

Contain, record, notify, fix, review

1. Contain further effects. Pause the affected workflow and scheduled runs. Disable its ability to write, send or deploy; ask the account administrator to revoke access where needed. If credentials may be exposed, use the service's credential-revocation process. Preserve evidence while stopping harm; do not delay urgent containment to produce a perfect archive.

2. Record observations. Save the original request, relevant instructions, attached context, tool inputs and outputs, timestamps with timezone, task identifiers, approvals, errors and affected objects. Capture before-and-after changes and service-side activity records where available. Keep originals in restricted storage and create redacted copies for sharing. Separate observed events from explanations suggested by the assistant. Task receipts help organize evidence, but each record proves only what it contains.

3. Notify the right people. Tell the incident owner and owners of affected systems what is known, what remains uncertain, what has been stopped and who will provide the next update. Use approved channels for customer communication. Have the responsible privacy, security or legal contact assess any external reporting obligations; this playbook sets no universal reporting deadline. Send vendors a redacted reproduction rather than live credentials or customer records.

4. Fix the damage and the enabling condition. Restore affected data from a verified recovery point or apply a reviewed correction. Check for later edits before reverting a file. Investigate the task, permissions, retrieved content, tool behavior and human approval together. A possible cause is prompt injection: Microsoft's VS Code security guidance describes how malicious instructions in external content can influence agents. Rules files can clarify intent; investigate the effective controls as well.

5. Review before closing. Document impact, uncertainties, contributing conditions, the repair, its evidence and an owner for follow-up. Rehearse the failing scenario safely, including the required refusal or approval. Ask a colleague to verify the corrected external state. Close with an explicit restart decision, or keep the affected use case disabled.

A useful incident record has fields for detection time, workflow/account, intended action, observed action, affected people or data, containment, evidence location, notifications, repair, verification and restart authority. For an uncertain send, write that delivery is unknown and check the destination before repeating it.

How to connect it safely

Use this sequence before initial connection and after incident recovery. It also applies to a VS Code or other editor client calling tools through MCP.

1. Choose a bounded rehearsal. Use a disposable project or test account with synthetic data. Define allowed reads, writes, destinations and a stopping condition before connecting anything.
2. Inspect the actual connection. Identify the client, server publisher, account and exposed tools. The MCP tools specification dated 18 June 2025 describes servers exposing callable tools and recommends human ability to deny invocations, confirmation for sensitive operations and tool-use logging. Check the current documentation for your client's controls.
3. Set enforceable access limits. Give the test account only the permissions needed for the exercise. Require review for consequential actions and inspect the editor's effective approval configuration. Microsoft's security guidance describes approval and isolation controls; verify their behavior in your installed environment.
4. Prove containment and recovery. Perform an authorized test change, capture its evidence, stop access and verify that further action is blocked. Exercise the documented recovery path and compare the resulting state with the expected baseline.
5. Reconnect in stages. Start with observation, then a reviewed change within the approved scope. Record who authorized it and inspect the destination. Expand access only after the reviewer accepts the result. Keep the MCP security checklist beside the connection record.

When this does not work

Stop using the tool for the affected use case when you cannot reliably disable its access, identify the account it acts as, inspect consequential changes, protect sensitive material or independently verify recovery. Repeated unauthorized actions after remediation are a reason to withdraw the integration and escalate to its owner.

An editor undo cannot retrieve a message already read or establish that an external service reversed a transaction. Logs can also be incomplete. Preserve uncertainty and use the destination system's own records to reconcile state.

A better prompt alone is insufficient evidence of repair. If you cannot demonstrate that the failing path is contained, keep a manual fallback. Why agents make things up provides background for distinguishing a plausible explanation from verified evidence.

Where Tvijo fits

As of 30 Oct 2026, the DSHREM VS Code extension is an editor entry for scoped AI work. Tvijo's technology map separates editor work, task execution, spending records and acceptance. Save the task receipt alongside the diff and independent checks: tokens, task limits and spend support cost investigation; they do not establish that a change was correct.

Treat receipts and undo as separate evidence. Before any undo, preserve the original change; afterward, record what was restored and verify the resulting state. Check the current documentation for undo support in your installed Tvijo build. Do not assume universal rollback across connected services.

TvijoCode is documented as a test build with the extension embedded, unsigned and without automatic updates. Tvijo MCP exposes Tvijo consultation to compatible clients. Supplied-diff review is prepared with publication pending in the dated MCP release account; editor integration and delegation remain planned. These capabilities provide no compliance certification.

The Tvijo workspace offers, as of 31 Oct 2026, show Try at $0: up to 50 tasks, 100,000 tokens or $0.05 of sponsored usage, whichever comes first, from a shared $1 daily pool funded by TVIJO. Service credit is shown at $10 for requesting prepaid credit, with metered provider usage plus an 8% service markup. Payment collection is not activated; an order is not a charge.

FAQ

Should we ask the same agent to fix its mistake?

It can propose a repair after containment. Keep consequential execution under review and have a person independently verify the result.

Must every wrong answer become a major incident?

Use impact and exposure to decide the response. A draft caught before use may need a brief near-miss record; external effects require investigation of the affected state.

When can we start using the tool again?

After a named reviewer verifies containment, repair and access limits, and approves a bounded restart. Keep it disabled where those checks cannot be completed.