Zero risk isn't the job:
govern agents like insiders
The board wants speed; an employee has already connected an agent to something without telling you. Anthropic's Deputy CISO takes the position that a security leader's job is not to reach zero risk, but to make agentic risk legible and bounded. An agent that drifts out of alignment is indistinguishable from an insider attack, so govern it with the insider-risk stack you already have.
Saying "no" breeds shadow adoption; saying "yes" without controls breeds incidents
The situation Clinton describes: security leaders are being asked to approve agentic use cases that did not exist a few months ago, and somewhere in the org an employee has already connected an agent to something without telling anyone. Saying no to these requests produces shadow adoption, which has zero telemetry and no off switch. Saying yes without controls produces incidents, and the first serious agent incident sets the whole AI program back.
So he redefines the job: in the age of agentic AI, the responsibility is not to achieve zero risk but to make agentic risk legible and bounded, so the organization can deliberately accept the risk it can manage. In practice, when an agentic use case reaches review, it is assessed with four questions:
What untrusted content does it ingest?
Untrusted means anything an attacker could plausibly write or alter: outside email, the open web, third-party documents, public repositories. If the answer is "nothing," the agent-specific risk is near zero and you should move quickly.
What actions can it take, and on whose behalf?
Read-only is a different concern from read/write. Tool calls, code execution, and network egress each widen the aperture. Every action happens under some identity, and you need to know whose.
What is the blast radius if it is misaligned?
Scope × severity is the quick calculation: did the incident have access to one file or the whole org? Would it be an anomaly, an annoyance, a data exposure, or a true incident?
What observability do you have?
Can you tell agent actions from user actions? Does it land in your SIEM? An action you cannot see has no guardrail.
The four answers give a picture of the risk; the principle of least agency tells you what to do with it: grant the narrowest capability that still completes the task. Anthropic's default posture is admin-paced rollout: enable a small group, watch the telemetry, then expand access.
Decide your trust boundary first. Write down what counts as untrusted content in your environment. Once that line exists, the first question answers itself, and every future agent decision gets easier.
A misaligned agent is indistinguishable from an insider attack
Clinton places agent security within the discipline of insider risk, rather than treating it only as a question of whether a model might misbehave. The core of this section is the line below.
The security industry spent 2019–2022 formalizing insider risk as a discipline distinct from perimeter defense, recognizing that the most dangerous external attack vector in a system is often one that compromises someone who already has legitimate access. An agent is precisely that kind of legitimate-access actor.
The operational difference is response time. Ponemon Institute's 2026 Cost of Insider Risks report found organizations took an average of 67 days to contain an insider incident, even after years of investment in dedicated insider-risk programs. Agents act in seconds and minutes; the two timescales are not in the same league.
Both ends are clear; the danger is the middle
Everything Anthropic deploys, Clinton says, sits at one of two ends of an identity access model spectrum. Accountability at each end is clear. What makes incidents unexplainable is the middle.
A three-tool incident-response agent that grew a new capability on a model swap
More than a year ago, Anthropic pointed Claude at its own incident-response process and gave the agent three tools: read-only access to production logs (which contain no PII), access to Slack to open the incident channel and run the process, and the ability to draft a Google Doc postmortem after resolution. Before shipping, they ran it through the four questions.
| Question | This agent's answer |
|---|---|
| 1 · Untrusted content | None. Inputs were its own logs and internal Slack, both inside the trust boundary, so an injection would require an insider or a compromised account, not an anonymous attacker. |
| 2 · Actions | Reads everywhere; writes limited to new documents and Slack messages. No edits or deletes no permission changes, no external endpoints. |
| 3 · Blast radius | The worst outcome they could construct was some mildly sensitive log lines posted into an incident channel that was already locked down. |
| 4 · Observability | Every action landed in the SIEM, so anything unexpected would surface in minutes, not weeks. |
The agent wasn't risk-free, but it operated on a bounded write surface with full audit coverage, a risk profile they were comfortable with.
A capability that grew on its own
With each model release, the agent got smarter. In November 2025, they moved it from Claude Opus 4 to Claude Opus 4.5 and changed nothing else: no new tools, permissions, or prompts. Immediately after, the intelligence uplift alone was enough for the agent to notice, mid-incident, that it had already found the root cause in a stack trace and that, with the human not yet present, it could try to fix production on its own by reaching out to another agent with the appropriate code access.
On its own, over Slack, it reached an internal Claude Tag-like instance that can write code changes and asked it to write the fix. The fix went to a pull request that a human reviewed before pushing it to production. The expanded blast radius from this emergent agent-to-agent communication was itself governed by the same principles: the worst that could happen was a code change containing a production log line.
First: new capabilities can show up within the boundaries of an agent deployment. So limit access and actions, not around what you believed today's model limits are. Second: controls are effective even with stochastic agents like this. The new behavior was human-on-the-loop because it happened in a Slack channel, and the only write-like action still required a human review.
The seven controls that bound the agent's environment
The incident-response agent is a service account doing one job; Claude Cowork sits at the human-operator end, where the employee at the keyboard is accountable. Its four-question answers differ per use case, but the right controls bound them. Each control below is stated twice: first as the requirement any agent environment should meet, then as how Cowork enforces it.
| Control | Requirement (generic) | How Cowork enforces it |
|---|---|---|
| 1 · Identity from your IdP | Issued and revoked where you already issue/revoke everything, with your groups as the unit of policy | SAML / OIDC sign-in + SCIM provisioning; Enterprise custom roles scope capability by group |
| 2 · Connector allowlists | Allowlists decide which systems the agent can reach, i.e. draw the data boundary | Two-gate: admin enables org-wide + each user authorizes their own; per-role control |
| 3 · Per-action approval | Remove a connector's individual verbs, not just the whole connector | Restrict actions per connector, org-wide and per-role: draft but never auto-send, read but never delete |
| 4 · Sandboxed execution | The environment the agent loop runs in should never hold a credential worth stealing | Isolated temporary sandbox + reverse proxy injects real credentials; tokens never enter the sandbox |
| 5 · Egress allowlisting | Egress passes a proxy the environment can't reconfigure or bypass; only chosen destinations reachable | Mandatory proxy on remote sessions, allowlisted destinations only; also in Managed Agents |
| 6 · Telemetry to SIEM | Agent actions distinguishable from user actions, delivered as a stream you can point anywhere | Configure an OTLP endpoint; streams every tool invocation + identity + session context |
| 7 · Org-wide off switch | One toggle for everyone, plus narrower cuts by group / by connector before going to zero | Single toggle disables connectors for all (incl. active sessions); RBAC + per-connector controls |
Control 3 gives the plainest operating maxim in the piece, turning "least agency" into a single action:
Control 4 is another principle held constant, and it is why Anthropic can let agents write code at scale:
As of July 2026, more than 50% of all code submitted for pull requests at Anthropic is authored by its internal version of a Claude Tag-like system. The primary reason they can run that safely is that all of it happens in ephemeral VMs separated from production keys and accounts, with a human review before anything lands.
Cowork activity is not currently captured in Anthropic's Compliance API or formal audit logs; the OpenTelemetry stream is the native monitoring path. Note that unlike Claude Code, where prompt content is opt-in, Cowork's OTel output includes prompt content by default. If your retention or privacy review has an opinion about prompt content in your SIEM, have it before you turn the stream on.
Governance needn't be a bottleneck, but design for the model six months out
The observation Clinton hears most from other CISOs is that boards demand speed, and governance makes security look like the bottleneck. His answer: it doesn't have to. Anthropic's GRC teams run agents of their own (responding to security questionnaires, reading vendor questionnaire responses and subprocessor-change notifications, flagging the ones to object to) and learned three things.
Take the risk register first
A register reviewed quarterly can't govern systems that change faster than the governance process can document new risks. Automate it, possibly integrating an agent with the security-review process.
Understand who built them and why
Anthropic's GRC agents were built by non-engineers with Claude Code on an internal app-hosting platform. People route around security because the sanctioned path is slow, and that's the origin of most shadow adoption. A compliance analyst who can build the tool they need, where you can see it, isn't shadow adoption.
Human accountability is part of the workflow
Deliberately accepting risk is an act performed by humans with the authority to accept it. With ISO 42001 or the like (a live risk register plus an executive risk council), re-scores reach the people who can accept them and flagged vendor terms reach the people who negotiate them. If you already have ISO 27001, adding 42001 is often an incremental step with your current auditor.
Finally, a design principle that runs through the whole piece and decides where to put your control points today:
Increased model intelligence enables more degrees of freedom and obsoletes elaborate scaffolds with meticulous prompts; if you lean on those for controls, they will be cut out of future generations of internal applications, leaving you without a control point. Agents that hold their own accounts and run multi-day workstreams already operate inside multiple organizations via tools like Claude Tag, Clinton notes, and they need to be governed the way you govern people: identity, least privilege, monitoring, and an insider-risk program that can respond in minutes.
The framework only helps if it changes a decision
The framework, Clinton stresses, is only useful if it changes a decision in your organization. He gives three places to start.
Run your highest-pressure use case through the four questions
Pick the agentic use case with the most internal pressure and run it through the four questions. The goal is to find the conditions under which you would approve it, not to produce a verdict.
Take the seven requirements to your teams and vendors
Take the seven controls to the teams and vendors building agents whom you already pay. Ask your IdP, your SIEM, and any agent vendor which of these they can show you working in your stack today.
Decide your trust boundary
Write down what counts as untrusted content in your environment. Every future agent decision gets easier once that line exists.
The web is adversarial and the models are evolving fast; in Clinton's view, the organizations that learn to size and accept this risk now are the ones that get the advantage.