Josh Epstein

President and Chief Business Officer

Picture this: Your developers started using Cursor last month. Productivity shot up 40%. Pull requests doubled. The platform team started planning a company-wide rollout.

Then your security team stepped in.

Not because they&#39;re innovation killers. Not because they don&#39;t understand the value. Because when AI agents run on local laptops with unrestricted access to your private repositories, your APIs, and the open internet, you&#39;ve created a governance nightmare that no CISO can defend.

So the tools get blocked. Innovation stalls and developers go back to fighting their local environments while your competitors figure out how to ship faster with AI.

There&#39;s a better way.

<h2>Why enterprise security teams are blocking AI coding tools</h2>

<a href="https://coder.com/docs/ai-coder">AI coding assistants</a> like <a href="https://registry.coder.com/modules/coder/cursor">Cursor</a>, <a href="https://registry.coder.com/modules/coder/claude-code">Claude Code</a>, and <a href="https://coder.com/blog/github-copilot-cli-now-runs-natively-in-coder-workspaces">GitHub Copilot</a> Workspace represent a fundamental shift in how software gets built. We’re way past autocomplete. Modern AI assistants are autonomous agents that read codebases, call APIs, execute commands, and make architectural decisions.

Your developers need them. Your security team can&#39;t allow them. Thus an unstoppable force met an immovable object, at least on local machines.

Why do security teams block AI coding tools? It’s because they present what <a href="https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/">Simon Willison refers to as the lethal trifecta for AI agents</a>. 

First, they need access to private data. Real work requires context from your proprietary codebases, internal documentation, and production systems. No sandbox. No abstractions. Direct access.

Second, they must communicate externally. These agents call LLM APIs, pull dependencies, query documentation sites, and interact with development tools. They need internet access to function.

Third, they cannot access untrusted context. Prompt injection attacks, poisoned dependencies, and hallucinated suggestions mean agents need boundaries. Without isolation, a compromised agent can exfiltrate your entire codebase.

On a local laptop, you can&#39;t solve all three simultaneously. You either give agents the access they need and lose control, or you lock them down so tightly they become useless.

Enterprise security teams are choosing control. What we’re seeing in our conversations with platform engineering leaders across <a href="https://coder.com/solutions/financial-services">financial services</a>, healthcare, and <a href="https://coder.com/solutions/tech-innovators">technology</a> companies is that AI coding tools are being blocked at an accelerating rate—not because they don&#39;t work, but because local execution is fundamentally ungovernable.

<h2>The hidden costs of uncontrolled AI agents in development</h2>

When AI agents run on local developer machines, enterprises lose three things they can&#39;t afford to lose.

<h3>Zero visibility into AI agent activity</h3>

No audit trail means no answers. <a href="https://coder.com/blog/the-first-ai-orchestrated-cyberattack-just-happened-no-one-was-prepared">When something goes wrong</a>, you need to know exactly what the agent did, which prompts triggered which actions, what data was accessed, and where the output went.

On a local machine, you get none of that. For regulated industries, including financial services, healthcare, and government agencies, this isn&#39;t just inconvenient. It&#39;s disqualifying. Compliance teams can&#39;t sign off on tools they can&#39;t audit.

<h3>No control over AI agent permissions and access</h3>

Developers are trusted. AI agents aren&#39;t. Not yet.

When an agent has the same level of access as the developer running it—full repository access, production credentials, unrestricted network access—the blast radius of a mistake or a compromised prompt is enormous.

You need boundaries. Network policies that define exactly which external services an agent can reach. Resource limits that prevent runaway compute costs. Access controls that separate human permissions from agent permissions.

None of this exists when agents run locally.

<h3>Unmanaged compute costs and resource constraints</h3>

AI agents are expensive to run. Not just API costs—compute costs. Modern agents execute tasks in parallel, spin up multiple environments, run extensive test suites, and consume significant CPU and memory.

On developer laptops, this manifests as maxed-out machines, poor performance, and frustrated engineers. At scale, it becomes an infrastructure problem with no good solution. You can&#39;t allocate GPU resources to laptops. You can&#39;t bin-pack multiple agents onto optimized instances. You can&#39;t measure or control spend.

One enterprise customer we spoke with estimated they were spending $25 million annually on shadow VMs that developers created just to circumvent laptop performance limitations. And that was before AI agents entered the picture.

<h2>Remote development infrastructure is becoming mandatory for AI</h2>

The more agent-driven your workflow becomes, the less viable local development is. Not just for security. For performance, cost, and developer experience.

This isn&#39;t a controversial take anymore. GitHub is building Copilot Workspace as a cloud-native experience. Anthropic assumes Claude Code runs in remote environments. Even Cursor&#39;s most advanced features work best with cloud compute. The shift is happening whether enterprises are ready or not.

<a href="https://coder.com/blog/inside-ai-adoption-lessons-from-enterprise-software-development-teams">Enterprises need something different.</a> Something self-hosted. Something that provides the governance and observability that security teams demand, while delivering the performance and experience that developers expect.

<h2>How Coder enables secure, governed AI development at scale</h2>

Coder provides <a href="https://coder.com/cde/premium">self-hosted development environments</a> that let AI coding tools run safely at enterprise scale. Not by replacing developer tools. By enabling them.

When Cursor runs in a Coder workspace instead of on a laptop, this is what you can expect:

<h3>Self-hosted infrastructure you control and audit</h3>

Agents run on infrastructure you control. Your cloud. Your data center. Your GPU fabric. Most importantly, your access controls and policies.

Unlike <a href="https://coder.com/cde/compare">SaaS development platforms</a>, Coder runs entirely in your infrastructure. This matters for regulated industries that can&#39;t send proprietary code to third-party platforms, for <a href="https://coder.com/solutions/government">government contractors with air-gapped requirements</a>, and for any enterprise that takes data sovereignty seriously.

When auditors ask where your development happens and how you govern it, you can point to infrastructure you control, with policies you define, running in environments you monitor.

<h3>Standardized, reproducible environments for every developer</h3>

With Coder Workspaces, you define development environments as code using Terraform. Every developer gets the same tools, the same access controls, the same security policies.

When AI agents run in these standardized environments, you eliminate configuration drift. You know exactly what each agent has access to because you defined it. You can update security policies centrally and have them apply to every workspace instantly.

<h3>Enterprise-grade compute without laptop limitations</h3>

AI agents need serious compute. Coder Workspaces run on cloud or on-premises infrastructure that can scale to meet demand.

Need GPU access for AI workloads? Provision it. Need to run multiple agents in parallel? Bin-pack them efficiently. Need to control costs? Set resource limits and track usage.

Your developers get powerful development environments. Your platform team gets visibility into resource consumption and the ability to optimize spend.

<h3>Integration with your existing security stack</h3>

Coder Workspaces <a href="https://registry.coder.com/">integrate with the tools you already use</a>. SSO for authentication. Your existing VPN and network policies. Your monitoring and observability stack. Your secret management system.

You don&#39;t need to rebuild your security posture around a new platform. You extend what you already have to cover development environments, including the AI tools running inside them.

<h3>What&#39;s next: Deeper AI governance and observability</h3>

Today, Coder Workspaces provides the infrastructure foundation for secure AI development. Tomorrow, we&#39;re building capabilities specifically designed for the AI agent era.

Centralized observability for every AI tool interaction. Network-level boundaries that let you define exactly which external services agents can reach. Complete audit trails that answer the questions compliance teams actually ask. These capabilities are coming to give enterprises the granular control and visibility that AI governance demands, built directly into the infrastructure layer where it belongs.

Dec. 9-11 Coder introduces the context and guardrails that enterprises need to get AI out of the lab: secure, scalable, and self-hosted.

<h2>Tool-agnostic infrastructure for any AI coding assistant</h2>

Coder doesn&#39;t care which AI tools you use. Cursor, Claude Code, Copilot, your own custom agents—they all work. Your developers keep their tools. They just run in environments that are standardized, secured, and centrally managed.

This matters because the developer experience tooling landscape is changing rapidly. Betting on a single vendor means betting they&#39;ll win the long-term interface battle. Coder doesn&#39;t require that bet.

You get infrastructure that works with any developer tool, any AI agent, and any workflow—while maintaining the governance and security posture your enterprise requires.

<h2>Moving from blocked AI tools to governed AI development</h2>

Here&#39;s what we&#39;re seeing across our customer base: enterprises that try to govern AI coding tools at the laptop level fail. Policies don&#39;t scale. Enforcement doesn&#39;t work. Shadow IT proliferates.

Enterprises that shift AI development to remote, governed infrastructure succeed. Developers get better tools. Security teams get visibility and control. Platform teams get infrastructure they can actually manage.

The shift is coming. Security teams are already blocking local AI agent usage. Developers are already demanding better solutions. The question isn&#39;t whether your development infrastructure needs to evolve—it&#39;s whether you&#39;ll lead the change or be forced into it reactively.

Spin up at speed. Control at scale.

That&#39;s what Coder enables. <a href="https://coder.com/cde/premium">Self-hosted development infrastructure</a> where your developers can use the AI tools they need, with the governance and security your enterprise demands.

This is why… 

Every Cursor needs a Coder.

FYI, this was stolen with permission from one of our customers who told us they were denied access to Cursor until Coder was in production.

When AI agents run on local laptops with unrestricted access to your private repositories, your APIs, and the open internet, you've created a governance nightmare that no CISO can defend.

Every Cursor / Claude / Gemini / Copilot / Devin needs a Coder

Every Cursor Needs a Coder: Unblocking AI Coding Tools in the Enterprise

Chinese state-sponsored hackers just executed the first large-scale cyberattack run primarily by AI. <a href="https://www.anthropic.com/news/disrupting-AI-espionage">Anthropic disclosed it yesterday.</a> 30 organizations compromised. Major <a href="https://coder.com/solutions/tech-innovators">tech companies</a>, <a href="https://coder.com/solutions/financial-services">financial institutions</a>, <a href="https://coder.com/solutions/government">government agencies</a>.

The AI handled 80-90% of the work autonomously. Reconnaissance, exploitation, data exfiltration. Human operators intervened only 4-6 times per campaign for critical decisions. The AI made thousands of requests per second—attack speed impossible for human teams to match.

This isn&#39;t a proof of concept. This was a successful intelligence collection operation against confirmed high-value targets. It happened in September. We&#39;re learning about it now because Anthropic&#39;s detection systems flagged the suspicious activity, launched an investigation, and has spent the past weeks mapping the full scope, banning accounts, and notifying affected entities.

Your developers are using AI coding tools right now. Same capabilities. But do you have the detection and governance infrastructure that let Anthropic identify and disrupt this campaign?

<h2>From AI-assisted to AI-orchestrated: Why your AI risk profile just changed</h2>

Cybersecurity professionals have tracked AI in cyberattacks for years, but GTG-1002 represents a categorical shift in threat sophistication that fundamentally changes the risk calculations every CISO makes.

The attack succeeded not by compromising Anthropic&#39;s infrastructure but by manipulating Claude Code itself into becoming the attack platform. The threat actors jailbroke the AI by breaking attacks into small, seemingly innocent tasks and convincing Claude it was performing legitimate security testing for a cybersecurity firm.

Here’s how it just changed your AI risk profile:

Speed eliminates the detection window. Attackers achieved thousands of requests per second. Your SOC monitors for patterns that take hours or days. These patterns took minutes. Traditional detection failed.

Scale makes containment impossible. 30 simultaneous targets. Multiple active sessions per target. Your incident response playbook assumes human-speed operations. This moved faster than your runbooks.

Attribution gets harder. The attack used legitimate AI services through compromised credentials. Your logs show normal developer activity patterns. Separating legitimate from malicious usage becomes forensic archaeology.

Liability expands. Regulators will ask what controls you had in place. Insurers will revise coverage terms. Board members will want to understand your AI governance posture. &quot;We didn&#39;t know this was possible&quot; stops working as a defense.

<h2>How the attack succeeded</h2>

GTG-1002 worked because it exploited the gaps between where your security controls operate and where AI actually executes. Understanding the attack framework shows you exactly where to build defenses and why generic security policies won&#39;t stop the next one:

Phase 1: Framework development and jailbreaking

Attackers built an automated attack framework that used Claude Code as its execution engine. They jailbroke the AI through role-playing—convincing it that it was an employee of a legitimate cybersecurity firm performing authorized security testing. They decomposed malicious operations into isolated tasks that appeared benign when Claude evaluated them individually.

Phase 2: Autonomous reconnaissance

Claude inspected target organizations&#39; systems and infrastructure, identifying high-value databases in a fraction of the time a human team would require. It reported findings back to human operators in summarized form.

Phase 3: Exploitation and lateral movement

Claude identified security vulnerabilities, researched and wrote exploit code, tested attacks, and moved laterally through compromised systems. Human operators approved phase transitions but didn&#39;t execute the technical work.

Phase 4: Intelligence extraction

The framework used Claude to harvest credentials, extract large volumes of private data, categorize information by intelligence value, identify high-privilege accounts, and create backdoors—all with minimal human supervision.

Phase 5: Documentation for persistence

Claude produced comprehensive documentation of the attack, creating organized files of stolen credentials and system analysis to assist in planning the next stage of operations.

The successful intrusions targeted major technology corporations, financial institutions, chemical manufacturers, and government agencies. Active intelligence collection at machine speed against highly secure organizations.

<h2>The governance gap that enabled the attack (and how to close it)</h2>

This attack succeeded because Claude Code was manipulated into becoming the attack platform itself. The attackers didn&#39;t need to steal credentials first. They used the AI agent&#39;s legitimate capabilities: access to tools via MCP, ability to write and execute code, network access to inspect systems, autonomous operation over extended periods.

Think about your environment. Your developers are using similar AI coding agents right now. Claude Code, GitHub Copilot, Cursor. These agents have:

<ul>
<li>Tool access via MCP to interact with systems, databases, APIs </li>
<li>Code execution capabilities to write exploits, scripts, automation </li>
<li>Network visibility to discover and analyze infrastructure </li>
<li>Autonomous operation to chain tasks together with minimal oversight</li>
</ul>

The same capabilities that make AI agents productive for your developers made them effective for attackers. This wasn&#39;t about compromised credentials or insider access. This was about weaponizing legitimate developer tooling.

Your security model assumes humans use these tools, but AI agents don&#39;t work that way. They operate at machine speed, making thousands of decisions per hour and running wherever developers run them. A human was still in the loop in this attack, but we&#39;re getting closer and closer to fully autonomous cyber attacks. 

These are the governance gaps that exist in most organizations right now:

No visibility into AI usage. Developers use personal API keys. You can&#39;t see what they&#39;re asking AI to do. What code they&#39;re generating. What data they&#39;re sharing. What systems they&#39;re querying. Do you know which employees are using AI coding tools?

No centralized access control. Each developer has direct access to AI providers. You can&#39;t revoke access instantly. Can&#39;t enforce usage policies. Can&#39;t attribute actions to specific users during incident response. What controls exist between your developers and AI providers?

No pattern detection. Your SIEM ingests logs from applications, not from AI interactions. Thousands of AI queries per second? You wouldn&#39;t see it. Attempted data exfiltration through AI? Not in your logs. If an AI-driven attack targeted your organization, how would you detect it? What is your incident response plan for AI-related security events?

No audit trail. Incident occurs. You need to understand scope. Your forensics team has developer workstation logs. Application logs. Network traffic. What they don&#39;t have: what the AI was asked to do. What it had access to. How the compromise progressed. Can you prove no sensitive data was shared with external AI providers? Can you produce an audit trail of AI interactions during the relevant time period?

No policy enforcement. AI agents access any tools through open protocols like MCP. No approval workflow. No restrictions based on role or sensitivity. No separation of duties. How do you ensure AI agents only access systems they&#39;re authorized for?

This isn&#39;t a failure of existing security controls. It&#39;s a gap between where your controls operate and where the risk now exists. 

These questions are coming. From your board. From auditors. From regulators. And your current answers are probably inadequate. Not because you lack security expertise, but because the architecture to answer these questions confidently doesn&#39;t exist in most organizations yet.

<h2>What governance actually means for AI development</h2>

Effective governance isn&#39;t just about restrictions or blocked adoption. It&#39;s about architecture that gives you the visibility and control your role requires while enabling developers to work productively. 

These are the governance standards you should be implementing against an AI-orchestrated attack: 

Centralized authentication and identity 

Every AI interaction must tie to an authenticated user. No personal API keys. Session-based access you control centrally. Instant revocation when needed. Clean attribution for every request.

When incidents occur, you know exactly who was using AI, when, for what purpose. Your forensics timeline is complete.

Real-time policy enforcement 

A governance layer to intercept every AI request before it reaches the provider. This analyzes patterns. Blocks suspicious activity automatically. Escalates anomalies to your SOC.

Thousands of rapid queries? Blocked. Attempted data exfiltration? Stopped. Exploit code generation? Flagged. Your existing security policies extend to AI usage.

Comprehensive audit logging

Every prompt used must be logged. Every response captured. Every tool invoked. Full context preserved. Searchable. Exportable to your SIEM.

Compliance audits become straightforward. Incident investigation becomes possible. Regulatory reporting becomes defensible.

Tool and resource access controls

AI agents access only approved tools. Centrally managed. Role-based restrictions. Network segmentation. Explicit allowlisting.

Your existing access control models extend to AI. Least privilege applies. Separation of duties enforces.

Cost as security signal - Usage quotas create security tripwires. Sustained high-volume activity exhausts limits fast. Forces manual review before continuing.

Anomalous spending patterns indicate compromise. Your FinOps data becomes security telemetry.

<h2>Why human developers and AI agents should have different privileges</h2>

The governance layer is necessary. Not sufficient.Your developers have privileges your AI agents shouldn&#39;t.

Separate identities for agents 

Human developers authenticate as themselves. Full access to their authorized resources. AI agents need their own service accounts. Limited scope. Revocable independently.

In the GTG-1002 attack, Claude operated with the same access level as the compromised developer accounts. Full network access. All tools available. No differentiation between human and agent operations.

Your architecture should enforce separation.

Least privilege by default 

An AI agent needs to analyze code? Grant read access to repositories. Nothing more. Needs to run tests? Access test infrastructure only. Production stays locked.

Human developers need production access for debugging. AI agents don&#39;t. Human developers need to approve deployments. AI agents shouldn&#39;t. Human developers access customer data with proper controls. AI agents never should.

Different actors. Different privileges. Different risk profiles.

Scoped network access 

Human developer environment: access to internal services, databases, API endpoints they need for work.

AI agent environment: access to nothing by default. Explicit allowlist for each required resource. No lateral movement. No service discovery. No internal reconnaissance.

The attack succeeded because Claude could enumerate internal services freely. Your agents shouldn&#39;t have that capability.

Isolated execution environments 

Run AI agents in dedicated compute within your security perimeter:

<ul>
<li>Operate in your VPC or on-premises </li>
<li>Default-deny network posture </li>
<li>Ephemeral compute that destroys after use </li>
<li>Audit trails that persist after environment destruction </li>
<li>Separate from human development environments</li>
</ul>

Same isolation principles you apply to production workloads. Now applied to AI operations. But with agent-specific restrictions humans don&#39;t need.

Why this matters for incident response 

Compromise happens. Human account compromised: revoke access, investigate scope, remediate. Standard playbook.

AI agent compromised: revoke agent service account. Human account remains functional. Developer keeps working. Blast radius contained.

Without separation, you can&#39;t contain without disrupting legitimate work. With separation, you can isolate and investigate while operations continue.

<h2>The conversation with your board</h2>

Every business leader should be looking at this latest attack and asking themselves what they can do to get ahead of the next one. Use this framework to communicate with your peers on how and why you plan to address future attacks like this:

Risk: AI-driven attacks move faster than human-speed incident response. Traditional detection fails. Attackers can now achieve nation-state capabilities with smaller teams.

Liability: Regulators will ask what controls existed. Insurance policies will scrutinize AI governance. Legal exposure grows with each unmanaged AI deployment.

Business impact: Developers need AI to stay competitive. Blocking it creates shadow IT. Allowing unmanaged usage creates unacceptable risk. The question isn&#39;t whether to use AI—it&#39;s how to govern it.

Investment required: Governance infrastructure. Not heroic effort. Centralized authentication, policy enforcement, audit logging. Same patterns you applied to cloud adoption. Now applied to AI.

Timeline: The threat exists today. Your developers use AI today. The gap exists today. Closing it requires prioritization.

Board members understand this framing. They&#39;ve lived through cloud adoption, mobile device management, shadow IT crises. This follows the same pattern. Just faster.

<h2>Coder was built for this moment</h2>

We build governance infrastructure for AI in development environments. Centralized authentication, real-time policy enforcement, comprehensive audit logging, tool access controls, cost governance.

Our platform runs AI agents in isolated, governed workspaces within your infrastructure. Same security model protecting production development work. Now applied to AI operations.

More important than our product: enterprises must treat AI deployment as a security architecture problem. Not a developer productivity tool.

<h2>This is the baseline, not the peak</h2>

The GTG-1002 campaign represents current capability. Not theoretical risk. Not future threat. What&#39;s possible today.

And this is the least dangerous AI attack capability will ever be.

Next year&#39;s AI models will be more capable. More autonomous. Faster. Better at reasoning through complex multi-step operations. The defensive challenge grows with each model release.

The attackers who executed this campaign were sophisticated. Well-resourced. Nation-state backed. But Anthropic&#39;s report makes the key point: these techniques are now accessible to less experienced, less resourced groups.

The barrier to entry just dropped. Permanently.

<h2>Governing your AI coworkers</h2>

Your developers already work alongside AI. Claude Code, Copilot, Cursor. These aren&#39;t tools anymore. They&#39;re collaborators that generate code, suggest architectures, automate tasks.

Effective collaborators require governance. Not restriction. Not prohibition. Systematic controls that match their capabilities and risk profile.

You govern human developers through identity management, access controls, audit logging, network segmentation. AI agents need the same systematic approach. Different implementation. Same principles.

The organizations that treat AI governance as an architecture problem will maintain security posture. The organizations that treat it as a policy problem will accumulate risk.

What the first AI-orchestrated cyberattack means for CISOs. Your board will have questions.

AI-native Development

Secure Environments for 2,500+ Developers

Josh Epstein

Explore the latest from Josh

Every Cursor Needs a Coder: Unblocking AI Coding Tools in the Enterprise

The First AI-Orchestrated Cyberattack Just Happened. Your Board Will Have Questions.

Related content

Using Claude Code with Coder Workspaces

Introducing Coder Agents

Self-Hosted Doesn’t Always Mean What It Implies