AI coding agent security: Claude Code, Cursor, Codex and Copilot

It covers tool calls, inherited credentials, the MCP servers configured beside the agent, and the evidence left behind.

Coding agents deserve their own treatment because they are the most privileged developer tool most organisations have ever installed. They run with the developer's rights, in the developer's home directory, with a shell.

Why does coding agent security matter now?

Coding agents are not an emerging category. They are the main way a large share of developers now work. In the 2026 Stack Overflow survey, 73% of respondents used coding assistants and agents daily, coding assistants and agents were the top AI use case at 66%, and 31% of daily users spent four or more hours a day with them, with Claude Code at 66% and GitHub Copilot at 59% (Stack Overflow Developer Survey 2026).

That survey also found 20% of respondents use AI for deploying or operating production systems, and only 48% trust AI output when they can easily verify it (Stack Overflow 2026). The tools are in the release path before the trust is, which is precisely the gap controls exist to close.

The attacks are specific to this environment. A Microsoft-led challenge with 208,095 human-written attack prompts found injected instructions transferred across domains, reaching 37% success on coding tasks and 28% to 45% on file management (LLMail-Inject, arXiv:2506.09956). An injection in a README, an issue or a test fixture is not an abstract risk for a tool that reads all three.

Tool-level attacks land on the same surface. The first public tool poisoning disclosure used a malicious MCP server to make Cursor read ~/.ssh/id_rsa and its own configuration, then exfiltrate both (Invariant Labs). A malicious public GitHub issue was used to steer an agent into leaking private repository data through a pull request, using the official GitHub MCP server, and the write-up notes it was not a server code bug, so no patch fixes it (Invariant Labs).

Model improvements show up directly in this environment. When Anthropic resampled real employee Claude Code sessions where an earlier model had done something destructive, Claude Opus 5.5 repeated the destructive action in 21% of them, against 42% for Opus 5 and 49% for Opus 4.8, and it asked for permission instead in 35% of cases (Claude Opus 5.5 System Card). Version upgrades are worth doing and 21% is not zero, which is what the replacement review gate is for.

The credential picture underneath is the same everywhere. In a survey of 5,200 open-source MCP servers, 88% required credentials, 53% relied on long-lived static secrets and 79% passed keys through environment variables (Astrix). On a developer laptop, that is a config file in a project directory.

How exposed is your setup? Compass gives you a structured read on your coding agent exposure: compass.alyria.ai.

How is a coding agent different from an autocomplete tool or a CI pipeline?

The differences explain why existing controls miss it. Autocomplete never left the editor. CI runs code the team wrote, in a container the team controls. A coding agent runs on the laptop with the developer's identity and chooses commands from a menu that changes per project.

Dimension	Autocomplete	Chat assistant	Coding agent with tools	CI pipeline
Execution	None	None	Shell, file writes, package installs	Build and test scripts
Data in reach	The open file	Selected context	Home directory, repositories, credentials	Repository plus injected secrets
Identity	The developer	The developer	The developer, via inherited tokens	Pipeline service account
Capability source	Fixed model	Fixed model	CLI flags plus project MCP config	Committed configuration
Change detection	Model updates	Model updates	New MCP server, new tool, new prompt	Commit history
Audit trail	Editor telemetry	Chat logs	Session transcripts, tool calls, shell history	Build logs
Typical incident	Wrong suggestion	Leaked snippet	Credential read, hostile push, package install	Secret in artefact

In practice: The interesting difference is the middle column. A coding agent's capability set is assembled per project, per machine, by whoever needed it that week.

What are the main risks of coding agent security?

The risk list is short, and every item has a version in the OWASP agentic taxonomy. OWASP's Top 10 for Agentic Applications 2026 puts goal hijack first for a reason.

Secrets within easy reach

An agent that can run cat can read anything the developer can read. SSH keys, ~/.aws/credentials, .npmrc, .env files from other projects, browser session stores and the agent's own MCP configuration are all two tool calls away. The Cursor disclosure is the canonical example, and it required no vulnerability in the developer's workflow.

Untrusted content inside the repository

Repository content is untrusted input. A README from a dependency, an issue body, a generated test fixture, a vendored documentation file, a lockfile comment. Injected instructions in any of these reach the model as content, and the model does not reliably separate content from instruction.

Project-level MCP configuration

Opening a repository can enable servers the developer never chose. That makes the config file a supply chain artefact with the same trust properties as a build script, except it is usually not reviewed, not pinned and sometimes fetched from a URL.

Shell access and egress

Command execution plus unrestricted network access is the combination that turns a hijack into an incident. An agent that can install a package from any registry can also be steered into installing one the attacker published.

Delegated credentials

Most agents authenticate with the developer's own token. Every action is then attributable to a person who may not have taken it, and the token's scope is whatever that person can reach, including production repositories they happen to have access to.

The audit gap

Sessions live in local transcripts. A security team asked what an agent did last month usually has shell history at best, and personal-account usage leaves even less.

In practice: Every risk above is expressed as a tool call. That is where a control can see it and where a denial is cheap.

How to implement coding agent security

Start with visibility, then bound the two things that matter most: what the agent can read and where it can send it.

1. Inventory the agents and their servers

Enumerate the agent CLIs, IDE extensions and MCP servers on every developer machine, including the config path that enabled each server. You cannot write a policy for the CLI you did not know was installed.

Tip: Ask for the tool list each CLI exposes, not the vendor name. Two installations of the same tool can have very different capability sets.

2. Deny credential paths by default

A short deny list covers most real incidents: SSH private keys, cloud credential files, package registry tokens, browser profiles, and .env files outside the working repository. Enforce it at the endpoint where the read happens.

3. Broker repository credentials

Replace personal tokens with short-lived leases scoped to the repository and the branch. The agent then acts as itself, with the developer's entitlement checked at issue time, and the record names both.

Tip: Scope write leases to a branch prefix the agent creates. A push restriction that requires no human attention is worth more than a policy nobody enforces.

4. Treat project MCP config as code

Require review for changes, pin versions, and refuse servers that fetch a definition from a URL at runtime. Where possible, resolve servers from an internal registry rather than a public namespace.

5. Allowlist egress

Named destinations only: the model endpoint, the package registry, the source host. Everything else is denied and recorded. This is the control that turns an exfiltration attempt into a blocked connection.

6. Keep production credentials out of reach

A coding agent should not be able to hold production cloud credentials, even read-only. Where a workflow needs it, use a separate agent with its own approval path rather than widening the developer tool.

7. Put review between the agent and the default branch

Agent-authored changes should arrive as pull requests with attribution, reviewed by a human who can see the diff and the tool calls that produced it. The control is not that a human reads every line. It is that a human decision exists for changes to protected paths.

8. Stream the evidence somewhere you keep

Send tool-call decisions, shell executions and denials to your SIEM, signed and chained. Then a question about last month has an answer that does not depend on a developer's laptop still existing.

Where coding agent security applies in the SDLC lifecycle

Design

Decide which agents are sanctioned, what they may reach and whether they can run commands unattended. Also decide the identity model, because retrofitting per-agent identity after 400 laptops is a project.

Note: Most organisations discover at design time that their repository permissions were never designed for non-human actors. Fixing that once is cheaper than per-team workarounds.

Development

Keep MCP configuration in the repository, reviewed and pinned. Keep secrets out of the shell profile, and keep the agent's own config free of keys.

Pre-deployment testing

Test with hostile repository content: an injected README, a poisoned tool description, a fixture that asks the agent to read a key file. Confirm the denial exists and is recorded.

Note: A denied call is a better test result than a well-behaved one. It proves the control exists rather than that the sample was polite.

Deployment

Confirm the agent's identity, the lease path and the egress allowlist before the first protected-branch push. Verify attribution in the audit record, not only in the pull request.

Runtime

Decisions happen per tool call, with arguments visible. Denials reach both the developer and the SIEM, because a denial is often the first sign of a hijacked session.

Continuous monitoring

Track new servers per week, standing secrets remaining in configs, denials per agent and per repository, and the share of agent-authored changes that had a human approval on protected paths.

Note: A spike in denials on one machine can be a hijacked session or a policy bug. Alert on it and let a human decide which it is.

Decommissioning

Remove the agent's identity, expire the leases, delete the config and keep the session record for the retention period. Departed developers are the usual home of orphaned agent tokens.

The takeaway: Coding agent security is endpoint security with a new consumer. Same deny lists, same least privilege, different action surface and a much faster loop.

Worked example: a platform team enabling 200 developers

A software company enables a coding agent for 200 developers. The rollout takes two weeks. The security team hears about the plan in week three, when an engineer asks whether the agent is allowed to read the company's SSH keys.

Week 1, inventory. Endpoint discovery finds the sanctioned agent on 190 machines, two unapproved CLIs on 44 machines, and 31 distinct MCP servers. Seven of those servers hold personal access tokens in project config files, and one is configured from a URL that resolves today to a JSON definition nobody reviewed.

Week 1, the credential path. A deny list for SSH keys, cloud credential files, registry tokens and out-of-project .env files is deployed in monitor mode for a week. It records 2,140 attempted reads of credential paths, most from an agent summarising a home directory during setup. Nothing breaks when the list is enforced, which is the useful finding.

Week 2, identity. Personal tokens are replaced with leases scoped to a repository set and a branch prefix, expiring in 20 minutes. Two CI jobs that depended on a developer's token are moved to their own identity. The audit record starts naming agents instead of people.

Week 3, egress. The allowlist covers the model endpoint, two package registries and the source host. A legitimate internal documentation server is added after one support ticket. Three attempted connections to a public paste service are blocked in the first month, all from a project whose README contained an instruction to save build output externally. That project is cleaned, and the finding is recorded as an injection attempt rather than a policy exception.

Month 2, review. Agent-authored changes to protected paths must arrive as pull requests with a named reviewer. A rule requires the diff and the tool calls to appear together, so reviewers can see that a change came from a scripted sequence rather than a considered edit.

Month 3, the near miss. A dependency's README instructs the agent to add a package from a typosquatted namespace. Policy blocks the install because the registry destination is allowlisted but the package is not on the internal list. The developer is told, the dependency is flagged upstream, and the blocked install is the first evidence the team has that the egress control works.

Month 6, audit. An internal review asks how many agent-authored changes reached the main branch without human approval in the prior quarter. The answer is none, and the query takes minutes because each decision carries the repository, the branch, the actor and the policy version.

The rollout succeeded because none of the controls depended on developers behaving differently. The agent kept its speed, the credential paths became unreadable and the exfiltration path disappeared.

How standards and regulations influence coding agent security

Framework	Primary focus	Relevance to coding agent security
NIST AI RMF	Govern, Map, Measure, Manage	Structures inventory, risk tiering and monitoring for agent tooling
ISO/IEC 42001	AI management system with documented controls	Expects roles, records and review for AI used in delivery
ISO/IEC 23894	AI risk management inside enterprise risk	Connects agent risk to existing third-party and change risk
ISO/IEC 42005	AI system impact assessment	Frames the pre-rollout question of what an agent's access could affect
EU AI Act	Obligations by risk class, including logging and oversight	Applies where agent-authored code sits inside a high-risk system
OWASP Top 10 for Agentic Applications 2026	ASI01 goal hijack, ASI04 supply chain, ASI05 unexpected code execution	The closest match to coding agent failure modes
OWASP MCP Top 10 (beta)	Tool poisoning, token management, shadow servers	The per-project server risks
SOC 2	Change management, access control, monitoring	Expects review evidence for changes to production systems

Further reading: Agentic SDLC for the process view, Sensitive data and secrets in agent context for the data side, and Tool poisoning for the description channel.

How Alyria handles it

Alyria governs the agent where it runs, which is the only place a coding agent's tool calls can be decided before they execute. Beacon, the signed daemon on every machine, inventories agent CLIs, IDE extensions and MCP servers, records the configuration that enabled each one, and routes the agent's inference and network calls through a local policy service.

Lyra decides per tool call with the arguments in view: which repository, which path, which destination, which server. A read of a credential path is denied before it happens, and a push to a protected branch is held rather than blocked outright where that is the better fit for the workflow.

Umbra removes the personal token from the loop. Repository and cloud credentials arrive as short-lived leases scoped to the task, sealed to the device's hardware key, so a copied config file carries nothing usable. Spectra streams signed, chained OpenTelemetry into your SIEM, which turns the audit gap into a query.

Start free at alyria.ai and run Beacon on one developer machine to see the agent and server inventory: app.alyria.ai/signup.

The free Agent Exposure Report is the read-only starting point, and these posts go deeper: keeping coding agents away from secrets, blocking coding agent tool calls before execution, and finding MCP servers on developer laptops.