Your AI Coding Agent Has a Supply Chain. Are You Auditing It?

A coding agent can follow every approval prompt you give it and still run malicious code.

That is the uncomfortable part of the new AI developer-tool supply chain: the model is not the only thing with access to your machine. Plugins, skills, MCP servers, editor extensions, hooks, and helper packages can execute with the permissions of the developer who installed them.

CERT-EU recently demonstrated how seemingly legitimate third-party agent packages could be modified to collect credentials in the background. The lesson is bigger than “be careful what you install.” We need to treat agent extensions like production dependencies.

Here is a practical way to do that without turning every experiment into a security review project.

1. Inventory the whole agent stack

Most teams already track npm, Python, and container dependencies. Add the components that extend your coding agent:

• MCP servers and their package versions
• Agent skills and prompt packs
• Editor extensions
• Lifecycle hooks and shell scripts
• Local tools the agent can invoke
• Remote services the agent can authenticate to

Keep the inventory in the repository or an internal document. Record the source, version or commit, maintainer, permissions, and why the team needs it.

If you cannot answer “what code runs when this agent starts?”, your inventory is incomplete.

2. Review capabilities, not marketing descriptions

A tool described as “GitHub integration” might read issues, create branches, push commits, open pull requests, or access repository secrets. Those are very different risk levels.

For every extension or MCP server, ask:

1. Can it read files outside the current project?
2. Can it execute shell commands or start processes?
3. Can it access environment variables, tokens, or SSH credentials?
4. Can it make outbound network requests?
5. Can it modify files or publish changes without approval?

Write down the actual capabilities. Do not infer them from the tool's name or marketplace description.

3. Apply least privilege at the process boundary

Agent approval prompts are useful, but they are not a complete sandbox for code running alongside the agent.

Use separate boundaries:

• Run experiments in a disposable container or VM.
• Mount only the repository and directories the task needs.
• Keep production credentials out of local agent environments.
• Use short-lived, narrowly scoped tokens.
• Restrict outbound network access where practical.
• Require human approval for external side effects.

A useful default: an agent working on a feature branch should not inherit credentials that can deploy production.

4. Pin, verify, and update deliberately

For every component, prefer a specific version or immutable commit over a floating branch or an unpinned “latest” install.

But do not confuse pinning with verification. Check that the code actually installed matches the version or commit you reviewed. A pinned reference is only useful if the installation process verifies what landed on disk.

For high-impact tools, keep a small record:

5. Make security checks part of onboarding

A lightweight checklist is better than a long policy nobody follows.

Before enabling a new agent tool:

• [ ] Confirm the source and maintainer.
• [ ] Inspect the code or package contents when feasible.
• [ ] Check requested filesystem, shell, and network access.
• [ ] Pin an exact version or commit.
• [ ] Test in an isolated environment first.
• [ ] Use dummy credentials during evaluation.
• [ ] Document the owner and reason for using it.

Revisit the list when permissions change or a component updates.

6. Treat agent tools like dependencies, not accessories

The key shift is conceptual: an MCP server or agent skill is not just a prompt enhancement. It is part of the software that executes in your development environment.

That means it deserves the same questions we ask about a new dependency: Who maintains it? What can it access? How is it updated? What happens if it is compromised?

You do not need to ban third-party tools. You need to make their trust boundary visible.

A practical starting point

Pick the five agent extensions or MCP servers your team uses most. For each one, write down its source, exact version, permissions, network access, and owner. Then remove permissions that are not required for its actual job.

That one-hour exercise will usually reveal more than another generic “AI security” policy.

How are you managing the supply chain around your coding agents today? Do you have an inventory and permission review, or are tools still being added one marketplace install at a time?

Further reading: CERT-EU — Beyond the model: backdoors in AI agent harnesses.