AI Developer Tool Security Starts With Treating Every Repository As Untrusted Input

Somewhere in your company right now, a developer is cloning a repository they found in a GitHub issue, opening it in an editor with an AI coding assistant switched on, and asking the assistant to explain how the build works. That is a perfectly reasonable Tuesday. It is also, depending on how the assistant is configured, the moment a stranger on the internet gets to run commands on a laptop that holds the company's cloud keys, a checkout of every private repo, and a browser session logged into production.

AI developer tool security used to sound like a problem for the big labs. It stopped being theoretical in July, when Amazon Q Developer was found to auto run Model Context Protocol server configurations from any repository a developer opened (CVE-2026-12957). No click on a suspicious attachment, no macro prompt, no malicious package install. The configuration file sat in the repo, the assistant read it as trusted setup, and the process it launched ran with the developer's full privileges. This week added a reminder from the other direction, with GitLab CVE-2026-85706 handing unauthenticated attackers file read at CVSS 10 on the platform where a lot of small teams keep both their source and their CI secrets. One flaw is in the tool that reads code. The other is in the system that stores it. Both land on the same asset, which is the trust relationship between a development team and the code it touches.

This post is the threat model for that relationship, written for the small and mid-sized dev team that adopted AI coding assistants because they genuinely help, and never had a meeting about what the assistant is allowed to do.

AI developer tool security is a trust boundary problem, not a productivity setting

Here is the thing most security reviews of AI coding tools get wrong. They focus on data leaving the building, on whether snippets of proprietary code get sent to a model provider and whether that provider trains on them. That is a legitimate procurement question, and the answer is usually buried in an enterprise agreement somebody signed. It is also the least interesting risk on the table.

The more serious question is what the assistant can do, not what it can see. A modern coding assistant is not an autocomplete box anymore. It is an agent that reads files, runs terminal commands, edits configuration, calls external tools through MCP servers, and in many setups does all of that with approval prompts that developers learned to click through by the second afternoon. OWASP named this pattern directly in its Top 10 for LLM Applications, where LLM06 Excessive Agency describes a model granted more functionality, permissions, or autonomy than the task requires. Pair that with LLM01 Prompt Injection and LLM03 Supply Chain from the same list and you have the whole shape of the problem in three entries.

From a CISSP standpoint, the failure is a trust boundary drawn in the wrong place. Security teams spent a decade teaching developers that a cloned repository is untrusted until proven otherwise. Visual Studio Code even shipped Workspace Trust so that tasks, debug configurations, and extensions would not execute from a folder the user had not explicitly trusted. AI assistants quietly walked back across that line. The agent reads the repository to be helpful, and the repository gets to talk to the agent. Anything the agent is permitted to do, the repository can now ask it to do.

How an opened repository becomes code execution

The Amazon Q issue is worth walking through slowly, because the same path shows up across the category. MCP is the protocol that lets an assistant call external tools, whether that is a database client, a ticketing system, or a local script. Tools are defined in configuration files, and several assistants look for those files at the project level so that a team can share a common setup. That is a convenient feature. It also means a file checked into a repository can define a command, and an assistant that loads project configuration automatically will launch that command as a local process the moment the workspace opens.

The lineage is short and it is not flattering. Cursor patched CVE-2025-54135, nicknamed CurXecute, where prompt injection could rewrite the MCP configuration and trigger execution, and CVE-2025-54136, where an MCP configuration approved once could later be swapped for a malicious one without a fresh prompt. GitHub Copilot in Visual Studio Code had CVE-2025-53773, where injected instructions could get the agent to flip its own settings file into an auto approve mode and then run whatever it was told. The Amazon Q extension itself had a rough 2025, when a malicious pull request slipped instructions into a published release telling the agent to wipe local files and cloud resources. That payload was reportedly malformed enough not to work, which is a strange thing to be grateful for.

Map any of those onto MITRE ATT&CK and the path is familiar. Initial access is T1195.001, compromise of software dependencies and development tools, or simply a developer being socially engineered into cloning a repo, which is the same lure the Lazarus fake job interview campaigns have used for years with booby trapped coding assessments. Execution follows as T1059 under the developer's own user context. There is no privilege escalation step, because a developer workstation rarely needs one. Collection lands at T1552.001, credentials in files, and the developer laptop is the best place in the company to find them.

What makes this path nasty from a blue team perspective is that nothing about it looks unusual on the endpoint. The editor spawned a Node or Python process. Developers' editors spawn Node and Python processes all day. The EDR sees a signed, allowlisted application launching an interpreter from a project directory, which is literally the job description of an IDE.

The developer laptop was already the richest credential store you own

Before AI assistants arrived, the developer workstation was already the least governed high value asset in most small companies. It is where the long lived AWS access key lives in a credentials file because the SSO integration broke once in 2024 and nobody went back. It is where the personal access token for GitHub or GitLab sits in a dotfile with full repo scope. It is where the kubeconfig for the production cluster was copied during an outage, and where a dot env file holds the Stripe secret key for local testing. NIST control CM-8 asks for an inventory of system components, and almost nobody's inventory records the fact that one engineer's laptop carries more standing access than the domain admin account.

Attackers noticed this well before the AI angle. The August 2025 compromise of the Nx build system packages is the example every dev team lead should know by heart. The malicious versions harvested tokens, SSH keys, and wallet files, and then did something new. They checked whether AI command line tools such as Claude Code, Gemini CLI, and Amazon Q were installed and prompted them, with permission bypass flags, to search the filesystem for secrets. The attacker outsourced reconnaissance to the victim's own assistant. The stolen material was published to public repositories created under the victims' own GitHub accounts, which is about as insulting as data exfiltration gets.

Then the Shai-Hulud npm worm arrived weeks later and used stolen publishing tokens to push itself into more packages automatically. The tj-actions/changed-files compromise in March 2025 (CVE-2025-30066) had already shown the CI side of the same story, dumping secrets into public workflow logs across thousands of repositories. Put those three together and the pattern is plain. The target is the credential, the delivery vehicle is the developer toolchain, and the AI assistant is now both a new delivery vehicle and a very efficient search engine for whatever the attacker lands next to.

This is where the GitLab file read from this week matters for the same conversation. A self hosted GitLab instance holds CI variables, deploy tokens, runner registration tokens, and the configuration files that tell pipelines which cloud role to assume. Unauthenticated file read against that server is credential theft against the entire engineering organization, no laptop required. Whether the attacker comes through the assistant or through the source platform, the prize is the same pile of standing secrets.

Prompt injection turns every README into an instruction set

Configuration file execution is the loud version of this risk. Prompt injection is the quiet one, and it is harder to patch because it is not really a bug in any single product. A language model does not have a reliable way to separate instructions from data. If the assistant reads a file as part of its task, the contents of that file become part of the context the model reasons over, and text that looks like an instruction can be followed as one.

The practical injection surfaces on a dev team are everywhere a developer points the assistant. A README in a third party repository, a comment buried in a dependency's source, a GitHub issue the assistant was asked to summarize, a web page fetched during research, a code review comment from an outside contributor, even the output of a failing test that echoes attacker controlled input. Researchers have demonstrated hidden instructions tucked into Unicode tag characters and HTML comments that render invisibly to the human reviewing the file while remaining perfectly legible to the model.

The consequence depends entirely on agency. An assistant that can only suggest text in a chat panel can be manipulated into giving bad advice, which is annoying. An assistant that can run shell commands, write to its own settings, call an MCP tool with network access, and commit code can be manipulated into exfiltrating a credentials file to an attacker's server and then opening a pull request that looks like a routine lint fix. MITRE ATLAS catalogs this class of technique for AI systems, and NIST SP 800-218A, the generative AI community profile for the Secure Software Development Framework, pushes organizations to treat model inputs with the same suspicion as any other untrusted input. That guidance was written mostly with model builders in mind, but the logic applies just as cleanly to model consumers.

The uncomfortable conclusion for a CEH is that you cannot filter your way out of this. Every vendor ships some prompt injection defense, and every one of them has been bypassed by a researcher with a free afternoon. The durable answer is the same one security has always used when input validation is unreliable. Assume the input is hostile and constrain what the process that consumes it is allowed to do.

Controls that change the outcome for a small dev team

None of this requires banning AI coding assistants, which would be both unenforceable and a great way to push developers onto personal accounts with no controls at all. It requires treating the assistant as what it is, a privileged automation identity running on the most credential rich endpoint in the building.

Start with the settings that decide whether a repository can execute anything. Disable automatic loading of project level MCP configuration and require that tool servers come from a centrally managed allowlist. Turn off auto approve and so called yolo modes for terminal commands in company managed installs, and enforce that through the editor's managed policy features rather than a wiki page. Keep Workspace Trust on in Visual Studio Code and teach the team that restricted mode is the correct default for anything cloned from outside the organization. These are AC-6 least privilege and CM-7 least functionality decisions, and they cost almost nothing to make.

Next, shrink the prize. The single highest value project for most small engineering teams is getting long lived credentials off developer laptops entirely. Move cloud access to SSO backed short lived sessions through AWS IAM Identity Center, Azure CLI with Entra sign in, or the Google Cloud equivalent. Scope Git personal access tokens to specific repositories with expiration dates, or replace them with fine grained tokens and SSH keys held in a hardware backed agent. Pull production secrets out of dot env files and into a secrets manager that requires an interactive, MFA gated fetch. When an assistant or a malicious package goes looking for credentials and finds a fifteen minute session token instead of a three year old access key, a total compromise becomes a partial one.

Then isolate the risky work. Development containers and remote development environments give each project its own filesystem and its own scoped credentials, so an injected command running inside a devcontainer sees that project's secrets and not the whole home directory. For evaluating unfamiliar code, including the take home assessment from a recruiter nobody has met, a disposable virtual machine with no company credentials is the only sane option. This is SC-7 boundary protection applied at the scale of a single laptop.

Finally, get visibility the endpoint agent will not provide on its own. Egress monitoring on developer workstations and devcontainers catches the step that every one of these attacks eventually needs, which is sending stolen material somewhere. Git platform audit logs catch new tokens, new deploy keys, and repositories created under an employee's account at three in the morning. Cloud control plane logs catch an access key suddenly calling APIs from an unfamiliar network. Under SI-4 and AU-6, those three sources correlated together tell a far clearer story than any single EDR alert about Node spawning a shell.

How to pentest an AI coding assistant deployment

Most penetration test scopes for a software company still stop at the production application and the external perimeter. That leaves the tier described above completely untested, which is odd, because it is precisely where attackers have been getting in.

A useful assessment of the development environment starts with configuration review of the assistants as actually deployed, not as the vendor documentation says they should be. Testers check which assistants are installed across the team, which versions, whether auto approve settings are enforced or merely suggested, and whether project level MCP and settings files are honored. That alone usually produces findings, because the managed policy that someone configured in the admin console rarely matches what is running on the contractor's personal MacBook.

The core of the test is a controlled malicious repository. The assessment team builds a realistic looking project containing a crafted MCP configuration, injected instructions in a README and a source comment, and a benign canary payload that phones home and records exactly which files and environment variables it could reach. A consenting developer opens it and uses the assistant normally. The output is not a theoretical severity score. It is a concrete list of what a stranger's repository could have touched on that machine, which tends to be a more persuasive document for leadership than any CVE writeup.

From there the scope extends into blast radius. Testers take the credentials that the canary could reach and measure how far they go, whether that token pushes to the main branch, whether that cloud key reads the production database backups, whether the GitLab runner token lets an attacker register a runner and harvest CI variables from every pipeline. The engagement closes with detection validation, confirming whether the egress, source platform, and cloud logs actually flagged any of it, and how long it took a human to notice. OWASP's Web Security Testing Guide covers the application pieces well, but this part of the work is closer to a focused internal assessment with a supply chain entry point, and it should be scoped that way.

Where this work usually lands

The teams that handle AI developer tool security well are not the ones that picked the most locked down assistant. They are the ones that wrote down, in a single page, what the assistant is allowed to execute, which credentials exist on developer machines and how long they live, and who gets alerted when a repository does something a repository should not do. That page tends to be short. Getting to it tends to require someone actually trying the attack first.

That kind of evidence driven scoping is what the Penetration Testing module inside CyberSphere was built around. It runs external, internal, and web application assessments from one dashboard, lets the assessment team scope a development environment test against the controls a client actually has to defend, and pushes each finding into the remediation queue with the canary evidence and the credential blast radius attached, so the fix for an auto approve setting and the fix for a three year old cloud key do not get lost in separate spreadsheets. Software teams around Plano and Frisco that have been shipping faster with AI assistants will find the platform at https://cybersphere.thecyberone.com/, though the honest first step costs nothing. Open a terminal on one developer laptop, list every credential file in the home directory, and ask how many of them an opened repository could read. The answer usually settles the budget conversation on its own.

Ready to Take the Next Step?

Innovation Network Design helps businesses across McKinney, Dallas, and the DFW metroplex — as well as organizations nationwide — with expert cybersecurity services. Contact us for a free consultation and we'll assess your needs with clear, actionable recommendations.

Have questions? Call us at 512-518-4408 or schedule a free assessment.