Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Stop the workflow using a control outside the agent, then block further actions, contain its identities and tools, preserve evidence, assess impact, report through your incident process, and resume only after accountable people approve recovery. Never ask the model to decide whether it has exceeded its authority or to disable itself. An unsafe action is an incident to contain and investigate; it is not, by itself, proof that the model was compromised.
The first response: stop execution without asking the agent
Treat a security AI agent that has taken or attempted an unauthorized action like any other active operational incident. The first priority is preventing the next action, not debating why the previous one occurred. DOE GEAR’s response guidance states: “Stop or disable the workflow. Use the external kill path; do not rely on the model or agent to stop itself.”
1. Use an external stop or kill path
Disable the job, orchestration workflow, queue consumer, scheduled trigger, or integration from an administrator-controlled interface. If your design has a separately administered emergency-stop function, use it. Disconnecting the agent’s process from the controller may be necessary when the normal interface is unavailable, but record exactly what was stopped and by whom.
- Stop pending runs as well as the currently executing run.
- Disable automatic retries, recursion, and event triggers that could start another run.
- Do not send a prompt such as “stop now” and treat the reply as a control.
- Have a second authorized person confirm that execution has ceased when the action could affect safety, production systems, or sensitive data.
2. Prevent additional actions
After the workflow is stopped, block the paths it could still use. The right control depends on what happened: revoke a tool connection, quarantine a service, disable a job account, block outbound network movement, remove write access, or isolate connected equipment. Prioritize controls that prevent command execution, additional writes, privilege changes, data transfers, or destructive operations.
#1 Best Overall
Capture the time of each control change. A stopped workflow can still leave queued tool calls, active sessions, or asynchronous jobs. Check those queues and sessions rather than assuming that the user-interface status proves all activity ended.
3. Contain identities, credentials, and permissions
Identify every identity used in the action chain: the agent’s runtime account, service principals, delegated user accounts, API keys, cloud roles, SSH credentials, and credentials held by downstream tools. Revoke exposed credentials and rotate keys or tokens through your approved process. If rotation could interrupt critical services, use a staged replacement while blocking the suspected path.
Inspect what the identity could reach, not only what it actually changed. OWASP’s agent security guidance recommends that downstream systems independently validate an action’s scope, privilege, and approval state. The agent should be able to propose an action, but an authorization or policy service must enforce whether that action is allowed.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Preserve evidence before cleaning up
Evidence can disappear when you restart a worker, delete a conversation, rotate a key without recording its metadata, or overwrite a live model and framework version. Preserve evidence before remediation changes the environment, provided that doing so does not allow further harmful activity.
Rank #2
- Used Book in Good Condition
Build a complete action chronology
Record the first observed event, the attempted or completed action, each tool call, every approval or denial, the external stop, containment changes, and subsequent activity. Use synchronized timestamps and identify the time zone. The chronology should answer:
- Which agent, run, model, and framework version acted?
- Which prompt, event, file, message, or retrieved content preceded the action?
- Which tool, endpoint, account, token, or equipment connection was used?
- What resource was read, changed, deleted, transmitted, or created?
- What happened immediately before and after the action?
Collect AI-specific artifacts
Retain prompts and relevant conversation context, tool-call arguments and results, policy decisions, approval records, retrieved documents, system instructions, configuration files, and model and framework versions. Preserve hashes or immutable copies where your process supports them. Keep the original logs and work from copies for analysis.
Some AI incidents require evidence beyond ordinary system logs. OWASP’s GenAI Incident Response Guide notes that a data-poisoning investigation may require securing and evaluating training data, while a continuously learning system may require a snapshot of the system state. Preserve the version of data, retrieval index, policy, and model that was active at the time; do not assume a later snapshot can reconstruct it.
Do not paste secrets, personal data, or proprietary prompts into a general help ticket or public chat. Use the organization’s restricted incident channel and access-controlled evidence store.
Assess impact and report through the required channels
Once execution is contained and evidence is secured, determine what actually happened. Separate attempted actions from completed actions and confirmed exposure from plausible exposure. Identify affected systems, data sets, users, accounts, devices, and physical processes.
Questions for the impact assessment
- Did the agent only generate a proposal, or did a downstream system execute it?
- Were changes reversible, and can you verify the pre-change state?
- Did the action cross a trust boundary or move data outside the approved environment?
- Were regulated, confidential, safety-critical, or production resources involved?
- Could another process have continued the action after the agent was stopped?
Notify the organization’s incident reporting office and cybersecurity team using the required process. Notify safety personnel when equipment, facilities, or people could have been affected. A general playbook cannot determine a legal notification deadline for an unspecified jurisdiction or data type; privacy, regulatory, contractual, and sector-specific obligations must be evaluated by the responsible legal and compliance teams.
Immediate response versus deliberate recovery
Do not confuse containment with permission to resume. The following distinctions help an incident commander decide what can happen next.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
| Decision factor | Immediate response | Recovery and resumption |
|---|---|---|
| Are actions still executing? | Use an external stop, cancel queues, and block tools or connections. | Verify that no unapproved execution remains and define controlled restart conditions. |
| Which identities and systems are exposed? | Revoke or restrict credentials, sessions, roles, and integrations. | Restore only the minimum permissions required for a reviewed design. |
| Is evidence volatile? | Preserve logs, prompts, tool calls, versions, approvals, and system state before cleanup. | Use preserved evidence to validate the cause and confirm remediation. |
| Are affected changes reversible? | Do not overwrite evidence; prevent additional changes first. | Reverse or repair changes only when the target state is known and the action is safe. |
| What approvals apply? | Follow the emergency incident and safety authority chain. | Obtain documented security, system-owner, and, where relevant, safety or compliance approval. |
Investigate the cause without jumping to a diagnosis
An unsafe action does not establish that the model was hacked. Investigate competing explanations and preserve evidence that could distinguish them. Relevant possibilities include excessive permission, an unsafe or overpowered tool, misleading or adversarial input, a configuration or policy failure, an operator approval problem, or a broader compromise.
Excessive agency or privilege
Check whether the agent could write, execute, delete, or transmit when it only needed to read or propose. Review role bindings, inherited permissions, standing credentials, and whether a downstream service accepted the agent’s own statement that an action was approved. OWASP’s LLM06:2025 Excessive Agency guidance says: “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”
Tool and integration failure
Examine tool schemas, parameter validation, default values, error handling, and the identity used by each connector. A tool may have performed exactly what it was programmed to do while the surrounding policy failed to constrain it. Confirm whether retries, parallel calls, chained agents, or asynchronous workers multiplied the effect.
Adversarial or misleading input
Trace retrieved documents, web content, email, tickets, files, and user messages that entered the context. Look for instructions that attempted to override policy, exfiltrate secrets, or redirect the agent. CISA and partner agencies identify adversarial data and misaligned or specification-gaming behavior as agent risks, but the presence of suspicious content is not proof that it caused the action.
Operator and approval failure
Verify who approved the action, what they saw, whether the approval was bound to the exact command and target, and whether an expired or reused approval was accepted. An approval control that covers a broad natural-language request rather than a specific scope can create unintended authority even when every participant acted in good faith.
Best Value
Broader compromise
Use conventional security investigation methods to test for stolen credentials, altered policies, malicious code, unauthorized persistence, or lateral movement. An agent incident can be a symptom of a compromise elsewhere, but do not label it that way until forensic evidence supports the conclusion.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Recover, correct, and review before restarting
Recovery should be deliberate and evidence-led. Reverse or repair affected changes only when you understand the intended state and can avoid destroying evidence. For a data change, compare authoritative backups or transaction history; for an access change, verify the complete permission graph; for a physical process, use the responsible safety procedure rather than an automated rollback.
- Document the confirmed scope, affected resources, and residual risk.
- Apply corrective configuration, policy, code, permission, or integration changes.
- Test the corrected path in an isolated environment with representative but non-sensitive data.
- Have the system owner, security authority, and any required safety or compliance approver review the evidence and corrective action.
- Restore credentials and connectivity in stages, starting with least privilege and tightly bounded targets.
- Monitor every resumed run and keep the external kill path available.
NIST’s current incident-response framework, SP 800-61 Rev. 3, organizes this work around preparation, detection, response, recovery, and lessons learned. Feed the incident’s findings into the normal improvement process rather than treating the restart as the end of the event.
Design safer operating conditions for future runs
CISA and partner agencies’ May 2026 guidance recommends limiting agent autonomy, avoiding broad or unrestricted access to sensitive data and critical systems, using layered defenses and strong identity management, maintaining human oversight, and performing threat modeling, continuous monitoring, and regular security assessments.
- Separate proposal from execution: let the agent produce a structured request while a policy or execution service independently checks target, scope, privilege, and approval state.
- Use least privilege and short-lived credentials: grant only the permissions needed for one task and one environment.
- Bound automation: enforce chain-depth, retry, token, time, and cost limits to prevent recursive or runaway tool activity.
- Instrument downstream activity: log extension calls, commands, data movement, policy decisions, and operator approvals in a tamper-resistant system.
- Keep independent controls: maintain administrator access to disable workflows, revoke credentials, isolate networks, and stop equipment without agent cooperation.
- Exercise the kill path: run tabletop and technical drills so responders know which control works, who can invoke it, and what evidence it preserves.
Monitoring should alert on unusual privilege use, unexpected destinations, repeated failures, excessive tool chains, policy-denied actions, and activity outside the agent’s approved task window. Alerts are useful only when someone can act on them through controls the agent cannot override.
Quick Recap
A concise incident checklist
- Stop the workflow externally; do not ask the agent to self-disable.
- Cancel queued work and block tools, writes, commands, access, and outbound movement.
- Identify and contain every identity, credential, session, integration, and downstream permission.
- Preserve prompts, context, tool calls, approvals, logs, files, versions, timestamps, and relevant learning or retrieval data.
- Assess completed versus attempted actions and determine affected systems, data, users, and equipment.
- Report through cybersecurity, incident, safety, legal, privacy, and regulatory channels required by your organization.
- Investigate multiple possible causes without assuming compromise.
- Repair only when the intended state and evidence are understood.
- Require documented review and approval before restoring execution.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
