Anthropic’s cybersecurity work shows both the defensive value of AI and the importance of controlling its access. Claude Code Security helps developers find vulnerabilities and review proposed fixes, while Anthropic’s evaluations demonstrate what can happen when agents reach systems beyond their intended boundaries.

For enterprises, this raises an immediate question: which agents already have access to internal tools, and who controls what they can do? The main concern is that employees connecting Claude, MCP servers, or custom automations without security review can create unmanaged paths to source code, customer records, and production systems.

Below, we’ll discuss how those risks translate into enterprise shadow AI exposure, and how identity, scoped permissions, and runtime controls can support safer adoption.

Key Takeaways

• Anthropic cybersecurity spans defensive tools like Claude Code Security and controlled evaluations that test how autonomous models behave in cyber tasks.
• The enterprise risk extends beyond external threat actors. Internal shadow AI creates unmanaged paths from agents into company systems, data, and workflows.
• Traditional IAM and DLP remain necessary, but they don't fully govern delegated agent actions at the prompt, tool, and resource layer.
• Safe AI adoption requires identity, action-level permissions, runtime guardrails, and audit trails tied to each agent and each tool call.
• Willow is the agentic access platform that extends existing identity providers and includes an enterprise MCP gateway to govern agent actions.

The Dual Approach to Anthropic Cybersecurity

Anthropic cybersecurity has two sides: defensive product work that helps teams find and fix weaknesses, and frontier risk evaluation that tests how autonomous agents behave in cyber tasks.

The defensive side focuses on helping developers and security teams find and fix vulnerabilities. The evaluation side tests how capable autonomous agents become when they attempt realistic cyber tasks, including reconnaissance, vulnerability discovery, and multi-step execution.

Here are these two sides at a glance:

• Defensive tools: Claude Code Security, static analysis, code review, vulnerability discovery, and remediation.
• Cyber evaluations: controlled tests that measure model behavior in security tasks, including capture-the-flag style challenges and real-world simulations.
• Threat intelligence: reporting on malicious use patterns, adversary behavior, and how frontier models may change the cost of cyber operations.

But don’t just take it from us as Anthropic’s own writing also reflects this dual role. Their post on Claude Code Security frames agents as useful defensive tools, while their work on cybersecurity evaluations and the September 2026 threat intelligence report shows why autonomy, tool access, and internet access require careful control.

Defensive Capabilities and Claude Code Security

Claude Code Security focuses on AppSec acceleration instead of autonomous attack execution.

These tools can support:

• Static analysis: finding unsafe code patterns before they reach production.
• Vulnerability discovery: identifying flaws in application logic, dependencies, and configuration.
• Remediation: proposing fixes, creating patches, and helping developers move from finding to fixing.
• AppSec bottleneck reduction: helping security teams review more code without becoming the release blocker for every product team.

This way, a security team can use an agent to triage alerts, explain risky code, draft a patch, or summarize why a dependency creates exposure. For security operations teams, the defensive value also includes faster triage of Indicators of Compromise (IoCs), clearer reasoning about zero-day vulnerabilities, and safer analysis of kill chain automation patterns.

With that said, defensive agents need the same (if not more) rigor as human operators, plus controls built for delegation, tool calls, and runtime context.

Offensive Risk Evaluations and the Cyber Verification Program

Anthropic’s cybersecurity evaluations test how models behave when assigned cyber tasks under controlled conditions. They’re safety work designed to understand model capability, misuse potential, and the conditions under which autonomy changes cyber risk.

So far, the Anthropic team has described evaluation work that includes cyber benchmarks, controlled investigations, and programs such as Project Glass Wing. These efforts help determine whether a model can perform tasks like vulnerability discovery, exploit reasoning, or multi-step attack planning, especially when paired with tools and open internet access.

Internal agents also combine reasoning, tools, and access. The difference is that those agents may already sit close to sensitive systems, including source code, customer data, finance workflows, HR records, observability tools, and production infrastructure.

Spotlighting the Shadow AI Risk

Shadow AI happens when employees connect unapproved agents, MCP servers, browser extensions, skills, or vibe-coded apps to company systems without central review. This heightens the already present risks, extending it beyond the model to the path the agent now has into the business.

Consider these scenarios:

• A product manager might spin up a weekend app that reads Salesforce notes and summarizes renewal risk.
• An engineer might connect a local MCP server to GitHub, Jira, and a staging database.
• A finance analyst might wire an assistant into spreadsheets, invoices, and Slack. Each workflow may have a legitimate business goal, but the access layer is assembled outside standard review.

In doing so, Shadow AI creates three core problems:

• Unknown inventory: Security teams can't govern agents, MCP servers, or skills they can't see.
• Unclear delegation: A human may have legitimate access, but the agent’s permitted actions are often undefined.
• Weak accountability: A dashboard can show usage, but accountability requires identity, scope, decision logs, and audit trails tied to each action.

All of this makes endpoint governance essential because much of this starts on developer machines – local MCP configurations, API tokens, browser sessions, and external skills can create direct access paths that bypass central approval.

And when it comes to browser-based workflows, securing Claude in Chrome also means controlling what the agent can read, submit, or change inside authenticated applications.

Why Traditional IAM and DLP Are No Longer Enough

Don’t get us wrong – traditional IAM and DLP still matter, but they weren't designed to evaluate delegated agent actions in real time.

Prompt injection makes the problem even more apparent. An agent can receive a malicious instruction through a document, ticket, web page, repository issue, or tool response, leading it to believe that this injected instruction is part of its task – unless the system checks the request at runtime.

Closing these gaps means carrying identity and access controls through to the agent’s actual request. Before a tool call proceeds, the system needs to establish who is acting, whether the operation is permitted, and whether the live request meets policy.

The resulting audit record should make that decision traceable by:

• Establishing which user, agent, service account, or machine user is involved.
• Evaluating which operation the agent can perform against which resource and environment.
• Inspecting its target, parameters, data sensitivity, and compliance with policy before execution.
• Auditing who delegated the task, which agent acted, what tool was called, and what happened.

DLP supports this model by detecting sensitive data and applying protections such as PII redaction. At the same time, action-level controls address additional risks: a read-only tool, for example, might retrieve records outside the agent’s assigned scope or run queries that overload a system.

Discovery and enforcement therefore need to work together:

1. AI exposure management first identifies agents, MCP servers, skills, browser sessions, and local credentials that create access paths.
2. The agentic access layer then applies permissions and runtime policy to approved usage.

Finally, coverage matters throughout as well. A gateway can govern only the traffic routed through it, so direct database connections, cloud API calls, shell sessions, and unmanaged local tokens need controls at their respective execution points.

Together, these layers let teams govern agent activity across the paths it can actually take.

The Agentic Access Platform: Identity, Scope, and Audit

An agentic access platform governs how autonomous agents connect to enterprise tools, which actions they can perform, what data they can touch, and how each action is audited. If frontier agents can reason through cyber tasks, internal enterprise agents need more than visibility – they also need identity, scope, runtime enforcement, and accountability before they act.

Jira access shouldn't mean one broad permission, either. A good governed model separates actions and resources like so:

• Read tickets in selected projects.
• Create tickets in approved projects.
• Reassign tickets only within defined queues.
• Delete tickets only under restricted conditions, or not at all.
• Require approval before changes touch production workflows.

How Willow Can Help

Willow is the agentic access platform built for these types of issues. It plugs into and extends existing identity providers such as Okta, Entra, Active Directory, and JumpCloud. Existing groups become agent RBAC through SCIM, so teams can apply familiar identity structures to agents without replacing the IdP.

Willows also comes with MCP gateway support, giving enterprises a governed path for agent and tool traffic.

Moving from AI Chaos to Governed Enterprise Adoption

Enterprise AI adoption works when security teams can say yes with conditions instead of no by default. A workable operating model moves through seven steps:

1. Discover unmanaged agent activity because unknown access can't be governed. Surface local MCP servers, browser AI usage, external skills, and endpoint-level agent connections.
2. Assign ownership so every workflow has an accountable owner. Every agent, MCP server, skill, and toolkit needs a business owner and a technical owner.
3. Review the requested capability because approval only works when it matches the actual action. Approval should evaluate the target system, operation, environment, data sensitivity, and expected business use.
4. Publish approved self-serve paths so governed access is easier than shadow access. Employees need governed toolkits they can use without opening a ticket for every normal workflow.
5. Apply least privilege because agent actions carry different business impacts. Agent permissions should separate read, create, update, reassign, delete, export, and production-impacting actions.
6. Enforce at runtime because risk appears during the live tool call. Guardrails should check live tool calls instead of only the initial connection setup.
7. Stream audit evidence so investigations start with facts. SIEM integration and action-level agent monitoring should show identity, action, target, policy decision, and outcome.

Setting Clear Boundaries Before Agents Reach Production

Anthropic’s cybersecurity work brings the enterprise access question into focus: which agents can reach sensitive systems, and what limits govern their actions?

We recommend starting with workflows that can expose confidential data or change production systems. Establish ownership, restrict permissions to the task, and verify that runtime checks and audit records cover the actual execution path.

And if you want to use a ready-made solution without compromising on security, start free with Willow to easily connect your first agents and tools or explore our enterprise plans if you need IdP integration, action-level permissions, runtime guardrails, and SIEM log streaming.

Frequently Asked Questions

How should CISOs read Anthropic cybersecurity internal risk evaluations?

Anthropic cybersecurity evaluations should be read as an update on what frontier AI agents are capable of rather than direct predictions of an enterprise breach. Ultimately, their aim is to show how autonomous agents can reason through cyber tasks when they have tools, context, and access.

Inside a company, the parallel risk is an employee-connected agent that can read code, query Snowflake, update Jira, or call an internal API without scoped permissions, runtime checks, or an audit trail.

Is an MCP gateway enough to govern autonomous agents?

An MCP gateway is necessary when agents use MCP tools, but it isn't enough by itself if governance stops at connection routing. Instead, enterprise agent governance needs to evaluate the live action, target resource, environment, data sensitivity, and delegated authority before execution.

Direct database access, cloud APIs, shell paths, browser agents, and endpoint-local tokens also need controls because a gateway governs the traffic that actually traverses it.

How can enterprises find shadow AI without disrupting engineering workflows?

Enterprises should start with passive discovery of unmanaged MCP servers, browser agents, skills, local tokens, and vibe-coded apps, then route approved use into governed self-serve paths.

For example, Willow’s Radar view uses a Chrome extension and endpoint agent to surface unsanctioned AI activity and tie it to a real user. That lets teams choose a low-friction response, such as blocking risky use or re-connecting the workflow through governed access.