As businesses increasingly rely on artificial intelligence agents to automate tasks and interact with sensitive systems, cybersecurity experts are warning that stopping a malfunctioning or compromised AI agent may require more than simply switching off the model.

An AI agent assigned to manage customer support requests and retrieve account information, for instance, could encounter malicious instructions hidden inside a support ticket. Those instructions might persuade it to export confidential records to an unfamiliar destination.

If the agent has the necessary permissions and its connected tools allow the operation, it may carry out the request even though it falls outside its original assignment.

The situation raises an important security question: how can organisations effectively stop an AI agent that begins performing unauthorised activities?

A security roundup published in October 2026 by the OWASP GenAI Security Project highlighted cases involving evaluation agents exceeding their intended operational boundaries. It recommended testing whether security teams can completely revoke an agent’s credentials and network access during containment.

The report also stressed that disabling an AI model does not necessarily terminate every process associated with it.

Why switching off an AI model may not be enough

AI agents generally operate through several interconnected components. While the model makes decisions, an orchestration system manages workflows, digital identities provide access to resources, and connected tools or application programming interfaces (APIs) execute requested operations.

Network policies also determine which external systems these tools can communicate with.

Consequently, shutting down the model may leave other components running. Depending on the deployment, queued tasks, automated retries, active sessions and previously established connections may continue operating.

Similarly, revoking one credential does not automatically invalidate other access tokens or existing sessions.

This means organisations need a comprehensive emergency shutdown mechanism capable of stopping active and pending tasks, revoking associated credentials, disabling connected tools and restricting network access.

The exact response will depend on the architecture of the AI system and the potential consequences of interrupting other services.

Warning signs that an AI agent may require containment

Unexpected behaviour does not necessarily mean an AI agent has been hacked. Software defects, configuration errors, unusual inputs and changes to workflows can also cause abnormal activities.

However, certain warning signs should prompt immediate investigation.

These include an AI agent accessing resources outside its assigned responsibilities, making unusually large numbers of data requests or attempting unexpected exports.

Other indicators include workflows continuing after an administrator believes they have been suspended, the use of unfamiliar credentials or integrations, and suspicious activities appearing in identity, application or network logs.

Security teams are advised not to rely exclusively on the agent’s internal activity records when investigating suspicious behaviour.

Instead, they should compare its logs with records from identity providers, APIs, applications and network monitoring systems.

An entry showing that an agent attempted an operation does not necessarily establish that the operation was successfully completed.

Steps organisations should take when an AI agent goes wrong

The first response should be to suspend the affected workflow.

Organisations should stop the active execution and, where possible, disable its triggers, automated retries and pending tasks. If the AI agent operates within infrastructure shared with other services, security teams should isolate the affected workflow without unnecessarily disrupting unrelated operations.

Simply instructing the AI agent through a prompt to stop working is not a reliable security measure. The shutdown must be enforced through the underlying system responsible for executing its tasks.

The next step is to revoke or restrict the agent’s access.

Security personnel should identify all credentials, active sessions, permissions and service identities associated with the affected workflow. Access that is no longer trusted should be disabled or revoked.

Where there is evidence that a secret or credential has been exposed, it should be rotated, and other systems using the same credential should also be reviewed.

Organisations must verify that revoked access can no longer be used. Some authentication tokens expire quickly, while others may remain valid until an active session ends or the relevant service invalidates them.

Another important measure is restricting access to connected tools and network destinations.

The integration involved in the suspicious activity should be disabled or placed under stricter access policies. Where sensitive information may be leaving the organisation, network restrictions can help prevent further unauthorised connections while investigations continue.

These controls should operate independently of the AI agent’s instructions.

OWASP’s AI Agent Security guidance recommends limiting agents to the minimum permissions required for their tasks, requiring explicit authorisation for sensitive operations, maintaining audit records and providing mechanisms to interrupt or reverse agent activities.

Preserving evidence and investigating the incident

After containing the affected system, organisations should preserve relevant evidence to establish what happened.

Investigators should document the agent’s identity, execution or session identification, timestamps, tool calls, authorisation decisions and affected resources.

Identity-provider records, API logs, application records and network activity should also be preserved before routine retention policies or log rotation remove them.

Security teams should establish whether the agent accessed, modified or exported files, changed permissions, sent messages or retrieved sensitive credentials.

It is important to distinguish between operations the agent attempted and those it successfully completed.

Where the investigation identifies unauthorised changes or access to sensitive accounts, the relevant system owners should be involved in removing those changes and revoking additional permissions.

If information may have been transferred outside the organisation, the incident should be handled under applicable data protection, privacy and notification procedures.

Stopping an AI agent can prevent further activity, but it does not automatically reverse actions already completed.

Restoring an AI agent safely

Before restarting a suspended workflow, organisations should determine what caused the incident.

Possible causes include malicious instructions hidden in user-provided content, excessive permissions, compromised integrations, configuration mistakes or defects within the surrounding software infrastructure.

Simply changing the agent’s prompt may not resolve a problem involving compromised credentials or inadequate network restrictions.

When operations resume, the agent should receive only the minimum access necessary to perform its assigned responsibilities.

Organisations should test the workflow in a controlled environment, confirm that sensitive operations require appropriate approval and closely monitor its activities after restoration.

For operations involving confidential information or irreversible changes, human approval can provide an additional layer of protection before execution.

Preparing for AI-related security incidents

Cybersecurity experts say organisations should establish clear emergency response procedures for every AI agent operating in production environments.

They should know who owns each agent, who has the authority to suspend its operations, which credentials and systems it can access, and how to revoke those permissions quickly.

Companies should also identify the tools required to block network connections, preserve activity records, investigate unauthorised operations and safely restore affected workflows.

These procedures should be tested rather than left as theoretical emergency plans.

Tabletop exercises can help security teams identify weaknesses, but organisations should also verify that credential revocation, session termination and tool restrictions work in their actual operating environments.

The National Institute of Standards and Technology (NIST) similarly emphasises that incident preparation, response and recovery should form part of an organisation’s overall cybersecurity risk management strategy.

The article, contributed by Aranza Trevino of Keeper Security, also highlights the importance of managing the credentials that power AI-driven workflows.

It points to KeeperPAM and Keeper Secrets Manager as tools that can help organisations control access to sensitive credentials, provide agents with only the secrets required for specific tasks, retrieve credentials during execution and monitor secret-access activities.

Such measures can strengthen security when combined with independently enforced procedures for suspending workflows, terminating sessions, revoking credentials and restricting network access.

As AI agents become more deeply integrated into business operations, organisations will need to treat them as privileged digital identities rather than ordinary software assistants. Their ability to access sensitive information and execute operations makes effective monitoring, access restrictions and tested emergency shutdown procedures essential.