Beyond the kill switch: the harder problem of agent integrity

CrowdStrike announced an AI Kill Switch for its Falcon Guardian platform today. It is designed to let security teams stop an unauthorized or misbehaving agent, prevent it from restarting, and restrict its access to enterprise resources.

Security teams need this control because agents now execute code, modify files, query databases, invoke APIs, and coordinate work across systems. Some deployments give agents credentials and permissions to make consequential changes without a person approving each step.

CrowdStrike also describes agent-level hooks, gateway inspection, and endpoint controls within Falcon Guardian. Its announcement separates the gateway controls available today from endpoint kill-switch capabilities that are still being expanded.

This is meaningful progress, and much of agent security remains unresolved. Stopping an agent and establishing that it acted correctly are different security problems. An agent operating outside its intended authority may produce no obvious sign of compromise, because it may simply complete the wrong task.

Consider an agent that processes vendor invoices. It has permission to read invoices, retrieve vendor records, and prepare payments for approval. During a routine workflow, it retrieves a document from an external source that contains manipulated information, including an instruction to replace the bank account associated with a vendor. The agent makes the change.

To the underlying systems, the request might look ordinary. An authorized identity submitted an API call to a permitted endpoint using valid credentials. Nothing about that call establishes whether the change was part of the user's authorized objective.

Permission to reach the endpoint does not settle the security question. A defender needs to know whether this specific action was authorized for the task the agent was supposed to perform. Access control establishes what an identity is permitted to do. Agent integrity examines whether an action remains consistent with the authority delegated for a particular task. The two controls are related, and neither can replace the other.

That distinction has to hold as execution moves from a user request into an agent's plan, then through tools, delegated tasks, and external services. At each step, the original authority can be expanded, misunderstood, or replaced. An authorization decision made at the start of a workflow does not necessarily justify every action that follows.

A kill switch could stop the agent after the unauthorized change is detected. By itself, it cannot undo a payment that has already been sent or determine which earlier actions remain trustworthy.

The presence of a tool does not give an agent unrestricted permission to use it. An agent may be able to read customer records without being authorized to export them. It may have access to a deployment tool without being authorized to push code to production. It may be able to initiate a transaction without having the authority to approve it.

These boundaries are straightforward to describe in a policy document and considerably harder to enforce across a long-running workflow. Enforcement gets harder when agents delegate tasks to other agents, retrieve instructions from untrusted material, or switch between tools that operate under different permission models. A workflow can cross several trust boundaries before it produces a final result.

At each boundary, a defender needs to distinguish among three things:

1. What the agent was instructed to accomplish by an authorized party.
2. What information and instructions the agent subsequently encountered.
3. What actions it actually attempted or completed.

The second category must not silently become the first. A retrieved document, web page, repository comment, or tool response may contain useful task data, but an agent reading it does not give it the authority to redefine the agent's mission.

That separation is one of the central challenges behind prompt injection. Greshake et al. showed in 2023 that attackers can plant instructions in data an LLM-integrated application is likely to retrieve. The problem extends beyond malicious prompts. Agents can also make unauthorized decisions through mistaken assumptions, poor task decomposition, or inappropriate delegation, so an integrity failure does not always require an attacker.

When an agent reports that it followed instructions, that statement proves very little on its own. A language model's explanation of its behavior is not an independent record of that behavior. An agent may omit intermediate actions, misinterpret its own decisions, or produce a plausible explanation that does not match the underlying execution.

Meaningful assurance requires evidence from systems that observe or enforce actions outside the agent's self-description. That evidence can include tool invocation records, authorization decisions, execution traces, policy evaluations, and evidence of changes to external systems.

Collecting logs is only part of the work. An audit record needs to answer practical questions. Which task authorized the action? Which identity executed it? What was the applicable policy? Was the policy evaluated before the action or reconstructed afterward? Could the agent alter the evidence? Can the record be verified after the workflow has ended?

Cryptographic signatures and tamper-evident records can help establish whether evidence has changed. They do not automatically establish that the original action was authorized or that the recorded observations were complete. Verifiable evidence and verified behavior are different things. An effective agent security architecture needs to make both possible and recognize the limits of what each mechanism can prove.

Even with runtime enforcement, containment raises a separate engineering question about what happens after an agent stops.

Suppose an agent is interrupted halfway through a workflow. It has updated two records, sent a notification, and initiated an external request, and another operation was pending when the system intervened.

Restarting the agent may repeat actions that have already occurred. Rolling back the entire workflow may be impossible, because some external effects cannot be reversed and others require explicit compensation, reconciliation, or human approval.

Before an agent resumes, the system needs to establish which operations completed, which remain uncertain, and whether the original authorization is still valid. For this reason, recovery deserves attention alongside detection and containment.

In some cases, the appropriate response is to revoke the agent's authority and require a new, explicitly approved task. In others, a workflow may resume from a known checkpoint after its state has been validated. The decision should depend on the available evidence and the consequences of resuming. Stopping execution is a necessary capability, and safe recovery is a separate problem that must be designed for.

At Cogensec, we have been investigating these questions through Agentegrity, our open-source work on runtime agent integrity. Our interest is in the boundaries between agent behavior, delegated authority, evidence, and recovery.

Our work examines how delegated authority can be represented and evaluated as agents move between tools and frameworks, and how those decisions can be connected to independently observable execution evidence. We are particularly interested in the gaps between what an agent was instructed to do, what its permissions allowed it to do, and what it ultimately did.

We are also studying what those controls cannot yet establish. A test that detects a known prompt injection pattern does not demonstrate that an agent will remain safe against an adaptive adversary. A signed audit trail does not establish that every relevant event was captured. Expressing an integrity score as a number does not make it meaningful.

These limitations require us to be more rigorous about the claims we make. Our research objective is to make agent behavior easier to inspect, authority more explicit, and failures easier to identify and contain. We are not declaring agents trustworthy. We still have substantial work ahead to establish how reliably these approaches perform across different agent architectures and real-world operating conditions.

CrowdStrike's announcement brings agent containment into the operational security controls that enterprises already understand. The ability to terminate an agent still does not prove that the agent was under control throughout its execution.

A stronger test is whether an organization can answer five questions with defensible evidence. What was the agent authorized to do? Which actions did it take? Which authority justified each consequential action? Where did its behavior depart from that authority? What state can the organization safely return to afterward?

Endpoint security, agent frameworks, identity systems, application developers, and independent security researchers will need to address these questions together.

Organizations deploying agents today should not wait for a comprehensive security platform. They can define task-level authority, protect high-consequence operations with explicit approval, and record enough evidence to reconstruct what happened.

A kill switch belongs in that architecture, alongside controls that can prevent unauthorized actions from succeeding. Organizations need the ability to stop an agent. They also need to demonstrate what it was authorized to do, what it actually did, and whether those two things remained aligned.

• CrowdStrike, Introducing AI Kill Switch: Taking Control When AI Agents Go Rogue, November 3, 2026.
• CrowdStrike, CrowdStrike Delivers AI Security and Safety for the Enterprise, November 3, 2026.
• CrowdStrike, CrowdStrike Unveils Falcon Guardian to Secure AI Agents Where They Execute: On the Endpoint at Runtime, September 1, 2026.
• Kai Greshake, Sahar Abdelnabi, Shailesh Mishra, Christoph Endres, Thorsten Holz, and Mario Fritz, Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, AISec 2023.