Ask most security teams where their AI coding assistant sits in the risk register and you’ll get a shrug. It usually gets filed next to the editor, the linter and the theme pack, as a productivity tool. That’s a mistake, and the Claude Code extension incident on October 29 made the case better than any threat model could.
An assistant reads your code, learns how the project hangs together, talks to Git, runs commands, connects to other tools and, on some teams, helps push changes out the door. If it were a person, you’d call it a senior engineer with admin rights and no manager. If it were software, you’d call it a service account. The second framing is more useful, so it’s the one we’ll use here.
The question most people ask is whether the model can be tricked. That’s fair. But the question that decides how bad a bad day gets is simpler: if this assistant were compromised right now, what could it reach, change, steal or expose? That’s blast-radius modeling, and it’s much cheaper to do before something goes wrong than during.
Why an AI assistant counts as a privileged insider
“Insider” doesn’t mean malicious. It means an identity or system with enough access to do serious damage if someone else takes it over. Coding assistants meet that bar easily, because they sit where a lot of valuable things meet:
- source code and proprietary business logic
- Git identities and commit history
- developer workstations
- environment variables and local secrets
- cloud credentials and CLI sessions
- internal APIs and staging environments
- CI/CD pipelines
- package registries and artifact repositories
- production configuration and deployment paths
A typical desktop tool sees one thing. An assistant tends to see across projects. It knows how services connect, where secrets get referenced, which repository holds the sensitive logic and how a release actually ships. An attacker who gets that context doesn’t have to spend weeks mapping your organization. The assistant has already drawn the map.
What the Claude Code incident showed
On October 29, 2026, malicious versions of the Claude Code extension were available in Cursor’s marketplace for roughly 11 hours. Cursor says the builds weren’t developed by Anthropic. According to its disclosure, the tampered code collected the hostname, username, operating system, working directories, Git email and public IP address, along with the names of environment variables containing terms like KEY, TOKEN, SECRET, PASS, AWS or GCP. It also tried to add an attacker-controlled SSH key, turn on local SSH access, set up persistence and open a reverse SSH tunnel.
That reads less like a smash-and-grab for source code and more like reconnaissance plus a foothold. Look around, note where the credentials probably live, and leave a way back in. It’s how someone behaves when they’ve landed on a privileged identity and want to keep it.
What “blast radius” means for an assistant
Blast radius is the most damage an attacker can do after compromising one component. For an assistant, it isn’t limited to the files open in the IDE. It covers everything the assistant, its extensions, its connected tools and the workstation underneath can reach.
Five questions get you most of the way there:
- What can it read?
- What can it write or change?
- What credentials can it access, or work out?
- What systems can it connect to?
- What actions can it trigger?
Honest answers to those five are your real risk, whatever any vendor’s security page says.
Seven places to look
This is the walk-through we’d use with a platform or security team. Each area has a few things to ask, a warning sign to look for, and the control that matters most.
1. Source code
Start with the obvious asset. Which repositories can the assistant open? Can it read local workspaces, monorepos or mounted network drives? Does it keep context across projects, or across business units and customers? A compromised assistant with wide repository access exposes far more than one project: architecture, authentication flows, internal endpoints and the location of sensitive configuration.
Warning sign: unrestricted filesystem or repository access across many projects. Control: keep workspace scope tight, enforce repository-level boundaries and watch for unusual code-context collection.
2. Git identity and repository access
The assistant often inherits the developer’s Git identity and everything that identity is allowed to do. Can it read configuration, history, remotes and author details? Can it commit, push, open pull requests or change repository settings? Does it get anywhere near personal access tokens or SSH keys? In the wrong hands that means malicious commits, quiet backdoors and edits to CI configuration, all under a name your team trusts.
Warning sign: commit rights, or write access to protected branches. Control: short-lived credentials, scoped tokens, branch protection, mandatory review and alerts on unusual push behavior.
3. Environment variables and local secrets
Developer machines are full of them: API keys, database credentials, cloud tokens, signing keys, internal URLs. The malicious Claude Code builds collected variable names tied to credentials and cloud providers. Names alone are useful to an attacker, because they show where the secrets live and which systems are worth going after. Ask which variables the assistant can read, whether it separates names from values, whether it can open .env files, shell profiles or credential stores, whether it sends environment data off the machine, and whether your secrets sit in a managed secrets manager at all.
Warning sign: broad access to environment variables, dotfiles, credential files or shell history. Control: use a secrets manager, restrict file access, redact values and block extensions that collect credential metadata with no clear reason.
4. Cloud credentials and infrastructure
Plenty of developers stay logged in to cloud CLIs all day. An assistant on the same machine may be able to run those tools or read their configuration. Can it execute AWS, Azure or GCP commands? Reach Kubernetes contexts or Terraform state? Read cloud metadata or assume roles? If so, a compromise can mean enumerating resources, changing infrastructure, opening storage and pivoting toward production.
Warning sign: access to cloud credentials, infrastructure state or privileged roles. Control: scoped, short-lived credentials, separate developer and production identities, MFA or approval for sensitive actions, and logging for all of it.
5. Internal APIs and services
Assistants increasingly plug into internal APIs, documentation, ticketing, observability tools and knowledge bases. Which services can yours reach, and with whose identity? Can it query production data or customer records? Are API tokens stored locally? Can it call arbitrary destinations? Every connection is a bridge between the developer workstation and something sensitive.
Warning sign: broad network access, unrestricted outbound requests or access to high-value internal APIs. Control: egress controls, allow-listed destinations, scoped tokens and explicit approval for new integrations.
6. CI/CD access and deployment paths
This is often the highest-impact area. If an assistant can edit pipeline files, read CI secrets, trigger builds or touch deployments, a developer laptop becomes a route into production. A malicious change to a workflow file can be worse than a direct exploit, because it rides along with every future build. Can the assistant modify GitHub Actions, GitLab CI or Jenkins files? Reach runner credentials? Alter build scripts, dependency manifests or publishing steps? Are deployment approvals actually enforced?
Warning sign: write access to CI/CD configuration, deployment scripts, dependency manifests or release workflows. Control: protect pipeline files, require review for workflow changes, isolate CI secrets and verify build provenance.
7. Production secrets and downstream systems
Even with no direct production access, an assistant can get there sideways, through credentials, configuration files, internal docs or ordinary developer workflows. Can it see staging or production secrets? Read configuration that reveals production architecture? Could a compromised workstation reach production without another control in the way?
Warning sign: shared credentials, overly broad network access or weak separation between development and production. Control: environment separation, least privilege, just-in-time access and approval gates for anything that affects production.
A scorecard you can use this week
Score each assistant, extension or agent integration across these dimensions. You don’t need a perfect number. You need the risk to be visible before an attacker makes it visible for you.
| Dimension | Lower risk | Medium risk | Higher risk |
|---|---|---|---|
| Code access | One approved workspace | Multiple repositories | Broad filesystem or monorepo access |
| Git access | Read-only | Can create branches and PRs | Can push, merge or change repo settings |
| Secrets | No secret access | Names and metadata | Values, .env files or credential stores |
| Cloud access | None | Scoped read-only role | Privileged CLI access or role assumption |
| Internal APIs | No access | A few approved APIs | Broad internal network access |
| CI/CD | No access | Read-only pipeline visibility | Can modify workflows or trigger deployments |
| Production impact | None | Indirect visibility | Direct deployment or production access |
| Network behavior | Approved destinations only | Limited external calls | Arbitrary outbound communication |
| Persistence | None | Background process | SSH keys, launch agents, scheduled tasks |
Treat the assistant like a service account
Once you’ve modeled the assistant as a privileged insider, the controls mostly write themselves. A well-run service account has an owner, least-privilege permissions, scoped credentials, logging, anomaly detection, rotation and a way to revoke it. Assistants deserve the same. In practice it comes down to five things.
- Identity. Know which assistant, extension, version, publisher and integration is running. A marketplace name isn’t enough.
- Permissions. Write down what it can read, write, execute and reach, and review that whenever a new version or integration shows up.
- Logging. Capture extension installs, version changes, network activity, command execution, credential access and policy decisions. Without logs, incident response is guesswork.
- Revocation. Be able to disable the assistant, pull its tokens and isolate affected endpoints quickly.
- Approval. Put a human in front of high-risk actions, such as changing CI/CD files, touching production secrets, installing new extensions or connecting to new external services.
How PexLens helps reduce blast radius
PexLens is built to give security teams visibility and control over what enters developer and AI environments before those components become part of an incident. Catching a malicious package after the fact is part of the job. The bigger value is understanding and limiting what AI tooling can do before anyone has a reason to exploit it.
Know what’s coming in
PexLens inspects packages, extensions, plugins, dependencies and AI-related components for risk signals before they spread through the organization. That covers publisher and provenance consistency, version changes, unexpected dependencies, suspicious code patterns, install-time and runtime behavior, network activity, permission expansion and persistence mechanisms. In blast-radius terms, it answers the first question: what is this component, and what can it actually do?
Turn findings into policy
A finding only matters if something happens next. PexLens findings can feed developer-endpoint policy directly:
| PexLens finding | Policy action |
|---|---|
| Malicious or high-confidence compromise indicators | Block installation and alert security |
| Suspicious behavior, unknown publisher or unverified provenance | Quarantine pending review |
| Low-risk, approved component with normal behavior | Allow |
| New version, new permission or unusual network behavior | Allow with monitoring |
| High-impact component or sensitive environment access | Require approval before deployment |
That gives security teams something closer to a control plane than a pile of alerts.
Catch drift before it becomes access
The riskiest compromised assistant doesn’t look like an attacker’s tool at first. It looks like a familiar extension that picks up new abilities in an update. PexLens can flag when an extension or package introduces new capabilities, dependencies, network destinations or persistence behavior. In the Claude Code case the behaviors were reconnaissance, SSH-key insertion, persistence and tunneling. A platform that evaluates those signals can help stop the component before it turns into an active foothold.
Adopt AI tools without blind trust
PexLens lets organizations adopt AI coding tools without adopting blind trust. Security teams can set policies like these:
- Allow only approved publishers and extension families.
- Require review for new versions with material behavior changes.
- Block components that ask for credential or system access they don’t need.
- Monitor approved tools for shifts in network or data-access behavior.
- Quarantine anything that attempts persistence or unauthorized system changes.
- Require approval before high-risk AI integrations are switched on for developers.
Engineering keeps moving, and security gets a way to step in when the risk is real.
What good looks like
A mature team can answer these quickly:
- Which AI assistants and extensions are installed across developer endpoints?
- Which versions are approved, quarantined or blocked?
- What permissions and integrations does each one have?
- Which developer identities, repositories, cloud accounts and internal APIs would be affected if it were compromised?
- What evidence exists if an extension behaves suspiciously?
- How fast can we revoke access and contain an incident?
If getting those answers means chasing three teams and a spreadsheet, your blast radius is probably bigger than you think.
The bottom line
AI coding assistants are useful because they have access, and that same access makes them a privileged insider risk. A compromised one isn’t a broken productivity tool. It’s a compromised identity with a possible path to source code, Git activity, secrets, cloud infrastructure, internal APIs, CI/CD systems and production.
PexLens helps teams model and contain that blast radius by verifying what enters the developer environment, catching behavioral drift and turning findings into policy: block, quarantine, allow with monitoring, or require approval.
The teams that do well with AI-assisted engineering won’t be the ones that assumed their tools were safe. They’ll be the ones that know exactly what those tools can reach, and have a response ready when that reach becomes a problem.
Reference
Cursor’s disclosure of the malicious Claude Code extension incident: cursor.com/blog/claude-code-extension-security-notice
