CrowdStrike puts an allow-or-block decision inside Copilot Studio, before the tool runs

CrowdStrike has extended Falcon AIDR to Microsoft Copilot Studio, registering as an external threat detection provider that checks a tool call's name and input parameters against organizational policy and returns an allow or block decision inside Copilot Studio's response window, before the agent executes the call ^[1][2][3]. That matters because of where the decision sits: by CrowdStrike's own framing, endpoint, network, and data loss prevention controls cannot see the prompt or the tool call in the first place ^[6].

Strip the framing and this is a synchronous authorization callback, the same shape as admission control in a cluster or a policy decision point in front of an API. The agent proposes an action; something outside the agent votes on it; the vote is binding. CrowdStrike's stated payoff is that a manipulated conversation pushing an agent toward a forbidden tool gets stopped before execution, with each check landing on the Falcon AIDR Findings page for correlation in Falcon Next-Gen SIEM ^[4][5].

Two things follow from the design as described. First, the policy is evaluated on the request, not the result: tool name and input parameters ^[3]. That catches an agent being steered toward a tool it should not touch, which is exactly the exposure CrowdStrike names when it points out that an agent can be prompted to call a tool that hands back something it should not ^[13]. It does not, on this description, inspect what the tool returns. Second, an inline blocking decision inside a response window is a latency budget and a failure mode, and the announcement does not publish either, nor does it state whether the check fails open or closed, or give availability and licensing detail ^[14].

The Claude Code half is built on the same principle with a weaker anchor. Falcon AIDR hooks into Claude Code's own hook event system to check and block prompts and tool activity as they happen, with setup consisting of a block of JSON in the Claude Code settings file, no agent to install, nothing added to the build, and coexistence with hooks a team already runs ^[7][8]. CrowdStrike says a prompt carrying a secret or PII is caught before Claude sees it, and events tie back to a specific Claude Code session and user in Next-Gen SIEM ^[9]. Low friction is the selling point, and it is also the caveat: a control that lives in a settings file on a developer's machine sits on the wrong side of a trust boundary, and the post says nothing about integrity enforcement for that file.

The browser extension release is the least novel and probably the most immediately useful: AIDR capability is now in the Falcon browser extension, managed from the Falcon console with policy assignment aligned to existing host groups, and detections carry host and user context because activity is tied to Falcon sensor endpoint data, so they correlate with EDR, identity, and network telemetry from the same machine ^[10][11]. Three announced integration points, three different places the enforcement decision lives, one telemetry sink ^[15].

CrowdStrike's own rollout advice is to watch and report first, then turn on blocking and data transformation once the risk is identified ^[12]. That ordering is honest about what teams do not yet know about their own agent traffic.

What to watch: whether blocked tool calls produce a clean signal to the agent's builder or just a broken conversation, what the provider does when it times out, and whether the Claude Code hook can be made tamper-evident rather than merely present.