AI Coding Assistant Security: Securing Claude Code, Cursor, and the MCP Connections They Create

Most security policies treat Claude Code and Cursor the way they treat a browser: a surface for human activity, not an autonomous actor. That framing is wrong, and the gap it creates is significant.

Both tools operate as agentic systems. Claude Code can autonomously plan and execute multi-file refactoring, run shell commands, read environment variables, and interact with version control systems without a human approving each individual step. Cursor operates similarly, with deep IDE integration that gives it access to local file systems, connected services, and developer credentials stored in configuration files. When either tool connects to external services through the Model Context Protocol (MCP), it becomes a non-human identity (NHI) with real, executable authority across multiple systems simultaneously.

The NHI framing matters here. In modern enterprises, non-human identities already outnumber human identities by 25 to 50 times. Every AI coding assistant a developer runs with MCP connections active adds to that count. Unlike human identities, these agents do not trigger standard lifecycle events. They do not go through quarterly access reviews. They hold tokens that persist across sessions, and they operate continuously without the behavior patterns that traditional IAM tools use to detect anomalies.

Approving Claude Code as a developer tool does not mean security teams have approved its effective authority. Those are two different things.

One important scope note: developer-side AI coding tools that run locally on a developer's machine (including Claude Desktop or locally configured agent runtimes) fall outside the SaaS-connected agent layer that enterprise visibility platforms address today. The risk discussed in this article is most directly visible when those tools interact with cloud-connected SaaS applications and services through MCP, where runtime signals are available.

The Model Context Protocol was designed to give AI assistants a standardized way to connect to external tools and data sources. For developers, that is a productivity accelerator. For security teams, each new MCP connection is a blast radius expansion that happens outside their field of view.

When a developer configures Cursor with an MCP server for GitHub, another for a database query tool, and a third for a Slack integration, the assistant now holds access paths to source code, production data schemas, and internal communication channels. Each connection is a tool call surface. Each tool call is an action the agent can take autonomously, often without the developer explicitly approving the specific data accessed.

The MCP protocol is young, and its security model is still maturing. Because it is an open standard with many independently maintained server implementations, the quality and safety of any given server varies widely. The implication for security teams is not that the protocol is broken, but that each MCP server represents an independent trust decision that needs to be governed rather than assumed. At some enterprises, MCP server counts are doubling quarterly, meaning the inventory problem compounds as fast as the productivity gains do.

The action chaining risk compounds this further. An AI coding assistant does not take one action. It takes sequences of actions: read a file, query a schema, write a code block, commit to a repository, trigger a webhook. Each step in that chain extends the agent's reach. By the time a security team asks "what did that agent do?", the chain may span four systems and a dozen tool calls. Reviewing it retroactively from siloed logs is the definition of ghost chasing.

For a broader view of how unseen connections create exposure across the SaaS estate, see AI agent security.

Developers store credentials in places that are convenient for them and invisible to security teams. Environment files, IDE configuration directories, and shell profiles regularly contain API keys, OAuth tokens, and service account credentials. When an AI coding assistant reads those files as part of its context, it inherits access to everything those credentials authorize.

This is machine insider risk in its most direct form. The agent holds a bearer token. The system receiving that token does not verify who is actually holding it. It grants access based on possession alone. If that token provides write access to a production repository or read access to a database containing customer records, the agent's effective authority extends there, regardless of what the security policy says about the developer's approved access scope.

The maker mode parallel is instructive. In enterprise agent platforms, maker mode means an agent built with the creator's credentials runs at the creator's privilege level for every user who invokes it. In developer environments, the equivalent is an AI coding assistant running with the developer's stored credentials for every task it executes. A junior developer whose assistant inherits a senior engineer's stored tokens now has the senior engineer's effective authority, mediated through a probabilistic agent that security teams cannot observe.

Hardcoded secrets in agent configurations compound this risk. One enterprise security team discovered during an assessment that multiple developer AI configurations contained credentials embedded directly in MCP server setup files, credentials that had never been rotated and that granted access to production systems. The theoretical configuration said the tool was approved. The runtime truth was a persistent credential exposure that had been active for months.

Developers do not ask security for permission before adding an MCP server to their local Cursor or Claude Code configuration. They find a server that solves a problem, add it to their config file, and move on. Security teams have no visibility into that decision, no inventory of what was added, and no way to assess whether the server is sanctioned, maintained, or safe.

This is shadow MCP sprawl, and it is the developer-environment equivalent of shadow AI at the enterprise level. At one enterprise, the count of MCP connections in developer AI tools was doubling on a quarterly basis. No security team can govern what it cannot see, and most security teams cannot see any of this layer.

The black box problem is architectural. MCP servers can expose tools that are only visible at runtime, when the agent actually invokes them. A server's configuration file may list a set of capabilities, but additional tools can be present that only appear when the agent makes a live connection. Static review of a server's documentation or repository does not reveal the full tool surface. Only runtime observation does.

This creates a specific governance gap: security teams trying to assess MCP risk through configuration review are doing exactly the kind of ghost chasing that produces no actionable evidence. They can see that a server exists. They cannot see what tools it actually exposed, what data flowed through those tool calls, or whether the agent's actions were within any policy boundary.

A key boundary to understand: addressing shadow MCP servers requires an inventory and classification capability, not an inline proxy or MCP gateway. Obsidian is a control plane and identity graph that observes agent behavior and maps effective authority. It does not sit between the developer's tool and the MCP server as a network intermediary. This distinction matters for evaluating what "MCP security" actually means in practice.

For a broader view of how shadow AI and unsanctioned tools create organizational risk, see shadow AI security.

Security teams managing developer AI tools face a specific version of a universal problem: the tools they have were built for a world where humans took actions, not agents. The visibility gap this creates is not a configuration error. It is a structural mismatch.

Here is what a typical security team can see when Claude Code or Cursor is active in their environment:

What Security Teams Can SeeWhat Actually MattersThe tool is installed and approvedWhat MCP servers are connectedThe developer's identityThe agent's effective authority across those serversThat a commit was madeWhat data the agent read before making itThat a webhook firedWhat action chain triggered it and what data movedThat a token existsWhether that token is scoped correctly and still active

The right column is runtime truth. The left column is theoretical configuration. Every security program built on the left column is, by definition, ghost chasing.

The toxic combination that creates the highest risk in developer environments stacks three factors simultaneously: an AI coding assistant running with embedded developer credentials, connected to one or more unsanctioned MCP servers, with access to production systems or sensitive data repositories. Each factor alone is a medium-severity concern. Together, they represent a critical-priority exposure with a blast radius that spans source code, infrastructure credentials, and potentially customer data.

The AI agent visibility capability addresses this gap by mapping effective authority across agent connections, not just the configuration that approved tools appear to have.

The security program that can actually govern AI coding assistants starts with one requirement: a complete, live inventory of every agent, every MCP connection, and every credential that agent holds at runtime. Without that inventory, every other control is theoretical.

A mature AI coding assistant security posture covers four areas:

1. MCP Server Inventory and Classification

Every MCP server connected to every AI coding assistant in the environment, classified as sanctioned or unsanctioned, with the tool surface each server exposes documented at runtime, not from static configuration review.

2. Effective Authority Mapping

For each agent, a clear picture of what it can actually do inside every connected system. Not what the policy says it should be able to do. What the entitlements, tokens, and credentials it holds actually authorize at the moment of execution.

3. Action Chain Visibility

A record of what the agent did, in sequence, across which systems, with what data. This is the audit trail that makes incident response possible and that turns a ghost-chasing exercise into an evidence-based investigation.

4. Deterministic Guardrails for Probabilistic Agents

AI coding assistants are probabilistic by design. Their next action is not fully predictable from their configuration. Deterministic guardrails apply fixed, predictable enforcement rules to that probabilistic behavior, restricting what tool calls the agent can make, what data it can access, and what actions it can chain, regardless of what the agent's model decides to do next. This enforcement layer is a target state that depends on the runtime visibility in the first three areas being in place first.

The single pane of glass that security teams need covers all four areas in one place, correlated across platforms, without requiring a separate connector for every SaaS tool the agent touches. That is the standard. Most environments are nowhere near it.

For teams building toward this posture, a structured AI agent risk assessment provides a starting point.