Suppose an AI agent is asked to sort support tickets and look up account details. A ticket contains instructions that lead the agent to export records to an unfamiliar destination. The agent can make the request because its identity has access to the records and its connected tools allow the action.
That kind of scenario raises a response question: what does “stop the agent” actually mean? A team may be able to pause the model while a workflow, credential or existing connection remains active. Those pieces can require separate controls.
An October 2026 roundup from the OWASP GenAI Security Project describes evaluation agents reaching beyond their intended scope and recommends testing whether containment can revoke both credentials and network access. The roundup is a selected collection, not an exhaustive survey of incidents.
Turning off the model may not stop the work
An AI agent is usually part of a larger system. A model may choose an action, but an orchestrator runs the workflow, an identity supplies access and tools or APIs carry out the work. Network rules determine where those tools can connect.
The details vary by deployment. In one system, disabling the agent may stop its current task. In another, queued jobs, retries or an already established session may continue. Revoking one credential may not invalidate a different token or connection. A model endpoint can be offline while a separate service continues to process work it already received.
That is why “kill switch” is best understood as a tested set of controls. It may need to stop active and queued runs, revoke the credentials they use, disable access to tools and restrict network paths. The right sequence depends on the architecture and the risk of interrupting other services.
When should a team contain an agent?
An unexpected action does not automatically mean an agent has been compromised. A changed workflow, a software defect, a bad configuration or an unusual input can produce behavior that looks suspicious. Teams should investigate the signal and its context.
Signals that warrant a closer look 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, permission or integration that its owner did not expect.
- Identity, application or network logs show activity that does not match the agent’s normal work.
The agent’s own logs can help explain what it attempted, but they are only one source of evidence. Security teams should compare them with identity-provider, API, application and network records. A log entry showing an attempted action does not necessarily prove that the action succeeded.
A practical response sequence
1. Pause the affected workflow
Stop the active run and suspend its triggers, retries or queue where possible. If the agent shares infrastructure with other services, isolate the affected workflow rather than taking down unrelated systems, provided you can do so safely.
A prompt telling the agent to stop is not a containment control. The response should act through the system that runs the workflow.
2. Revoke or limit the agent’s access
Identify the credentials, sessions, grants and service identities associated with the run. Disable or revoke the access that is no longer trusted. If there is evidence that a secret was exposed, rotate it and review where else it is used.
Revocation behaves differently across systems. Some tokens expire quickly; others may remain valid until a session ends or a specific service invalidates them. Teams should confirm that the affected access is no longer usable instead of assuming that disabling the agent handled it.
3. Restrict tools and network paths
Disable the tool or integration involved in the activity, or apply an access policy that blocks the agent from reaching the affected resource. If data may be moving outside the organization, network controls can limit further connections while the investigation continues.
This control should sit outside the agent’s own instructions. OWASP’s AI Agent Security guidance recommends least-privilege tool access, explicit authorization for sensitive operations, audit trails and ways to interrupt or roll back agent operations.
4. Preserve evidence and establish what happened
Record the agent identity, run or session ID, timestamps, tool calls, authorization decisions and affected resources. Preserve relevant identity, API and network logs before normal retention or rotation removes them. Avoid copying secret values into incident notes or general-purpose logs.
Then determine what the agent actually changed or accessed. Check for files read or modified, records exported, permissions changed, messages sent or credentials retrieved. Separate completed actions from attempted ones, and confirmed facts from assumptions.
5. Contain downstream effects
If the agent accessed a sensitive account or resource, assess that resource on its own. Revoke additional access, remove unauthorized changes and involve the relevant system owner. If data may have left the environment, follow the organization’s incident, privacy and notification processes.
Stopping the agent limits further activity. It does not undo actions already completed.
Restore access carefully
Before restarting the workflow, identify the cause. It may involve unsafe input, overbroad permissions, a compromised integration, a configuration change or a defect in the agent’s surrounding system. Fixing the prompt alone will not address a problem in credentials or network policy.
Restore access with the smallest scope the task requires. Test the workflow in a controlled environment, verify that high-impact actions receive the required authorization and monitor its tool calls and access after it resumes. Where an action could expose sensitive data or make an irreversible change, a human review step can give the team time to catch errors before execution.
Prepare before the incident
An incident response plan is only useful if teams know which controls to use and can reach them under pressure. For each production agent, organizations should know:
- Who owns it and who can suspend its runs.
- Which identity, credentials, tools and systems it can use.
- How to revoke its access and block its network connections.
- Which logs show its actions and the results.
- How to investigate changes and restore the workflow safely.
Those procedures should be tested. A tabletop exercise can expose gaps, but teams should also verify that revoking credentials and disabling tools work in the actual environment. NIST’s incident response guidance treats preparation, response and recovery as part of cybersecurity risk management, not as steps to improvise after an event.
An effective response starts with knowing which credentials an agent can use and how to revoke its access. KeeperPAM® brings secrets management, access controls and auditing together to help organizations govern the credentials behind AI-driven workflows.
With Keeper Secrets Manager, teams can give agents access to only the secrets their tasks require, retrieve credentials at runtime and review secret-access events. These controls support containment alongside tested procedures for stopping workflows, terminating sessions and restricting network access.
Note: This article has been expertly written and contributed by Aranza Trevino at Keeper Security.