Last week, Anthropic's Deputy CISO Jason Clinton published a guide to agentic AI for CISOs. The headline says it plainly: zero risk isn't the job. The job is making agentic risk legible and bounded so the business moves on your terms instead of around you.
He's right. And the four questions he proposes for every agent review are the right questions: what untrusted content does it ingest, what actions can it take and on whose behalf, what's the blast radius, and what observability do you have.
We've been building Opsin's Agent Defense around the same convictions, so reading the guide felt like watching someone describe the problem we wake up to every day. But there's a gap between asking those four questions once, at review time, and answering them continuously across hundreds of agents built by people who have never opened a security tool. That gap is where agent defense actually lives. Here's how we see it.
Anthropic's second question asks what actions an agent can take. That's necessary, but a capability list alone is a bad risk signal. A delete_resources tool on an SRE incident agent is expected. The same tool on a public-facing HR bot is a critical finding. Same capability, completely different risk, and the only thing separating them is purpose.
This is why we anchor everything on Agent Intent: what the agent was provisioned to do, who it was meant to serve, what data domain it should touch, and what constraints it declared. Capture that at build time, from the agent's name, instructions, connected tools, and creator, and you have a reference point. Now "least agency" stops being a slogan. You can't grant the narrowest capability that completes the task if nobody wrote down what the task is.
The gap between meant-to-do and can-do is the finding. Not the tool. Not the permission. The mismatch.
The sharpest part of the guide is the identity spectrum. At one end, a single-purpose service account. At the other, a human at a keyboard who owns the outcome. The middle, where an agent carries someone's delegated identity into systems nobody is watching, is where Clinton says accountability gets ambiguous. And ambiguous accountability is how incidents become unexplainable.
Our answer is blunt: no agent without an owner. Ownership isn't metadata to backfill later. It's a first-class property of the agent and of every issue raised against it. When an agent drifts, when it picks up a tool it shouldn't have, when it retrieves a file for the wrong audience, someone specific gets the finding. Clinton makes the same point about risk acceptance: deliberately accepting risk is an act performed by humans with the authority to accept it. You can't perform that act if the answer to "whose agent is this" is a shrug.
An agent that drifts from its intent is indistinguishable from an insider threat. You wouldn't run an insider risk program where employees have no manager. Don't run an agent program where agents have no owner.
Clinton describes compliance analysts at Anthropic building their own GRC agents with Claude Code, and argues that a person who can build the tool they need, where you can see it, isn't shadow adoption. Agree completely. The people provisioning agents today are financiers, marketing ops leads, and HR partners. They aren't developers, and they're not going to file a ticket and wait.
Security teams can't be the only reviewers in that world. The math doesn't work. A team of five can't babysit eight hundred agents, and if every finding lands in the SOC queue, the queue becomes the place findings go to die.
The owners have to be part of the remediation loop, and that only works if the finding arrives with context they can act on. "Agent has email tool" means nothing to an HR partner. "Your org-wide HR policy assistant can send external email, but it was built for read-only policy Q&A" is something they can fix in five minutes. Give owners the intent, the mismatch, and the fix. Keep security as the escalation path, not the bottleneck. That's how governance stops being the thing people route around.
Anthropic's first question, what untrusted content does the agent ingest, is the right place to start, because prompt injection is real and attack success rates aren't zero. But here's the operational problem: the moment an injection lands, every individual event still looks fine. Valid account. Approved tool. A file the agent can technically reach. An email that was, technically, just an email.
The risk only shows up in the chain. A CFO's assistant reads an external email, then starts searching for financial details, then reaches for an outbound channel. Each step passes a permission check. Together they tell you the agent is now following the attacker's intent instead of its own. Catching that requires connecting the actor, the agent, the data, the action, and the untrusted source that set it in motion, and comparing the whole chain against what the agent was meant to do.
This is where a lot of AI security tooling falls short. A keyword match tells you something happened. It can't tell you whether the action and the untrusted input are connected, and whether the combination still fits the agent's purpose. Without that context you get noise, and noisy queues get ignored, which is worse than no detection at all.
Clinton closes with the line that should be on every CISO's wall: waiting for zero risk means waiting forever. The organizations that learn to size and bound agent risk now will be the ones that get to say yes when the high-autonomy use cases arrive.
Our version of bounded looks like this: every agent has a declared intent, every agent has an owner, every owner gets findings with context they can act on, and detection connects untrusted input to action instead of scoring events in isolation. That's not a framework for slowing agents down. It's the reason you get to keep deploying them.
Directly. The four questions cover untrusted content, actions and identity, blast radius, and observability. Agent Intent answers what actions and data are proportionate to the agent's purpose. Ownership modeling answers who is accountable. AIDR 2.0 answers whether observed activity, including activity triggered by untrusted content, still fits the agent's intended use. The guide defines the review. Agent defense makes it continuous.
Intent is the purpose the agent was provisioned for: its audience, topic, actions, goal, and declared guardrails. Scope is what it can actually reach: tools, connectors, data sources, sharing, and identity. Security findings come from comparing the two. A capability that's expected on one agent is a critical issue on another.
Because remediation and risk acceptance are human acts. When an agent drifts or gets misused, someone with context has to decide whether it's an exception, a fix, or a shutdown. Without a named owner, findings pile up in a security queue with no one able to answer whether the behavior was ever legitimate.
It means the people who build agents participate in securing them. Findings are routed to agent owners in plain language, with the specific mismatch and the specific fix, while security keeps oversight and handles escalation. It's the only model that scales with the rate agents are being created.
Because ingesting untrusted content is normal. Agents read email, browse the web, and process third-party documents all day. The risk appears when untrusted input starts steering actions, like sensitive data retrieval followed by external egress. You need the connected chain of actor, agent, data, and action, judged against the agent's intent, to separate an attack from a Tuesday.
Last week, Anthropic's Deputy CISO Jason Clinton published a guide to agentic AI for CISOs. The headline says it plainly: zero risk isn't the job. The job is making agentic risk legible and bounded so the business moves on your terms instead of around you.
He's right. And the four questions he proposes for every agent review are the right questions: what untrusted content does it ingest, what actions can it take and on whose behalf, what's the blast radius, and what observability do you have.
We've been building Opsin's Agent Defense around the same convictions, so reading the guide felt like watching someone describe the problem we wake up to every day. But there's a gap between asking those four questions once, at review time, and answering them continuously across hundreds of agents built by people who have never opened a security tool. That gap is where agent defense actually lives. Here's how we see it.
Anthropic's second question asks what actions an agent can take. That's necessary, but a capability list alone is a bad risk signal. A delete_resources tool on an SRE incident agent is expected. The same tool on a public-facing HR bot is a critical finding. Same capability, completely different risk, and the only thing separating them is purpose.
This is why we anchor everything on Agent Intent: what the agent was provisioned to do, who it was meant to serve, what data domain it should touch, and what constraints it declared. Capture that at build time, from the agent's name, instructions, connected tools, and creator, and you have a reference point. Now "least agency" stops being a slogan. You can't grant the narrowest capability that completes the task if nobody wrote down what the task is.
The gap between meant-to-do and can-do is the finding. Not the tool. Not the permission. The mismatch.
The sharpest part of the guide is the identity spectrum. At one end, a single-purpose service account. At the other, a human at a keyboard who owns the outcome. The middle, where an agent carries someone's delegated identity into systems nobody is watching, is where Clinton says accountability gets ambiguous. And ambiguous accountability is how incidents become unexplainable.
Our answer is blunt: no agent without an owner. Ownership isn't metadata to backfill later. It's a first-class property of the agent and of every issue raised against it. When an agent drifts, when it picks up a tool it shouldn't have, when it retrieves a file for the wrong audience, someone specific gets the finding. Clinton makes the same point about risk acceptance: deliberately accepting risk is an act performed by humans with the authority to accept it. You can't perform that act if the answer to "whose agent is this" is a shrug.
An agent that drifts from its intent is indistinguishable from an insider threat. You wouldn't run an insider risk program where employees have no manager. Don't run an agent program where agents have no owner.
Clinton describes compliance analysts at Anthropic building their own GRC agents with Claude Code, and argues that a person who can build the tool they need, where you can see it, isn't shadow adoption. Agree completely. The people provisioning agents today are financiers, marketing ops leads, and HR partners. They aren't developers, and they're not going to file a ticket and wait.
Security teams can't be the only reviewers in that world. The math doesn't work. A team of five can't babysit eight hundred agents, and if every finding lands in the SOC queue, the queue becomes the place findings go to die.
The owners have to be part of the remediation loop, and that only works if the finding arrives with context they can act on. "Agent has email tool" means nothing to an HR partner. "Your org-wide HR policy assistant can send external email, but it was built for read-only policy Q&A" is something they can fix in five minutes. Give owners the intent, the mismatch, and the fix. Keep security as the escalation path, not the bottleneck. That's how governance stops being the thing people route around.
Anthropic's first question, what untrusted content does the agent ingest, is the right place to start, because prompt injection is real and attack success rates aren't zero. But here's the operational problem: the moment an injection lands, every individual event still looks fine. Valid account. Approved tool. A file the agent can technically reach. An email that was, technically, just an email.
The risk only shows up in the chain. A CFO's assistant reads an external email, then starts searching for financial details, then reaches for an outbound channel. Each step passes a permission check. Together they tell you the agent is now following the attacker's intent instead of its own. Catching that requires connecting the actor, the agent, the data, the action, and the untrusted source that set it in motion, and comparing the whole chain against what the agent was meant to do.
This is where a lot of AI security tooling falls short. A keyword match tells you something happened. It can't tell you whether the action and the untrusted input are connected, and whether the combination still fits the agent's purpose. Without that context you get noise, and noisy queues get ignored, which is worse than no detection at all.
Clinton closes with the line that should be on every CISO's wall: waiting for zero risk means waiting forever. The organizations that learn to size and bound agent risk now will be the ones that get to say yes when the high-autonomy use cases arrive.
Our version of bounded looks like this: every agent has a declared intent, every agent has an owner, every owner gets findings with context they can act on, and detection connects untrusted input to action instead of scoring events in isolation. That's not a framework for slowing agents down. It's the reason you get to keep deploying them.
