In July 2026, researchers at Noma Labs coaxed GitHub's new Agentic Workflows into leaking data from a private repository. It wasn’t from malware. They created a plausible-looking issue in a public repository containing instructions for the agent to retrieve information from other repositories in the organization. After testing variations of the prompt, they found that adding one word, "Additionally," was enough to get past GitHub's guardrails. The agent followed the instructions, fetched a private repository's README, and posted its contents as a public comment for anyone to read.
Most of the agentic AI security conversation fixates on that first part: the trick. Can an agent be manipulated into doing something its operator never intended? Yes, and GitLost shows how little it can take to bypass the safeguards designed to prevent it. But the trick only decides whether an incident starts. What the agent can reach determines how much damage follows. Across this year’s most instructive agent incidents, the severity of the outcome came down to what the agent could access: credentials, permissions, and the authority attached to them.
Three agentic AI incidents with a single amplifier
Three disclosures from 2026 make the pattern hard to miss.
#1. Claude Code: opening a repository was enough to lose an API key
In February, Check Point Research disclosed three newly discovered ways developers could be exploited, including two new vulnerabilities in Anthropic's Claude Code. Two allowed remote code execution through repository configuration files (.claude/settings.json and .mcp.json) that Claude Code could load when a developer started the tool inside an untrusted project. The third, CVE-2026-21852, worked differently but exposed something immediately useful to an attacker: the victim's Anthropic API key. A malicious repository could set the ANTHROPIC_BASE_URL environment variable, and Claude Code would send API requests, credentials included, to the attacker's endpoint before it ever showed the user a trust prompt. Anthropic patched the three issues between August and December 2025, ahead of Check Point's February 2026 disclosure.
Notice what the attacker actually gets. The code execution flaws carried the higher severity scores, but the key exfiltration converts directly into durable access: authenticated API traffic redirected to attacker infrastructure, usage billed to the victim, and continued access wherever that API key remains valid. The exploit created the opening. But it was the stolen credential that extended the attacker’s access.
#2. Amazon Q: one config file inherited a full cloud identity
In June, Wiz Research disclosed CVE-2026-12957 in the Amazon Q Developer extension for Visual Studio Code. The extension automatically loaded Model Context Protocol (MCP) server configurations from a .amazonq/mcp.json file in any workspace a developer opened, without requiring consent or a workspace trust check. A developer could clone a malicious repository, open it with Amazon Q installed, and unknowingly launch an attacker-controlled MCP process.
The vulnerability gave the malicious MCP process a way in. What made it dangerous was the access that came with it: live AWS credentials from the developer's environment, including AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and active session tokens. Wiz's proof of concept used aws sts get-caller-identity to identify the AWS account and role available through those credentials, then sent that information to an external server. From there, an attacker could exercise whatever access those credentials allowed, potentially reaching production data, creating new access keys for persistence, or moving into internal systems.
Amazon fixed the consent flow in language server version 1.65.0. But the broader lesson is about credential inheritance: the malicious configuration became dangerous because the process it launched inherited live credentials from the developer's environment.
#3. GitLost: a blast radius without a stolen secret
GitLost, the GitHub Agentic Workflows vulnerability Noma Labs disclosed in July, shows the same problem from a different angle. The vulnerable workflow could read public issues while also holding read access to other repositories in the organization, including private ones. A crafted public issue manipulated the agent into using access it already had to retrieve information from a private repository. GitHub's guardrails were supposed to block that request, but a one-word change to the prompt was enough to bypass them.
This is what over-permissioning looks like in agentic systems. An agent can exercise permissions on behalf of whoever controls or influences its instructions, even if that person never possesses the underlying credential. GitLost therefore reinforces the same lesson as the Claude Code and Amazon Q incidents from the opposite direction: a credential does not have to be stolen for the access behind it to be abused. Whether an attacker steals an API key or manipulates an agent into using its existing repository access, the outcome depends on how much authority that agent has. In GitLost, the prompt injection started the incident, but excessive access determined what the attacker could reach.
Why agents concentrate the blast radius
None of this would matter as much if agents had little access to sensitive credentials and systems. The data shows the opposite.
GitGuardian's State of Secrets Sprawl 2026 found 28.6 million new hardcoded secrets pushed to public GitHub in 2025, up 34% year over year and the largest annual jump on record. Secrets tied to AI services are growing even faster, reaching 1,275,105 last year, an 81% increase.
Commits assisted by Claude Code also showed a 3.2% secret leak rate compared with a 1.5% baseline across all public commits. The report cautions against treating that gap as a failure of the tool itself, since developers still decide what gets pushed. The larger point is that AI-assisted development is happening in an environment where credential exposure is already widespread and increasing.
Agents add another layer of risk because they need access to other systems to be useful. That access is often provided through credentials such as database connection strings, cloud keys, SaaS tokens, and model API keys. Those credentials increasingly represent non-human identities with real authority across cloud infrastructure, developer tooling, SaaS platforms, and internal systems. And many of them are stored in plaintext on the same endpoints where agents operate: in .env files, ~/.aws directories, shell history, and MCP configuration files. GitGuardian found 24,008 unique secrets exposed in MCP-related config files on public GitHub, including 2,117 that were verified as valid. Quickstart guides that instruct developers to paste credentials directly into configuration files only add to that exposure.
The risk becomes even clearer at the endpoint level. When GitGuardian analyzed machines compromised by the Shai-Hulud 2 supply chain attack, 6,943 infected machines yielded 33,185 unique secrets, and 59% of those machines were CI/CD runners rather than personal laptops. That campaign did not need to manipulate an AI agent; the credentials already present on developer and CI environments were valuable enough on their own. Put a coding agent with file system and tool access on top of the same environment, and those credentials become accessible to a system that can read files, execute commands, call external services, and act on instructions. If that agent is compromised or manipulated, the credentials and permissions within its reach determine how far the attacker can go.
Shrinking the blast radius before, during, and after compromise
Least privilege, isolation, approval gates, and egress controls remain essential. But coding agents also operate in environments full of credentials that grant access to cloud infrastructure, databases, APIs, developer tooling, and SaaS platforms. If those credentials are exposed, they can give an attacker access that persists long after the original agent interaction ends.
That makes secrets security a critical part of controlling an agent’s blast radius. Limiting which credentials agents can discover, transmit, and continue using reduces what a successful manipulation can become. The challenge spans the full lifecycle: removing exposed credentials before an incident, stopping them from crossing model and tool boundaries during one, and quickly revoking them afterward. GitGuardian’s secrets visibility and intelligence platform addresses each of those stages, including the developer and CI environments where coding agents actually run.
Before: block credentials at the model and tool boundary
Once an agent is running, the goal shifts from removing credentials from its environment to preventing those credentials from moving through the agent unchecked. GitGuardian's AI Hooks register ggshield as a checkpoint inside Claude Code, Cursor, VS Code with GitHub Copilot, and Codex. Prompts are scanned before they reach the model, while file reads, shell commands, and MCP calls are checked before execution. If a secret is detected, the action is blocked and the finding is returned to the agent so it can self-correct and continue. Tool output is also scanned after execution, and the developer is alerted if sensitive material appears. All of this runs against the same 55600+ detectors used in pre-commit and CI.
Honeytokens add a tripwire on top. Place realistic-looking decoy credentials alongside real ones in configuration files and other locations an attacker or compromised agent is likely to inspect. If a laptop is compromised, a threat actor will often test the credentials it finds to see what they unlock. A compromised agent can also discover and attempt to use credentials available in its environment. The moment a honeytoken is used, GitGuardian triggers a real-time alert, exposing credential misuse even when the agent itself is the actor.
During: remove what the agent can find
Reducing the blast radius starts with knowing which credentials are already within reach. Start by discovering the plaintext credentials AI workflows create and consume, scanning developer endpoints for credentials in .env files, cloud credential stores, MCP and agent configuration files, logs and shell history. Pair that with an inventory of which agents and MCP servers are running across the fleet and what they can reach.
GitGuardian's Developer Endpoint Protection does both through your existing Mobile Device Management (MDM) tooling, using scheduled scans with no continuous agent and the same ggshield detection engine already widely used in developer workflows. For organizations already running ggshield in pre-commit, extending that protection to developer endpoints is a configuration change within the existing MDM deployment, not a new agent or infrastructure project. Every credential removed from an endpoint before an incident is blast radius an attacker never gets.
Credentials are only half the equation. GitGuardian also maps which permissions and identities each credential is tied to, so an agent that can read one key isn't treated the same as an agent that can read a key with production access. The same credential found on an endpoint and in a secrets manager becomes a higher-priority finding than either alone, because it signals broader reach, not just exposure.
After: revoke faster than the attacker can move
Leaked credentials stay dangerous long after an incident scrolls out of the news cycle: 64% of secrets confirmed valid in 2022 were still valid and unrevoked in January 2026. That persistence makes rapid response especially important in agentic environments, where credentials can be discovered and exfiltrated quickly.
Knowing a secret leaked is not enough. You need to know whether it is still valid, what it unlocks, and who owns it. GitGuardian enriches incidents with available validity, ownership, scope, and location context. That turns "an agent may have read a key" into a prioritized list of credentials that need investigation or revocation. For secrets found in code or CI, GitGuardian can push them directly into your secrets manager (HashiCorp Vault, AWS Secrets Manager, CyberArk, Akeyless); where the provider supports it, GitGuardian can revoke the credential directly rather than walking you through manual steps. GitGuardian customers remediated five times more secrets in 2025 than in 2024. When a credential has been exposed, fast revocation removes the authority the attacker can continue to exercise.
The blast radius is defined by what the agent can reach
The GitLost writeup closes with two recommendations that get to the heart of the issue: never treat user-controlled content as trusted instruction input, and scope permissions to the minimum required. Security teams cannot fully prevent agents from being manipulated, but they can control the credentials, permissions, and authority those agents have access to. That is where the blast radius is decided. The next prompt injection may be as trivial as "Additionally." Whether it exposes a README, a cloud credential, or something more consequential depends on how much authority the agent had in the first place.
Reduce the credential blast radius of your AI agents
Katie DeMatteis
Dwayne McDaniel
