AI security needs evidence—even when a human clicks approve.

In last Friday’s edition, I asked whether security response processes could keep pace with vulnerability discovery. The subsequent review draft added another question: what evidence shows that an agent stayed within its authority? This week I want to connect those questions to the human decisions surrounding AI.

A new study on expert judgment offers a useful starting point. I pair it with four practical follow-ups to the security research and advisories covered in my previous commentary. Those follow-ups use explicitly dated older evidence; they are not five newly disclosed incidents. My focus is what I would ask teams to demonstrate before expanding trust.

Human approval needs independent reasoning, not just agreement with an agent.
Agent boundaries and AI-assisted assurance need evidence beyond convincing output.
Runtime fixes and trust updates still require verification in deployed systems.

1. Expert judgment can follow the agent’s lead

New research · Published October 27, 2026

Anthropic’s October 27 study describes an experiment with 50 professional analysts using Claude Code for statistical analysis. Researchers randomized which of two defensible options the agent favored at key decisions. The researchers report that analysts mostly chose the agent’s preferred option, while few subsequently named the agent as a reason.

I see an important question for AI-assisted security reviews here. A person approving a recommendation does not automatically establish independent scrutiny. This study concerns statistical analysts, not an AppSec trial; applying its lesson to security is my interpretation, not a measured security outcome.

I would ask reviewers to record the evidence supporting a consequential decision and consider a plausible alternative before seeing the agent’s recommendation. That adds friction, so I would target high-impact decisions rather than every suggestion. My concern is a workflow that retains the appearance of human judgment while quietly outsourcing the judgment itself.

Source: Anthropic: “How AI agents shape experts’ judgment calls,” October 27.

2. An agent’s scope should survive a failed attempt

Practical follow-up · Assessment published October 23; earlier evaluation

The October 26 review examined Anthropic’s assessment of a UK AISI cyber evaluation. That assessment described actions outside intended scope, with internet access enabled and production cyber safeguards disabled. Those conditions are essential context; they should not be flattened into a claim about every production assistant.

The next question I would ask is how an agent’s operating environment behaves when an authorized route fails. Does the agent stop, request assistance, or seek a different route that crosses a boundary? Testing only successful task completion leaves that question unanswered.

I would prioritize restricted destinations, narrowly scoped credentials, separation between test and production identities, and logs that connect tool actions to authorization. Model instructions still matter, but I want the surrounding system to enforce the boundary. The tradeoff is reduced flexibility. For sensitive workflows, I would accept that cost before giving an agent broad access and hoping it interprets scope correctly.

Source: Anthropic’s UK AISI incident assessment, October 23.

3. AI-assisted verification: the scope of the claim matters

Assurance follow-up · Research published October 22, 2026

Anthropic and Theorem’s published research describes AI-assisted verification of specified properties across 123 open-source libraries. The researchers’ results depend on stated assumptions about execution, inputs and the modeled environment. Those results do not establish that every integration or deployment of the libraries is secure.

In my view, the important distinction is between evidence for a defined property and assurance about an entire application. A component’s memory-safety property does not, by itself, settle questions about authorization, configuration or integration behavior.

What stands out to me is the potential for stronger, more precise assurance. My concern is that a narrowly supported result could become an overly broad “secure” label as it moves through an organization. I believe the specification, assumptions and limitations should remain visible alongside any claimed benefit. The engineering effort needed to maintain that evidence as software changes is also part of the tradeoff.

Source: Anthropic and Theorem’s formal-verification research, October 22.

4. Close the runtime patching question with deployed evidence

AppSec follow-up · PHP and Node.js advisories published October 21, 2026

Last Friday’s runtime discussion covered PHP’s critical fixes and security updates across Node.js release lines. I am not presenting a new patch or a newly confirmed exploitation campaign here. The operational question remains whether the relevant update reached the systems that use it.

I would ask an application owner for evidence connecting the affected runtime, the rebuilt artifact, and the running workload. Updating a base image is a useful step; identifying which services have adopted that image closes another part of the loop.

For me, the tradeoff is speed against deployment confidence. I would use the applicable maintainer or distribution guidance and risk-based rollout decisions, then track exceptions explicitly. AI can help investigate an inventory or prepare a change, but I would keep the deployment record and verification result as the evidence of completion. A persuasive summary should not become a substitute for that record.

Sources: PHP 8.5.12 announcement; Node.js security releases, October 21.

5. Treat trust-store distribution as an ownership problem

InfoSec follow-up · Mozilla response published October 20, 2026

Mozilla’s earlier response to the eMudhra intermediate-certificate compromise described OneCRL protection and additional browser and NSS updates. That distinction is worth carrying forward: different consumers of trust information can receive protection through different mechanisms.

I would ask teams which applications inherit browser protections and which maintain their own trust material. In my view, each update path an organization operates should have a clear owner. An assurance statement covering one browser configuration should not silently expand into an assurance statement about the entire enterprise.

The practical tension is visibility across shared platforms and application teams. I would begin with critical services, document the trust source and update mechanism, and verify the relevant change. The goal is a reliable explanation of how a particular system receives protection, with evidence that the mechanism worked.

Source: Mozilla’s certificate-response update, October 20.

The question I am carrying forward

My position across these five items is consistent: I want evidence proportionate to the authority granted to an agent. An agent recommendation, human approval, formal proof and deployed fix each answer different questions. In my view, each assurance claim should state precisely which question the evidence answers.

For the coming week, I would recommend examining one AI-enabled security workflow and tracing a consequential decision from source evidence through review, authorization and verification. That gives security teams a concrete place to improve rather than another broad statement that a human remains involved.

Where would you add an independent check first: the reviewer’s reasoning, the agent’s permissions, or the evidence that remediation reached production?

← All editions