AI coding tools are often discussed as faster authors. That description is too narrow. An agent can choose dependencies, configure tools, install plugins, add an MCP server and rewrite the instructions that guide future sessions. Each decision expands or redirects trust.
The supply chain is no longer a separate stage that begins after code generation. It is part of the agent’s working loop.
Secure what the agent decides to trust, not only what it decides to write.
A package name is a security decision
A model can suggest a package that looks plausible but does not exist. An attacker can publish that name and wait for an automated installation. A near-match can also send a developer to a typosquatted package. A legitimate package can still introduce unexpected install-time behaviour or arrive from a suspicious source.
These risks are well suited to continuous deterministic checks because many of the relevant facts are concrete. The manifest changed. A package is new. The registry does not recognise the expected identity. The source URL changed. An install script appeared.
CodeMarine’s supply-chain work examines supported manifests, lockfiles, package sources, known malicious indicators and install behaviour. The goal is to evaluate new trust at the point it enters the workspace, regardless of whether Claude, Codex, Cursor or a person added it.
The agent ecosystem is part of the chain
Dependencies are only one part of the modern development supply chain. Agent tooling introduces artifacts that can shape behaviour without appearing in application source:
- MCP server definitions can grant access to tools and data
- skills and plugins can carry executable behaviour or instructions
- repository rules can redirect how an agent interprets every future task
- persistent memory can preserve a malicious or simply wrong assumption
- tool descriptions can contain instructions that compete with the user’s intent
Those artifacts deserve provenance, scanning and policy. Treating them as harmless configuration leaves a path around conventional source and dependency controls.
Prompt injection becomes an operational risk
Prompt injection in a repository is not only about making a model say something odd. An instruction hidden in code, documentation or tool metadata can try to influence an agent with real authority. It may encourage secret collection, disable a check or redirect an installation.
No scanner will recognise every malicious instruction. Deterministic signals can still identify suspicious locations, known instruction patterns and sensitive configuration changes. Frontier reasoning can then inspect the smaller set of ambiguous cases with more context.
Notice that a dependency, MCP definition, skill or persistent instruction changed and evaluate known risk immediately.
Use an approved frontier model to reason about intent, interactions and novel behaviour when deterministic evidence is not enough.
Make trust visible before it becomes normal
New dependencies often disappear into the background after the first successful build. The same is true of agent configuration. Once a tool works, its authority becomes part of the environment and future developers stop noticing it.
A useful protection system records the moment trust changed. It identifies what entered, who or what introduced it, which policy evaluated it and which revision accepted it. That evidence makes later investigation possible and gives teams a durable baseline.
Use models to discover, then remember deterministically
A frontier investigator may discover a new malicious package pattern, a poisoned skill structure or a dangerous interaction between configuration files. That discovery becomes far more valuable when it can be converted into a regression fixture and a tested deterministic rule.
This creates a compounding security model. The frontier layer finds what the existing system did not know. The deterministic layer learns the verified shape and catches the next occurrence locally. New intelligence becomes routine protection.
The practical policy
Teams adopting agents should treat every new trust decision as reviewable:
- Watch manifests, lockfiles and sources continuously.
- Inspect install-time behaviour before normalising a package.
- Include MCP, skills, plugins and agent rules in the repository security model.
- Require stronger review when an agent adds authority, not just code.
- Keep the final decision independent from the model that proposed the change.
AI did not merely accelerate code generation. It accelerated the rate at which software can change what it trusts. Supply-chain security has to move at the same speed.