CrowdStrike Plans to Acquire Fiddler: Even If AI Isn't Hacked, It Can Still Make Mistakes

A digital employee used a valid account to call an API permitted by the company, successfully completed the operation, but approved a refund that did not comply with the rules. Authentication was not compromised, nor was the network breached, yet the business outcome was still incorrect. CrowdStrike announced on November 3, 2026, its intention to acquire Fiddler, focusing precisely on this type of risk: in addition to protecting AI from attacks, enterprises must also ensure that AI is executing tasks correctly.

The acquisition plan brings together two types of capabilities

CrowdStrike stated that it plans to integrate Fiddler’s pre-deployment assessment and continuous behavior monitoring capabilities into the Falcon platform to create Falcon Observe. The company used the example of refunds for violations to illustrate that erroneous decisions made under legitimate permissions can also result in losses.Official Announcement from CrowdStrike

In a blog post published the same day, Krishna Gade, founder and CEO of Fiddler, confirmed that the company had signed a definitive acquisition agreement and emphasized the integration of development testing, production monitoring, and runtime policies. This disclosure pertains to the agreement and integration plans; it should not be interpreted to mean that the transaction has been completed or that the integrated product has been deployed in all customer environments.Announcement from the Founder of Fiddler

He had the authority, but only answered, “Can it be done?”

Traditional access control is effective at restricting what an account can read and modify, but it cannot, on its own, determine whether each business operation is valid.

Suppose a company allows customer service representatives to look up orders and process refunds within a certain limit. Even if a request does not exceed that limit, it may still involve orders that have already been refunded, payments made to the wrong recipient, or products that are outside the return period. After granting account permissions, the company must also incorporate business rules into the operational workflow.

This means that reliability must be evaluated separately in at least the following areas: whether the system was triggered by malicious input, whether it understood the user’s intent, whether the data used was appropriate, and whether the final output met business requirements. Focusing solely on the “API call success rate” can easily lead to mistaking the completion of an action for the completion of a task.

Truly useful records should be able to reconstruct a task.

For enterprise administrators, the most challenging situation after an error occurs is when they can only see the assistant’s “Completed” message, without being able to determine which version of the policy it referenced or which step caused the deviation.

A useful task log should link the original request, the data used, tool calls, approval records, and the final result. For sensitive information, fields should be redacted and access restricted; client data should not be copied into the log simply for the sake of ease of tracking.

“Explainable” does not mean that the model’s internal reasoning can be fully understood. Actual troubleshooting should rely on verifiable evidence: what the input was, what the call parameters were, what the system returned, and which business rules were triggered. A justification written by the assistant after the fact cannot, on its own, prove that the operation was correct at the time.

Small teams don't need to set up a complex platform right away.

For small teams that are in the process of introducing digital employees, they can start by breaking tasks down based on their outcomes.

For low-impact tasks, such as organizing data and generating draft reports, the focus should be on checking citations, completeness, and version control. For operations such as sending messages to clients or modifying business records, additional steps such as previews, field validation, or explicit approval should be implemented. High-impact actions—such as fund transfers, permission changes, and bulk deletions—require stricter authorization and manual review; they should not be approved solely based on the model’s self-assessment of “low risk.”

Then select a specific process for a minimal validation test. For example, initially have the customer service assistant generate refund recommendations only, without executing them directly; test it using scenarios such as normal orders, duplicate requests, missing information, and malicious comments. Record the situations in which errors occur, and then incorporate the validated checks into the system. Only after gathering sufficient evidence should you consider enabling partial automation.

Random spot checks should continue even after deployment. Rule changes, knowledge base updates, and model upgrades can all alter processes that were previously stable. When encountering failures, correct the source or business rules and incorporate regression testing to avoid declaring the issue resolved simply by changing a single prompt.

Platform integration offers convenience, but it also presents new challenges.

Combining behavior monitoring with identity, endpoint, and cloud logs is expected to shorten the troubleshooting process. However, when making a purchase, you should still verify the integration costs: Can existing agents provide the necessary logs? How are logs stored? Which sensitive fields will be transferred out of the original system? And can evidence be exported after the service is deactivated?

Another issue is false positives. A more sensitive monitoring system isn’t necessarily better suited for business operations. Frequent interruptions to normal tasks can reduce efficiency, while overlooking low-frequency, high-impact errors can have serious consequences. The appropriate threshold for a business must be determined based on actual workflows and risk tolerance, rather than simply copying the configuration from a demo.

Our assessment is that this proposed transaction sends a clear message: once digital employees begin performing tasks, companies need to manage both access permissions and business behavior simultaneously. More reliable automation should allow users to know what happened during a task, whether the results comply with the rules, and how to revoke permissions and correct the process in the event of an error.