AI Agent Security for Law Firms: Anthropic’s 4 Questions

July 24, 2026

AI agent security framework showing four governance checkpoints—Ingestion, Actions, Blast Radius, and Observability—flowing through an approval decision process for secure AI agent deployment in a modern law firm environment.

Anthropic’s own Deputy CISO just told other security leaders something most vendors won’t say out loud: zero risk isn’t the job. Jason Clinton published a guide last week called “Zero risk isn’t the job: a CISO’s guide to agentic AI,” and it lays out the exact framework Anthropic’s security team uses before letting any AI agent touch production systems. For a firm running Claude, Copilot, or any agentic tool across a matter, that framework is worth stealing wholesale, and it happens to line up closely with what we’ve been telling clients about AI agent security for law firms for months now.

I’ll be honest, most vendor security content is marketing dressed up as guidance. This one isn’t. It reads like something written by a person who has had to explain an agent incident to a board, because it was.

Most law firms still think about AI agent security for law firms as a policy question: which tools are approved, which aren’t. Clinton’s guide is a useful reset. It treats agent security as an architecture question instead, one with a repeatable set of questions you answer before an agent ever touches a matter, not after something goes sideways in one.

The Four Questions Anthropic Asks Before Any Agent Goes Live

Clinton’s team runs every new agentic use case through four questions before approving it. None of them are complicated, which is probably why they work.

What untrusted content does the agent ingest?

Untrusted means anything an attacker could have written or altered: outside email, the open web, a third party document, a public repository. If the answer is genuinely nothing, the agent specific risk is close to zero. Most law firm agents don’t get that lucky. A research agent pulling case law off the open web, a document agent processing an opposing counsel filing, an inbox assistant reading external email, all of that counts as untrusted.

What actions can it take, and on whose behalf?

Read only is one risk category. Read and write is a different one entirely. Every action an agent takes happens under some identity, and Clinton’s point, which I think firms underrate, is that you have to know whose identity that is at all times, not just at setup.

What’s the blast radius if it goes wrong?

Not if it gets hacked, if it drifts, misreads a prompt, or just makes a bad call while acting on real permissions. Does it touch one file or the whole firm? Is a failure an annoyance or a genuine incident?

What observability do you have, really?

Can you tell an agent’s actions apart from a human’s in your logs? Does any of it reach a SIEM, or does it just sit in a vendor dashboard nobody checks?

Four questions. Ask them before deployment, not after something surfaces in a client audit.

Where the Framework Gets Honest About Its Own Limits

Here’s the part of Clinton’s piece that stood out to me most, more than the four questions themselves. He describes what he calls the agentic identity spectrum. On one end sits a system service account: a narrow, single purpose agent with no human identity attached, doing one job. On the other end sits a human credential, where a person at the keyboard is accountable the same way they’d be accountable for anything else they did themselves.

The middle of that spectrum is where it gets uncomfortable. That’s where an agent carries a person’s delegated identity into systems that person isn’t actively watching. Clinton’s own words: “ambiguous accountability is how incidents become unexplainable.”

That’s the exact question a partner at a recent ILTA Evolve session should be sitting with right now. When a Claude agent runs under an attorney’s own credentials, doing research, drafting, touching files that attorney has access to, how do you tell, after the fact, whether a given action was the attorney typing or the agent acting on the attorney’s behalf? Anthropic’s own guide doesn’t pretend there’s a clean answer. Their mitigation isn’t a magic identity flag that separates human clicks from agent clicks in real time. It’s telemetry: routing every tool call, every action, through a stream that lands in a SIEM, tagged with session context, so that when something looks wrong, you can reconstruct what happened after the fact.

That’s a real answer. It’s just not the answer most people want, which is a way to know in the moment. Until something better exists, the honest posture for a firm is to assume any given action from a shared identity could be automated and build your review and audit habits around that assumption rather than around the comfort of thinking a human did it.

There’s a good reason Clinton frames it this way instead of promising a fix. Security teams already have a name for a person acting with legitimate access in ways that turn out to be harmful: insider risk. Ponemon Institute’s 2026 Cost of Insider Risks report found organizations took an average of 67 days to contain an insider incident, even with a dedicated program in place. An agent acting under someone’s own credentials is, functionally, an insider risk case. Sixty-seven days is a reasonable timeline for a human insider threat. It is nowhere close to fast enough for something to move at agent speed.

Why This Is Really a Permissions Problem, not an AI Problem

Traditional data loss prevention was built around a simple idea: a human decides to move a file, and a rule intercepts that decision. Agents break that model, and not by breaking any rules. When an attorney connects an agent to firm systems, the agent inherits whatever permissions that attorney already holds. It doesn’t need to steal access. It uses the access it was handed.

That is a permissions and identity problem wearing an AI costume. A firm’s permission management posture, who can access what, and whether that access is scoped tightly or left wide open by default, determines how bad an agent misstep can get long before the agent itself does anything wrong. Clinton’s blast radius question and a firm’s existing permission sprawl are really the same conversation.

Least Agency: The Rule Hiding Inside the Framework

Clinton names a principal worth remembering on its own: least agency, grant an agent the narrowest capability that still completes the task. Not the broadest access that’s convenient. The narrowest that works.

In practice that means a contract review agent gets read access to the matter it’s working, not read and write access to the whole document management system. It means a research agent gets the open web, not your billing data. This isn’t a new idea, security teams have preached least privilege for decades, but agents make the cost of skipping it much higher, because an agent will use whatever access it has, at machine speed, without pausing to ask if it should.

We’ve written before about how cloud misconfiguration and agent security tend to be the same failure mode showing up in different systems: permissions that were set once, for convenience, and never revisited once an agent started acting on them.

The Observability Gap: Where This Meets Your Existing DLP Stack

Clinton’s fourth question, what observability do you have, is the one I think most firms will fail first, and it connects directly to a problem we’ve written about before. Traditional data loss prevention was built to catch a human decision: someone uploads a file, sends an email, prints a document. A DLP rule intercepts that decision. Agents don’t announce themselves that way. An agent extracting insights from a matter, summarizing a privileged document, or drafting a client communication doesn’t necessarily trip a single DLP alert, because nothing left the building in the way DLP was built to notice.

That’s exactly why Clinton pushes every agent’s activity into a SIEM as raw telemetry, tool name, parameters, success or failure, tied to session identity, rather than trusting a vendor dashboard nobody opens. A firm serious about AI agent security for law firms needs the same discipline: endpoint controls that know an AI destination when they see one, and a cloud access layer that can tell you, with confidence, which AI tools are in use and by whom. Without that, agent security is a policy on paper, not a control anyone could point to during a client audit.

What This Means for Your Firm's Copilot and Agent Rollout

Most firms didn’t choose to have this conversation on their own timeline. Copilot showed up because Microsoft bundled it in. Claude showed up because an associate found it useful. The rollout happened before the governance did, which is backward, but it’s also just reality for almost everyone right now.

If your firm has already deployed Copilot, or is actively evaluating it, this is a good moment to revisit whether your Copilot governance approach answers Clinton’s four questions for each Copilot agent in use, not just for Copilot as a product. “We approved Copilot” is not the same statement as “we know what each agent inside Copilot can touch, on whose behalf, and whether we’d notice if it went wrong.” Those are different sentences, and only one of them holds up under a client audit.

Where to Start This Week

Clinton’s own advice for getting started translates well to a law firm context. Pick the one agentic use case generating the most internal pressure right now, the one attorneys are already asking for or already using informally and run it through the four questions honestly. Don’t aim for a verdict. Aim to find the conditions under which you’d be comfortable approving it.

Then write down, in plain language, what counts as untrusted content in your environment. That single decision makes every future agent conversation faster, because you stop relitigating it from scratch each time.

Waiting for a zero risk answer means waiting forever, and Clinton says as much directly. The firms that get ahead of this aren’t the ones with the biggest security budget. They’re the ones willing to ask these four questions honestly, including about the agents already running under someone’s own login right now.

If you want a structured way to work through where your firm’s access controls, identity boundaries, and agent permissions stand today, our AI Readiness Assessment: What DLP Misses With Agents is built around exactly that kind of review.

Steve Combs

Co-Founder & Managing Director, Cocha Technology

Steven is a fractional CIO/CISO with 30+ years of enterprise IT and security leadership. He has built AI governance frameworks for organizations with 1,700+ users, led enterprise Microsoft Copilot deployments, and conducted security assessments across law firms, energy companies, financial institutions, and PE-backed manufacturers.