An AI agent asked to sort support tickets and retrieve account details may receive instructions embedded in a ticket that cause it to export records to an external destination. Because the agent’s identity already holds access rights and its tools permit the action, the request can succeed without triggering obvious alerts.
Turning off the model may not stop the work
An AI agent operates inside a larger system. The model selects an action, yet an orchestrator executes the workflow, an identity grants access, and tools or APIs perform the actual operations. Network rules further determine where connections are allowed. Disabling the model alone can leave queued jobs, retries or established sessions running. Revoking one credential does not automatically invalidate other tokens or connections. A model endpoint may be offline while a separate service continues processing work it already received.
Security teams therefore treat a “kill switch” as a tested combination of controls that can stop active and queued runs, revoke credentials, disable tools and restrict network paths. The correct sequence depends on the specific architecture and the risk of disrupting unrelated services.
When should a team contain an agent?
Unexpected behavior does not automatically indicate compromise. A changed workflow, software defect, misconfiguration or unusual input can produce suspicious activity. Signals that warrant investigation include:
- The agent calls a tool or accesses a resource outside its assigned task.
- It attempts an unusual volume of reads, writes or exports.
- A workflow continues after an operator believes it has been paused.
- The agent uses a credential or integration its owner did not expect.
- Identity, application or network logs show activity inconsistent with normal operations.
Teams must cross-reference the agent’s logs with identity-provider, API, application and network records to confirm whether actions succeeded.
A practical response sequence
1. Pause the affected workflow by stopping the active run and suspending triggers or queues. Isolate only the impacted workflow when possible.
2. Revoke or limit the agent’s access by identifying associated credentials and sessions, then disabling or rotating them. Confirm that revocation has taken effect rather than assuming the model is disabled.
3. Restrict tools and network paths by disabling the relevant integration or applying an access policy outside the agent’s own instructions. OWASP AI Agent Security guidance recommends least-privilege tool access, explicit authorization for sensitive operations and mechanisms to interrupt or roll back operations.
4. Preserve evidence including agent identity, run ID, timestamps, tool calls and affected resources before logs rotate.
5. Contain downstream effects by assessing any accessed sensitive accounts and following incident, privacy and notification procedures.
Restore access carefully
Before restarting the workflow, identify the root cause, which may involve unsafe input, overbroad permissions or a compromised integration. Fixing the prompt alone will not resolve credential or network issues. Restore access with minimal scope and test high-impact actions under human review when necessary.
Prepare before the incident
For each production agent, organizations should document ownership, usable identities and credentials, revocation procedures, relevant logs and safe restoration steps. These procedures must be tested in the actual environment. NIST incident response guidance treats preparation, response and recovery as integral parts of cybersecurity risk management.
KeeperPAM combines secrets management, access controls and auditing to help govern credentials used by AI-driven workflows. With Keeper Secrets Manager, teams can enforce least-privilege access, retrieve credentials at runtime and review access events to support containment actions.
