Your Coding Agent Runs as You — and So Does Everything You Install Into It

Your coding Agent doesn't run as a carefully scoped service account, or inside some signed-off sandbox — it runs as you, with your filesystem, your credentials, your repositories, and your ability to push code.

That's exactly what makes it useful. It's also why what you install into it deserves more scrutiny than most people give it. An Agent skill, a plugin, or an MCP server isn't a document your Agent reads. It's a set of instructions your Agent will execute — with your permissions, while you're busy doing something else.

Most people's mental model here is the "app store" one: marketplace review means someone checked. A piece of research published this year makes a fairly compelling case that this mental model collapses on contact with reality.

What the Researchers Did

A security company called AIR built an AI Agent skill, gave it a convincing name, packaged it as a tool from a company you'd recognize, and got it through review and onto a popular marketplace. They then ran ads targeting professionals who evaluate tools by how legitimate they look.

Every scanner that examined it — including scanners from well-known security vendors — reported it as clean.

And they weren't wrong. At the moment they checked, it was clean.

The skill referenced a documentation link. When scanners checked, that link served real documentation. After enough people had installed it, the researchers changed what the link pointed to — it now instructed the Agent to download and run a script. In the public demo, it collected an email address, which is the polite end of what it could have collected.

The original author deliberately avoided repeating the install count that's been circulating, because it's a self-reported, independently unconfirmed number from the company that ran the experiment. The number isn't the point. The mechanism is. And the mechanism doesn't need a large number to warrant action.

---

This class of attack has a dedicated category in security research: Supply Chain Poisoning — sometimes described as an advanced variant of Typosquatting or a variation of Dependency Confusion. The common thread: the attacker doesn't need to compromise the target system directly; they poison the upstream resources the target depends on. In 2021, security researcher Alex Birsan successfully delivered malicious public packages that shadowed private dependencies to 35 companies including Apple, Microsoft, and PayPal, earning over $130,000 in bug bounties. What makes the AIR research novel is that it targets an AI Agent ecosystem with no established security norms, and exploits the "clean at scan time, malicious at run time" temporal property — a property that structurally prevents any platform's pre-publication review from catching the threat, not merely because review was insufficiently thorough.

Why No Scanner Can Fix This

This part is worth genuinely internalizing, because it applies far beyond Agent skills.

A scanner examines an artefact at a point in time: reads the file, matches it against patterns of known-malicious behavior, and returns a verdict on those bytes. That verdict is accurate — but it's about the past.

The instructions your Agent ultimately executes are retrieved later, over the network, from wherever the artefact merely points to. Those are two different objects, separated by however long it took your team to adopt the tool, plus one HTTP request.

Security engineering has a name for this shape: Time of Check to Time of Use (TOCTOU). It shows up everywhere, from filesystem races to payment flows. The general form is simple: whenever the thing you verify and the thing you act on are retrieved separately, whoever controls the second one determines what actually happens — no matter how carefully you verified the first.

Static analysis cannot bridge this gap. Not because the tools are weak, but because the thing being analyzed is not the thing being executed. You could scan continuously and still lose — because the substitution can happen between your scan and the next invocation.

---

TOCTOU vulnerabilities were first studied systematically in the 1970s, initially describing race conditions in OS file permission checks: a program calls access() to check permissions, then open() to use the file, and an attacker swaps in a symlink between the two syscalls. Today the pattern has extended to virtually every scenario where "verify" and "execute" are separated. In supply chain security, the canonical lesson came from the 2020 SolarWinds incident: attackers injected malicious code into the final build artefact within the build pipeline, while all prior source code review targeted the content before injection. The Agent skill TOCTOU variant is subtler still — it's not the artefact itself that gets swapped, but the remote content the artefact references, which means the artefact can be clean at any moment of inspection, and the entire attack surface lives in the runtime network request.

What Actually Reduces Risk

Since you can't reliably detect the substitution, you have to either remove the ability to substitute or limit how much damage a substitution can cause.

Check the publisher and destination, not the description. A convincing name plus a plausible documentation link is the entire attack. The real question isn't "does this look professional" but "did this vendor actually publish it, from a domain they own." Those are two different questions, and only the second is verifiable.

Pin and vendor what you keep. Copy the skill into your own repository, review it there, and update it deliberately rather than automatically. The version you reviewed and control is not the same thing as a name you once trusted. When a tool changes maintainers, treat it as a new tool requiring re-review — because from a supply chain perspective, it is.

Prefer immutable references. For things that must be fetched, pin to a commit hash or content digest — which cannot change beneath you — rather than to a branch, tag, or bare URL, all of which can be redirected. This is the same discipline as pinning CI actions to a hash rather than a version tag, for the same reason.

Give the Agent less to lose. Don't run it in directories with production credentials. Prefer per-project installation over global installation, so a compromised tool can only reach one project rather than everything you're working on. This is ordinary least-privilege, applied to a category of software most teams haven't yet classified as "software running with permissions."

Pay particular attention to where it runs, because that materially affects the risk: a skill running inside a local coding Agent has the same network and filesystem access as any other program on your machine. Sandboxed, API-side execution is a different and smaller attack surface. Understand which one you're using before deciding how much to care.

---

The "pin and vendor" practice has established precedent in software supply chain security. Go's go.sum, Rust's Cargo.lock, and GitHub's recommendation to reference Actions by commit SHA rather than version tag all implement the same principle: lock the hash of content you once trusted into version control, so any subsequent tampering cannot pass silently. Content digests typically use SHA-256, whose collision resistance means an attacker cannot computationally construct a substitute with the same hash but different content. Notably, semantic version tags (like v1.2.3) and Git branch names (like main) are mutable pointers — the repository owner or a compromised account can point them at a different commit at any time. This is the fundamental reason why vendoring is more reliable than trusting a name.

Run an Inventory

Advice is cheap, so here's the actual check.

You need to know two things: every URL reachable from anything you've installed, and every executable your Agent toolchain is configured to run. In the appsec-protocols repository, there's a single script for this (run from a clone of it):

bash ci/scripts/vet-agent-installs.sh

It walks skill and plugin directories, follows symlinked skills, reads MCP server configuration (including per-project servers nested inside global config files), and prints two lists: the URLs, and the command and arguments for each server.

Then you read the output and own each line. A URL that's neither an immutable reference nor a vendored copy is a finding. An executable source without an integrity lock is a finding. A documentation link from a vendor's own domain is probably fine — and "probably fine, and I looked" is a materially different position than "I never checked."

There's a detail worth sharing about building that script: its output goes directly into an AI Agent's context. If the configuration it reads contains credentials and prints them, the tool moves your secrets somewhere you don't want them. So it needs to redact. The initial implementation redacted by matching against a list of known credential names, passed review twice, then failed on api-key because the list used api_key. The fix was to stop matching names and instead match shapes: any argument whose name looks like a credential, plus any value that looks like a token, gets replaced before printing.

There's now a test that plants credentials in a temporary config (12 forms when it was written, 17 now) and fails if any of them reach output. Running the old script, 4 of 12 leaked. That test is what makes it reasonable to tell you to run the thing.

If You're the Person Who Approves What the Team Installs

You don't need to understand any of the technical detail above to ask the questions that actually matter. Four of them:

1. "What has everyone on the team installed into their coding Agents, and can we produce that list?" If no one can produce the list, that's itself a finding — the same finding as not knowing what dependencies are running in production.
2. "Do any of them fetch instructions from the internet at runtime?" This is the question that distinguishes a tool from a liability, and it can be answered with one command.
3. "Where does our Agent run, and what credentials does it have access to there?" An Agent running in a directory with production keys is an Agent that has production keys.
4. "What happens when a tool we depend on changes hands?" The answer you want is "someone re-reviews it." The common answer is "no one notices."

None of these require a policy document. They only require that the list exist and that someone has read it.

Where the Boundary Is

This is a baseline for one specific category of supply chain risk — not a complete threat model for AI tooling.

It doesn't cover prompt injection via skill descriptions, malicious behavior in a skill that never fetches anything, the marketplace itself being compromised, or the possibility that a tool is exactly what it claims to be and its author's account gets taken over next month. The inventory script tells you what's reachable and configured — not whether the people behind those names are trustworthy. That remains a judgment call that no command returns an answer to.

What it does buy you is that you'll never again be surprised by a list you never took inventory of.

The project is public and MIT-licensed, with the script and its limitations documented in the repository.