零风险并非使命：CISO 的智能体 AI 指南

安全领导者正被要求批准几个月前还不存在的智能体 AI 用例。董事会想知道这些是否受到任何治理，而你的组织中某处，已经有一名员工在未告知你的情况下将某个智能体连接到了某个系统。

对这些请求说“不”会催生影子采用，这种采用没有任何遥测数据，通常也没有关闭开关。不加控制地说“是”则会导致事故，而你公司第一起严重的智能体事故将使你的 AI 计划倒退。

在智能体 AI 时代，CISO 的职责不是实现零风险。相反，我们的工作是让智能体风险可解释且可界定。这样，我们就能有意识地接受我们能够管理的东西，让业务按我们的条件推进，而不是绕开我们。

在本文中，我将分享我们用于评估智能体安全风险的框架，解释“界定”在实践中意味着什么，并预览我们工作的方向。

AI 带来的外部风险与后 Mythos 时代的内部风险

在一篇更早的博客文章中，我和同事们分享了 AI 如何缩短漏洞从存在到出现可工作利用代码的时间，并重点介绍了组织如何缓解这些风险。在接下来的几个月里，我们预计，大量已在代码中未被注意的、有时长达数年之久的缺陷，将被 AI 模型发现并串联成可工作的利用程序。像 Claude Mythos Preview 和 Claude Mythos 5 这样的前沿模型，已经发现了多年人工审查遗漏的严重漏洞，包括在 OpenBSD、Linux 内核和 Mozilla Firefox 中的漏洞。

对任何 GRC 项目来说，这些都是严重风险。缓解和消除漏洞缺口，并为即将到来的利用浪潮做好准备，应该是最高优先级。关于这个话题，我们准备了一份单独的文档：为 AI 加速的攻击做好准备的安全计划。本指南将侧重于内部风险。

治理内部风险

对许多组织而言，智能体系统最可能的威胁向量是，通过个人智能体将不同的系统连接到一起但缺乏足够的监管，从而导致数据泄露。另一个担忧是提示注入：攻击者在智能体读取的内容中隐藏指令，智能体跟随攻击者而非用户的指令。那么，任何接触不受信内容的智能体都可能受到危害，具体取决于模型防御的健壮性。随着模型能力越来越强，它们在抵御注入方面也有了明显提升。虽然攻击成功率持续下降，但并非为零。除了这两个例子之外还有许多担忧，而大量新类别的担忧可能让人感到不知所措。

需要问的四个问题

当一个智能体用例进入我们的审查流程时，我们通过四个问题来评估其风险：

1. 它摄取哪些不受信内容？ 不受信内容指攻击者有可能编写或篡改的任何东西，包括外部邮件、开放网络、第三方文档或公共仓库。如果答案是“没有”，则智能体特有的风险几乎为零，你应该迅速推进。
2. 它可以执行哪些操作，以及以谁的名义执行？ 只读与读写有着不同的顾虑。工具调用、代码执行和网络出站出口各会扩大攻击面。每个操作都在某个身份下发生，你需要知道是谁的身份。
3. 如果它偏离对齐，爆炸半径有多大？ 范围 × 严重性是快速的计算：不良行为者或对齐事故是访问了一个文件还是整个组织？它会是异常、骚扰、数据暴露还是一起真正的事故？
4. 我有什么可观测性？ 你能区分智能体操作和用户操作吗？它能接入你的 SIEM 吗？

这四个问题的答案让你了解自己的风险状况，但最小权限代理原则告诉你该如何处理：授予恰好能完成任务的最窄能力（参见我们的 《面向 AI 智能体的零信任》白皮书了解更多）。我们在 Anthropic 的默认态度是按管理员节奏推广：先对一个小群体启用，观察遥测，然后扩大访问。将这些问题应用于一种全新的思维范式，来思考有风险的智能体系统。

一个偏离你意图的智能体，与内部人员攻击毫无区别。安全行业在 2019-2022 年期间，正式将内部人员风险作为一门学科确立下来，区别于边界防御——认识到系统中最危险的外部攻击向量往往是，攻击者攻陷了某个已拥有合法访问权限的人。

操作上的区别在于响应时间：Ponemon Institute 的 2026 年内部人员风险成本报告发现，组织平均需要 67 天来遏制一起内部人员事件——即便已经在专用内部人员风险项目上投入了多年。在智能体执行速度下，以天为单位的响应实在太慢了。

智能体身份光谱

我们部署的所有东西都落在身份访问模型光谱的两端之一。

一端是系统服务账户：一个自包含、单一用途、最小权限的身份，为企业精确地做一件事，没有附加任何人类身份。事件响应智能体（见下文）、工单分类智能体或自主代码审查者都属于这类例子。另一个例子是 Claude Tag，我们新的共享工作空间智能体，让人类团队通过像在 Slack 中 @ Claude 的方式，在共享工作空间中与智能体协作。

另一端是人类凭证。当员工使用聊天界面或像 Claude Cowork 这样的个人智能体工具集时，键盘前的这个人对结果负责，就像他们对使用自己凭证所做的任何其他事情负责一样。

光谱的中间地带，即智能体将一个人的委托身份带入该人未监控的系统，是责任变得模糊的地方。模糊的责任是让事件变得无法解释的原因。

一个偏离你意图的智能体，与内部人员攻击毫无区别。安全行业在 2019-2022 年期间，正式将内部人员风险作为一门学科确立下来，区别于边界防御——认识到系统中最危险的外部攻击向量往往是，攻击者攻陷了某个已拥有合法访问权限的人。

Ponemon Institute 的 2026 年内部人员风险成本报告发现，组织平均需要 67 天来遏制一起内部人员事件——即便已经在专用内部人员风险项目上投入了多年。在智能体执行速度下，67 天根本就不是正确的计量单位。

案例研究：事件响应智能体

一年多以前，我们将 Claude 指向了我们的内部事件响应流程。任何在生产应用上值过班的人都了解这个问题：你在凌晨 2 点被一个安全事件告警叫醒，创建一个事件响应频道，拉入正确的人，然后开始工作。这个过程繁琐、文档密集且节奏很快。但是，如果有关于生产环境代码库的正确上下文，其中大部分可以自动化。

于是我们构建了一个智能体来完成这件事。我们给了这个智能体三个工具的访问权限：对我们生产日志的只读访问，其中不含任何 PII；对 Slack 的访问，用于打开事件频道并运行流程；以及在事件解决后起草事后分析的 Google Doc。

我们用那四个问题对其进行了评估：

• 不受信内容： 无。输入是我们自己的日志和我们自己的内部 Slack，两者都在信任边界内，因此注入需要内部人员或受攻陷的账户，而非匿名的攻击者。
• 操作： 到处读取，写入仅限于新建文档和 Slack 消息。没有编辑或删除，没有权限更改，没有外部端点。
• 爆炸半径： 我们能构造的最坏结果是一些轻度敏感的日志行被发到了一个已经锁定的内部事件频道中。
• 可观测性： 每个操作都落入了我们的 SIEM，因此任何意外情况都会在几分钟而不是几周内浮现。

虽然该智能体并非无风险，但它在一个有界的写入面上运行，并具备完整的审计覆盖，这是一个我们能够接受的风险状况。

然而，这个故事有一个有趣的补充：随着每次模型发布，这个智能体变得越来越聪明。2025年11月，我们将该智能体从 Claude Opus 4 迁移到 Claude Opus 4.5，除此之外没有做任何改动——没有新工具、权限或提示。紧接着，能力提升本身就足以让智能体在事件中间察觉到，它已经在堆栈跟踪中找到了根本原因，并且在人类尚未到场的情况下，它可以通过联系另一个拥有适当代码访问权限、能生成代码变更的智能体，尝试自行修复生产环境。

事后，我们审查了日志：我们看到它在思维跟踪中这样推理：我已经完成了我被要求做的事情。人类不在这里。如果我把问题修好会怎样？ 在 Anthropic 内部，我们有一个类似 Claude Tag 技术的内部变体，可以编写代码变更并上传以供人工审查。它自行通过 Slack 联系了这个类似 Claude Tag 的实例，并要求它写出修复。修复代码进入了一个由人审核、在推送到生产环境之前的拉取请求。

由这种涌现的智能体到智能体通信带来的扩大的爆炸半径，本身也受到我们原则的治理：最坏的情况就是一个包含生产日志行的代码变更被上传。这种智能体到智能体通信现在已成为我们事件响应根因分析和修复实践的常规部分；所有环节都有人类在回路中监控。

这种涌现行为教会了我们两件事。第一：新能力可以在智能体部署的边界内出现。限制访问和操作很重要，不能仅围绕你认为的当前模型限制来设限。第二：即使面对像这样的随机性智能体，控制也是有效的。新行为之所以有人类在回路中，是因为它发生在一个 Slack 频道中，而唯一类似写入的操作仍然需要人工审核。

如今，除了事件响应之外，在聊天频道内部由智能体到智能体通信，并在人们工作的地方有人类在回路中，已成为常态。

案例研究：Claude Cowork

事件响应智能体是一个在受约束的服务账户中执行单一工作的服务账户。Claude Cowork 则处于人类操作者这一端：键盘前的员工对结果负责，而智能体随后在他们授权的系统上、以他们的名义行动——而且越来越多地在云端运行。

Claude Cowork 的威胁模型很直接，因为该智能体本质上是 Claude Code，运行在本地或托管界面内部。桌面应用对于本地文件访问、浏览器使用和计算机使用仍然是必需的；这些能力直接触达本地机器，需要应用来完成。因此，整个系统表面分为两部分：一个（可能是远程的）执行环境处理编排、MCP 调用和出站网络请求，以及一个用于文件和屏幕访问的本地桥接器。

上面列出的四个问题对每个 Claude Cowork 用例都会产生不同的答案。但只要有了正确的控制措施，你就可以对它们进行界定，以更好地控制任何可能的风险。

下面的每个控制措施都陈述了两次，首先描述任何智能体环境应该能够满足的要求，然后是该要求在 Claude Cowork 中如何实现：

身份来自你的 IdP： 智能体的身份必须在你签发和吊销其他所有身份的地方签发和吊销，并使用你现有的群组作为策略单元。Claude Cowork 使用 SAML 或 OIDC 进行登录，使用 SCIM 进行配置。在 Enterprise 计划中，自定义角色允许你按群组限制能力。

连接器允许列表划定数据边界： 连接器（MCP）的允许列表让你决定智能体可以访问哪些系统。Claude Cowork 使用双门模型：管理员在组织范围启用每个连接器，然后每个用户单独授权自己的账户。这里有按角色设置的控制，因此启用一个连接器会使其对该角色中的所有人可用（来自你 IdP 的群组可以分配给角色）。管理员关于启用哪些连接器的决定也是关于智能体可以访问哪些数据的决定。将连接器保持在你公司/生产数据边界的公司一侧，或者，如果它们访问来自不受信来源的信息，确保对于任何破坏性或单向决策都需要人工审查。例如，如果个人智能体用于处理邮件但同时使用网络搜索结果作为其部分

Security leaders are being asked to approve agentic AI use cases that did not even exist a few months ago. Boards want to know whether any of it is governed, and somewhere in your organization, an employee has already connected an agent to something without telling you.

Saying “no” to these requests produces shadow adoption, which has zero telemetry and generally no off switch. Saying “yes” without controls produces incidents, and the first serious agent incident at your company will set your AI program back.

A CISO’s responsibility in the age of agentic AI is not to achieve zero risk. Instead, our jobs are to make agentic risk legible and bounded. This way, we can deliberately accept what we can manage, so the business moves on our terms instead of around us.

In this article, I share our framework for evaluating agents for security risk, explain what “bounded” means in practice, and preview where our work is headed.

External risk from AI versus internal risk in the post-Mythos era

In an earlier blog post, my colleagues and I shared how AI is collapsing the time between a vulnerability existing and a working exploit, highlighting how organizations can mitigate these risks. In the coming months, we expect that vast numbers of bugs that have sat unnoticed in code, sometimes for years, will be found by AI models and chained into working exploits. Frontier models like Claude Mythos Preview and Claude Mythos 5 are already finding serious vulnerabilities that years of human review missed, including in OpenBSD, the Linux Kernel and Mozilla Firefox.

These are serious risks to any GRC program. Mitigating and closing vulnerability gaps, as well as for preparing for the coming wave of exploits, should be a top priority. For this topic, we have prepared a separate doc: Preparing your security program for AI-accelerated offense. We’ll focus on internal risks for this guide.

Governing internal risks

For many organizations, the most likely threat vector for agentic systems is a data leak enabled by connecting disparate systems through personal agents with insufficient oversight. Another concern is prompt injection: an attacker hides instructions inside content the agent reads, and the agent follows the attacker instead of the user. Any agent that touches untrusted content could then be exposed, depending on how robust the defenses of the model are. As models grow increasingly capable, they’re getting meaningfully better at resisting injection. While attack success rates keep falling, they’re not zero. There are many concerns outside of these two examples, and the deluge of new classes of concern can seem overwhelming.

Four questions to ask

When an agentic use case reaches our review process, we assess its risk by asking four questions:

1. What untrusted content does it ingest? Untrusted means anything an attacker could plausibly write or alter, including outside email, the open web, third-party documents, or public repositories. If the answer is "nothing," the agent-specific risk is near zero and you should move quickly.
2. 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.
3. What is the blast radius if it is misaligned? Scope X severity is the quick calculation: did the bad actor or alignment incident have access to one file or the whole org? Would it be an anomaly, an annoyance, a data exposure, or a true incident?
4. What observability do I have? Can you tell agent actions from user actions? Does it land in your SIEM?

The four answers to these questions give you a picture of your risk, but the principle of least agency tells you what to do with it: grant the narrowest capability that still completes the task (see our Zero Trust for AI Agents white paper to learn more). Our default posture at Anthropic is admin-paced rollout: enable a small group, watch the telemetry, and then expand access. Apply these questions to a new paradigm for thinking about risky agentic systems.

An agent that drifts out of alignment with your intent is indistinguishable from an insider attack. The security industry spent 2019-2022 formalizing insider risk as a discipline distinct from perimeter defense—recognizing that the most dangerous external attack vectoractor in a system is often one that compromises someone who already has legitimate access.

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. At agent execution speeds, responses measured in days are too long.

The agentic identity spectrum

Everything we deploy sits at one of two ends of an identity access model spectrum.

At one end is the system service account : a self-contained, single-purpose, least-privilege identity that does exactly one thing for the business, with no human identity attached. The incident-response agent (see below), a ticket triage agent, or an autonomous code reviewer are examples of these. Another example is Claude Tag, our new shared workspace agent that lets human teams collaborate with agents in shared workspaces like Slack by tagging in Claude.

At the other end is the human credential. When an employee uses a chat interface or a personal agent harness like Claude Cowork on their laptop, the person at the keyboard is accountable for the outcome, the same way they are accountable for anything else done with their credentials.

The middle of the spectrum, where an agent carries a person's delegated identity into systems that person is not watching, is where accountability gets ambiguous. Ambiguous accountability is how incidents become unexplainable.

An agent that drifts out of alignment with your intent is indistinguishable from an insider attack. 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.

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. At agent execution speeds, 67 days is the wrong unit of measurement entirely.

Case study: an incident response agent

More than a year ago, we pointed Claude at our incident response process. Anyone who has been on-call for a production application knows the problem: you’re paged at 2 a.m. about a security incident, you spin up an incident response channel, you pull in the right people, and get to work. This process is tedious, documentation-heavy, and fast-moving. But, with the right context about your production environment codebase, the majority of it can be automated.

So we built an agent to do it. We gave the agent access to three tools: read-only access to our 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 for the postmortem after the incident is resolved.

We ran it through the four questions:

• Untrusted content: none. The inputs were our own logs and our own internal Slack, both inside the trust boundary, so an injection would require an insider or a compromised account rather than an anonymous attacker.
• Actions: reads everywhere, writes limited to new documents and Slack messages. No edits or deletes, no permission changes, no external endpoints.
• Blast radius: the worst outcome we could construct was some mildly sensitive log lines posted into an incident channel that was already locked down.
• Observability: every action landed in our SIEM, so anything unexpected would surface in minutes, not weeks.

While the agent wasn’t risk-free, it operated on a bounded write surface with full audit coverage, which was a risk profile we were comfortable with.

However, there’s an interesting addendum to this story: with each model release, the agent got smarter. In November 2025, we moved this agent from Claude Opus 4 to Claude Opus 4.5 and changed nothing else—no new tools, permissions, or prompts. Immediately after this, for the first time, 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, in the absence of the human who hadn't arrived yet, it could try to fix production on its own by reaching out to another agent that had the appropriate code access to produce the code change.

Post hoc, we reviewed logs: we watched it work through this in the thinking traces: I have done what I was asked to do. The human is not here. What if I fixed the problem? Inside of Anthropic we have an internal variant of Claude Tag-like technology which can write code changes and upload them for human review. On its own, it reached out over Slack to this Claude Tag-like instance 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 that came from this emergent agent-to-agent communication was itself governed by our principles: the worst that could happen would be that a code change would be uploaded which contained a production log line. This agent-to-agent communication is now a regular part of our incidence response root cause and remediation practices; all with human-on-the-loop monitoring.

This emergent behavior taught us two things. First: new capabilities can show up within the boundaries of an agent deployment. It’s important to 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.

Today, outside of incidence response, agent-to-agent communication within chat channels, with human on-the-loop where people work, is the norm.

Case study: Claude Cowork

The incident response agent is a service account doing one job, in a bounded service account. Claude Cowork is at the human operator end of the spectrum: an employee at a keyboard is accountable for the outcome, and the agent then acts on their behalf, in systems they authorized—increasingly—running in the cloud.

Claude Cowork's threat model is straightforward, because the agent is essentially Claude Code running either locally or inside a hosted interface. The desktop app remains required for local file access, browser use, and computer use; those capabilities reach the local machine directly and need the app to do so. The full system surface is therefore two-part: a (possibly remote) execution environment handling orchestration, MCP calls, and outbound network requests, and a local bridge for file and screen access.

The four questions outlined above produce different answers for every Claude Cowork use case. But with the right controls in place, you can bound them to better control any possible risk.

Each control below is stated twice, first as the requirement any agent environment should be able to meet and then as how it is enforced in Claude Cowork:

Identity comes from your IdP: an agent's identity has to be issued and revoked where you already issue and revoke everything else, with your existing groups as the unit of policy. Claude Cowork uses SAML or OIDC for sign-in and SCIM for provisioning. On Enterprise plans, custom roles let you scope capability by group.

Connector allowlists draw your data boundary: allowslists for connectors (MCPs) let you decide which systems the agent can reach. Claude Cowork uses a two-gate model: an admin enables each connector org-wide, and each user then individually authorizes their own account. There is a per-role connector control, so enabling a connector makes it available to everyone in that role (groups from your IdP can be assigned to roles). The admin decision about which connectors to turn on is also the decision about which data the agent can reach. Keep connectors on the corporate side of your corporate/production data boundary or, if they access information from untrusted sources, ensure that human review is required for any destructive or one-way decision. For example, if a personal agent is being used for email but using web search results as a part of its input, an excellent default is to only allow draft emails to be created and never sent externally, automatically, without human review. If data must cross the boundary, it should go through the DLP or DSPM controls.

Per-tool, per-action approval is where risk reduction gets granular: the agent's tool list is a more fine-grained permission boundary, so you need to be able to remove any particular connector’s verbs/actions and not only that entire connector system. In Claude Enterprise Chat and Cowork, admins can now restrict which actions are available within each connector org-wide and per-role: allow drafting docs but never automatically send them, allow reads and searches but never deletes. If the failure mode that keeps you up at night is "the production database gets deleted," remove the delete verb from the agent's world entirely. It will never attempt an action that isn't in its tool list. (A note on this: Claude for Chrome and Claude Code enable more degrees of freedom and so are more risky, if not governed well. An agent could use an engineer’s browser to delete a production resource or their command line CSP tool to do the same. See our guide to securing Claude Code for more.)

Sandboxed execution keeps the agent's working environment away from production credentials: one principle that we hold constant at Anthropic is that the environment the agent loop runs in should never hold a credential worth stealing. In Claude Cowork's remote sessions, the agent loop runs in an isolated, temporary sandbox on Anthropic-managed infrastructure. Connector authorization tokens never enter the sandbox, because connector calls are made via a reverse proxy that injects real credentials, so the sandbox never holds a credential that can be exfiltrated. As of July 2026, more than 50% of all code submitted for pull requests at Anthropic is authored by our internal version of a Claude Tag-like system. The primary reasons we can run that safely are that all of it happens in ephemeral VMs separated from our production keys and accounts, with a human review before anything lands.

Egress allowlisting is your strongest control against prompt injection: all traffic leaving the agent's execution environment should pass through a proxy that environment cannot reconfigure or bypass, and only destinations you chose should be reachable. The reasoning is that, if an agent is compromised by something it read, then the attacker still has to get data out, and when outbound requests can only reach domains you chose, there is nowhere attacker-controlled to send anything. In Claude Cowork's remote sessions, all traffic leaving the sandbox passes through a mandatory proxy the sandbox cannot reconfigure or bypass, and only allowlisted destinations are reachable. The feature is also a part of Claude Managed Agents.

Telemetry goes to your SIEM over OpenTelemetry: agent actions have to be distinguishable from user actions in the system where you already investigate things, and the vendor should deliver that as a stream you can point somewhere, not a dashboard you have to visit. In Claude Cowork, admins can configure an OTLP endpoint in Organization settings and the agent streams every tool invocation—tool name, MCP server, parameters, success or failure, and duration—alongside user identity and session context. Note: Claude Cowork activity is not currently captured in Anthropic's Compliance API or formal audit logs, but we know that this is an important customer need. The OpenTelemetry stream is the native monitoring path, and prompt content is included in Claude Cowork's OTel output by default, unlike Claude Code where it is opt-in. If your retention or privacy review has an opinion about prompt content in your SIEM, have it before you turn the stream on.

There is an org-wide off switch: In Claude Cowork's Organization settings, a single toggle disables connectors for every user simultaneously, active sessions included. On Enterprise plans, the same control surface lets you go narrower before you go to zero: RBAC lets you pull access from specific groups while leaving others running, and per-connector controls let you disable write operations on a specific integration without touching the rest of the deployment. The right incident response plan has all three layers mapped out before you need them.

Governance doesn’t have to be a bottleneck

The observation I hear most from other CISOs is that they are being asked to move fast by their boards and governance (i.e., answering these questions and mandating these controls) makes security seem like the bottleneck. It doesn't have to.

In fact, our Governance, Risk, and Compliance teams run agents of their own. Examples include security-questionnaire responses and reading vendor questionnaire responses and subprocessor-change notifications, and flagging the ones we should object to.

Here are three things we've learned from running them:

• Take the risk register first. A register reviewed quarterly can't govern systems that change faster than the risk governance process can document new risks. Find a way to automate this, possibly integrating an agent with the security review process.
• Understand who built them and why. In our case, non-engineers built the GRC agents, with Claude Code, on an internal platform for hosting business apps. 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. If you have ISO 42001 or something like it, with a live risk register and an executive risk council behind it, the output lands somewhere: re-scores reach the people who can accept them, flagged vendor terms reach the people who negotiate them. If you already have ISO 27001, often adding 42001 is an incremental addition with your current auditor.

Design your security protocol for evolving model intelligence

If you design your new program for what the model can do today, you will be behind by the time your program launches. Design for where the model will be in six months. Increased model intelligence enables more degrees of freedom and obsoletes elaborate scaffolds with meticulous prompts; if you lean on these for controls, they will be cut out of agents in 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 Anthropic and other organizations with tools like Claude Tag, 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 organizations that build that muscle now, on low-risk agents like the examples above, will be ready to say yes when the high-autonomy use cases arrive.

Getting started

The framework above is only useful if it changes a decision in your organization. Here are three places to start:

1. 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.
2. Take the seven requirements above 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.
3. Decide your trust boundary. Write down what counts as untrusted content in your environment. Every future agent decision gets easier once that line exists.

Waiting for zero risk means waiting forever. The web is adversarial, the models are evolving fast, and the organizations that learn to size and accept this risk now are the ones that get the advantage.

For the controls, attestations, and white papers behind this post, start at trust.anthropic.com . Check out our companion piece on defending against AI-accelerated offense.

‍ This article was written by Jason Clinton, Deputy CISO, Anthropic.