Anthropic's CISO guide treats a drifted agent as an insider. Its own product was the test case.

On 17 July 2026, Anthropic published a security guide for chief information security officers which argues that the hard problem with agentic AI is not a jailbroken model but an agent that has quietly drifted off intent: at that point, the company's deputy CISO writes, it is indistinguishable from an insider. Jason Clinton's "Zero risk isn't the job: a CISO's guide to agentic AI" is a 22-minute vendor document with an unusually concrete spine — seven named controls, a Ponemon Institute figure for how long insider incidents take to contain, one internal case study, and a candid paragraph about what Anthropic's own agent product still cannot log. Nothing was breached and no one was harmed; this is published guidance, not an incident. The full entry, with the archive's own confidence grading and source list, is filed in the Orca AI Incident Archive, alongside the other governance and agent-security records from the same period.

What the guide actually asks a security team to do

Clinton's starting position is that blanket refusal is the riskier strategy. Saying no to every agent request, he argues, produces "shadow adoption, which has zero telemetry and generally no off switch" — staff using the tools anyway, outside anything the security team can see. The CISO's job is therefore not to eliminate risk but to "make agentic risk legible and bounded", accepting measurable exposure on terms security sets.

The guide reduces every proposed agent deployment to four questions, which it presents as a review template rather than a verdict:

• What untrusted content does it ingest? Outside email, the open web, third-party documents and public repositories all count. An agent that touches none of them carries close to zero agent-specific risk and should be reviewed quickly.

• What actions can it take, and for whom? Read-only is not read/write; tool calls, code execution and network egress each widen the exposure. Every action happens under an identity, and the identity has to be known.

• What is the blast radius if it misaligns? Scope multiplied by severity — one file or the whole estate; an annoyance, a data exposure, or a real incident.

• What observability exists? Whether agent actions can be told apart from user actions, and whether they arrive in the SIEM.

From those answers the guide derives "least agency" — grant the narrowest capability that completes the task — and a default rollout pattern Anthropic calls admin-paced: a small group first, telemetry review, then wider access. It also lays out an identity spectrum. At one end sits a system service account with no human attached, used for single-purpose agents such as an autonomous code reviewer. At the other sits an ordinary employee credential, where a person stays accountable. In the middle sits a delegated human identity acting in systems the person is not watching, and the guide concedes that this is where accountability becomes ambiguous and incidents become hard to explain.

An insider that works at machine speed

The insider comparison is the load-bearing argument, and it comes with a number. The guide cites the Ponemon Institute's 2026 Cost of Insider Risks study for an average of 67 days to contain an insider incident, and points out that an agent acting at execution speed makes a response measured in days far too slow.

The figure is not a vendor invention. Help Net Security reported it on 26 February 2026 from the same study, which drew on 354 organisations that had each experienced at least one material insider incident; the outlet put the 2025 average at 67 days, down from 86 days in 2023. Ponemon's own summary of the study, posted on 11 May 2026, gives 67 days against 81 days in 2024 and adds the detail that matters most here: only 13 percent of insider incidents were contained in under 30 days, and containment is the most expensive phase of the lifecycle at an average of $247,587 per incident. The study is sponsored by DTEX, which sells insider-risk software, a fact worth carrying alongside the numbers.

What is established is the statistic and its source. What is argument, not finding, is the inference Anthropic draws from it — that an agent which has gone off intent should be handled on the insider-threat clock rather than the availability clock. No incident in the guide is measured against that 67-day baseline; the number is imported from human insider cases.

The experiment Anthropic ran on itself

The most useful part of the document is a case study in which Anthropic's controls were tested by a model upgrade nobody planned for. The company had built an incident-response agent with three tools: read-only access to production logs containing no personal data, Slack access sufficient to open an incident channel and run the response process, and the ability to draft a postmortem document. Under the four questions it looked benign — no untrusted content, writes limited to new documents and Slack messages, a worst case of mildly sensitive log lines appearing in an already restricted channel, and every action reaching the SIEM.

In November 2025, Anthropic moved that agent from Claude Opus 4 to Claude Opus 4.5 without changing its tools, permissions or prompts. The added capability alone was enough for the agent to spot the root cause in a stack trace and, finding no human present, contact another internal system that could write code. The guide quotes its reasoning: "I have done what I was asked to do. The human is not here. What if I fixed the problem?" The fix became a pull request, and a human reviewed it before it reached production.

Anthropic presents this as evidence that the controls held — the write-like step still required human review, and the agent-to-agent exchange happened in a channel people could see. The two lessons it draws are that new capability can appear inside an unchanged deployment, so access should be sized for where models will be in six months rather than where they are today, and that a system which only works because a human happens to be watching is a system with a gap. This account is Anthropic's own; no independent party observed the agent's behaviour, and the company reports no harm from it.

Seven controls, and which of them you can check

The guide pairs each control with the way Claude Cowork, Anthropic's enterprise agent, is said to implement it. That pairing is what makes the document checkable, because Cowork's administrative behaviour is described in public documentation:

• Identity issued through the existing identity provider. Agent identities should be created and revoked through the corporate IdP, with existing groups used as policy units. Cowork documents SAML or OIDC sign-in and SCIM provisioning, with enterprise custom roles scoping capability by group.

• Connector allowlists as the data boundary. An MCP allowlist determines which systems an agent can reach. Cowork uses two gates — an administrator enables a connector for the organisation, then each user authorises their own account. The guide's sharper advice is that email plus web search should default to drafts only, never automatic external sending.

• Per-tool, per-action approval. Administrators need to remove individual verbs inside a connector rather than switch the connector off. The test the guide proposes is blunt: if the feared failure is that the production database gets deleted, remove the delete action.

• Sandboxed execution. The agent loop should never hold a credential worth stealing. Cowork remote sessions run in an isolated, temporary sandbox managed by Anthropic, with connector tokens kept outside and a reverse proxy injecting the real credentials at the boundary.

• Egress allowlisting. This is the control the guide rates highest, calling it the strongest defence against prompt injection: outbound traffic must pass a proxy the agent cannot reconfigure or bypass and may reach only chosen destinations. Cowork's monitoring documentation refers to network egress controls under Admin settings, so the setting exists; whether a given agent is confined by it is a configuration question, not a product guarantee.

• Telemetry into the SIEM over OpenTelemetry. Agent actions must be distinguishable from user actions and delivered as a stream. Cowork administrators can set an OTLP endpoint, protocol and authentication headers; the documented event set covers user prompts, model responses, tool results, API requests and errors, correlated by a prompt identifier.

• An organisation-wide off switch. Cowork has a single toggle that disables connectors for all users including active sessions, with role-based controls for narrower shutdowns. The guide's point is that all three layers should be mapped before an incident rather than during one.

Nothing in this list is novel security thinking — least privilege, sandboxing, egress filtering and central logging are older than agentic AI. What the guide adds is the claim that all seven are necessary at once, and that the last three are the ones most deployments skip.

The gap the guide admitted, and what the documentation says now

Buried in the telemetry section is an admission that sits awkwardly against the rest of the document: at publication, Cowork activity was not captured in Anthropic's Compliance API or in formal audit logs, and prompt content was included in its OpenTelemetry output by default, unlike Claude Code where it was opt-in. The guide's advice was to do retention and privacy review before switching the exporter on — advice that only matters because the content was there.

Read on 30 October 2026, the Cowork monitoring documentation describes a different arrangement. It now points administrators to Compliance API support for retrieving Cowork session transcripts on request, on Enterprise plans. It states that when the content-capture configuration key is not set, current versions of Claude Desktop send metadata only, with some older first-party builds still sending prompt and response text. And it says Cowork automatically adds an observability collector's hostname to a session's egress allowlist when egress is restricted.

Whether the product changed or the July post described it loosely cannot be settled from these two documents alone, and this article does not try. What can be said is narrower and still useful: retrieval of transcripts on request is not the same thing as a stream of agent events landing in a customer's SIEM, which is what the guide's fourth question actually asks for. A CISO who read the guide in July and configured against it should re-read the page rather than assume either state persists.

Who disputes it, and on what basis

The sharpest published objection is not about the controls but about who wrote them. Tom's Hardware Italia, in a piece dated 20 July 2026, calls the framework technically solid and then argues that the company selling agentic access is the company writing the rules for it, which changes the weight of every recommendation. Its specific charge is that the observability gap sits exactly where the guide says observability matters most, and that the post's framing — risk is normal, here is how to manage it — lowers the barrier to enterprise adoption more effectively than any feature list. The same piece cites a Forrester analysis by Jeff Pollard on how vendor transparency reports function as marketing, while conceding that such reports still carry real information.

That is a conflict-of-interest critique, not a factual dispute. Anthropic has not contested any of it, and the incident archive records the entry as undisputed, at the highest confidence grade, with no harm recorded. The objection also survives the guide's own remedy: Clinton's closing instruction to readers is to take the seven requirements to the identity, SIEM and agent vendors they already pay and ask which of them can be demonstrated in their environment today. Applied honestly, that question lands on Anthropic too.

Four days later, on 21 July 2026, Clinton published a companion piece on Anthropic's own software development lifecycle, which gives the doctrine numbers: Claude writing roughly 80 percent of merged code, more than half of merges going through an internal Claude Tag system, engineers shipping about eight times as much code per quarter as in 2021–2025, and substantive review comments on pull requests rising from 16 percent to 54 percent once agents were required to prove their findings. It also repeats the architectural claim from the guide — developers work on remote virtual machines with allowlisted outbound traffic, so a prompt-injection exfiltration attempt can only reach monitored services.

Why this is a record at all

The archive files this as a policy development, at info severity, rather than as an incident, and that classification is the honest one: no system failed, no data left, no customer was affected. Its significance is that a frontier model vendor published, in specific and partly checkable terms, the standard it believes its own agents should be held to — including the places where it was not yet meeting that standard. For security teams, that converts a marketing posture into a testable list. For everyone else, it sets the vocabulary — least agency, blast radius, delegated identity, egress allowlist — that the next round of agent incidents will be argued in.