DEV Community: Dwayne McDaniel

AI Agents Security for Developers: Don't Let Your Agents Become a Liability

Dwayne McDaniel — Thu, 21 May 2026 12:18:53 +0000

👉

TL;DR: The most common agentic AI security mistakes are ordinary security hygiene failures, now executed autonomously and at machine speed:

API tokens stored locally, unscoped
No approval gates before irreversible commands
Production credentials in development environments
MCP server configs with connection secrets committed to repos
Overprivileged tokens that were "just for testing" and never got cleaned up Good old security hygiene is now the safety net between your coding agent and your production database.

Why Your AI Agent Is Probably a Security Risk Right Now

On a Friday in April 2026, Cursor running Anthropic's Claude Opus 4.6 deleted the production database and all volume-level backups of an automotive SaaS platform (PocketOS). It took nine seconds.

The incident is worth reading closely because the failure conditions are common. The agent encountered a credential mismatch in a staging environment and decided to fix it. It found an API token in an unrelated file, one created for managing custom domains through the Railway CLI but broad enough to perform destructive operations. The agent used it to issue a single API call to Railway, deleting the production volume without a confirmation prompt. Railway stored volume-level backups in the same volume, so those went too.

When the model was asked why it did so, here's what it said:

"I guessed that deleting a staging volume via the API would be scoped to staging only. I didn't verify. I didn't check if the volume ID was shared across environments. I didn't read Railway's documentation on how volumes work before running a destructive command. On top of that, the system rules I operate under explicitly state: 'NEVER run destructive/irreversible git commands unless the user explicitly requests them.' Deleting a database volume is the most destructive, irreversible action possible -- and you never asked me to delete anything."

The agent did not create the problem. The exposure already existed in the form of an overprivileged API key.

The mental model many developers are still missing is simple: when you use a coding agent, it operates as you, in your environment, with your credentials. It can read project files, inspect environment variables, and run commands with whatever permissions your tokens carry. If you have a root-scoped token sitting in a config file from six months ago, your agent might find it. Unlike a human developer who would probably recognize it as unrelated, a coding agent under pressure to fix a problem may simply use it.

Secrets sprawl before deploying LLMs has been a documented risk since AI integrations first showed up in production environments. The difference is the actor. Your credentials are no longer accessed only by you, at human speed, with human judgment. They are now accessible to a coding agent that can act at machine speed and does not always stop to ask.

The old assumptions no longer hold. Your development credentials are available to whatever agent you let operate in that workspace. A test token is harmless only until the agent finds a use for it. A cleanup task can wait for a human, but it will not wait for software that can act before you notice the risk.

Start With What Your Agent Can Reach

Start with the question that matters before the agent runs: what credentials are reachable from this workspace?

Before opening a project in an agentic coding tool, audit the credential surface:

.env files
shell profiles
local config files
MCP server configs
cloud CLI credentials
package manager tokens
old notes, scripts, and Makefiles

If the agent can read it, assume the agent can use it. The agent's workspace should contain only credentials that are safe for the task at hand.

In practice, development credentials should be separate from production credentials, scoped to the narrowest useful action, and rotated when the work ends. If a token can delete a production database, it does not belong in a routine development environment where a coding agent is operating.

Secret scanning belongs directly in that workflow. Pre-commit hooks are especially useful for coding-agent users because they catch credentials in generated code before the agent or developer commits them. PR scanning and CI/CD scanning provide additional layers, but pre-commit is where you stop the mistake closest to the source.

GitGuardian can cover each of these surfaces, including local pre-commit scanning, repository monitoring, CI/CD exposure, MCP configuration files, and credentials surfaced in agent-generated code. Scanning is not a replacement for least privilege. It catches the moment when the agent writes, copies, or exposes something it should not.

Use Better Credential Patterns When the Agent Writes Code

There are two credential problems to watch: what the agent can already reach, and what it writes into your application.

When a coding agent generates integration code, review the authentication pattern it chooses. Agents optimize for getting the task done. They may reach for a static API key because it is easy, familiar, and present in nearby examples. That does not make it the right pattern.

Prefer this order:

1. Workload identity or managed identity. For cloud-native applications, use the platform's native identity system wherever possible. AWS IAM roles, GCP Workload Identity Federation, and Azure Managed Identity all avoid storing long-lived static credentials in code or config.

2. OAuth with short-lived, scoped tokens. For SaaS integrations, request only the scopes the application needs and use dedicated app registrations per integration. OAuth assumes client behavior can be anticipated, but agent-written systems often compose behavior dynamically. Narrow scopes are your blast radius limiter.

3. Vault-issued dynamic credentials. For databases, internal services, and infrastructure, use a secrets manager that issues scoped, time-limited credentials at runtime. HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault all support patterns that avoid hardcoding credentials into the application.

4. API keys with strict controls. Some APIs still only support API keys. In that case, use one key per service integration, store it in a vault or inject it at runtime, set the shortest reasonable lifetime, and monitor for exposure. For vault storage, rotation scheduling, and scoping patterns, API key management best practices is the reference to start with.

Hardcoded secrets are the pattern to reject: credentials embedded in source code, committed .env files, prompt templates, config files, or examples that the agent can imitate. If an agent generates code with hardcoded credentials, fix the immediate output and then check whether it learned that pattern from the existing codebase.

Also look at secret handling in logs and caches. Agents sometimes write debug statements that print retrieved secrets or cache credentials beyond their intended lifetime. The authentication pattern may be sound while the generated implementation still leaks the credential.

Securing MCP Server Connections: The New Attack Surface

Coding agents like Claude Code and Cursor increasingly use MCP (Model Context Protocol) to connect to external tools: databases, APIs, file systems, and services. Configuring MCP servers means making credential decisions that affect every tool call your agent makes.

The common mistakes are familiar: secrets stored directly in JSON or YAML config files, admin-level database access when read-only access would be enough, and shared MCP configurations reused across projects or team members. In each case, the MCP server turns a local coding assistant into an authenticated actor against an external system.

Store MCP connection credentials in a secrets manager, not in configuration files. This is the same principle behind building a secure LLM gateway with MCP: the agent should reference credentials through a controlled layer, not hold them directly. Inject values as environment variables at runtime. Scope each MCP server to the minimum required access. If the agent only needs to read from a database, configure read-only access.

MCP configs deserve the same treatment as application secrets. Exclude sensitive local configs from version control, scan repositories that contain MCP setup files, and review generated MCP configuration before accepting it. Coding agents can write these files for you, and they do not always follow the safer pattern by default.

The Developer Checklist

The practical controls are not complicated. The hard part is applying them before the agent starts acting.

Before running a coding agent in a project

Audit credentials in the project directory and development environment
Remove production credentials from routine development work
Scope API tokens to the minimum required operations
Separate development, staging, and production credentials
Install pre-commit secret scanning hooks

While the agent is working

Review generated code for hardcoded credentials
Require explicit confirmation before destructive operations
Do not paste raw credentials into prompt context
Watch for unexpected API calls, logs, or generated config changes
Treat MCP configs as sensitive files

In CI/CD and automated workflows

Inject secrets through CI/CD secret stores
Use OIDC for cloud access instead of static cloud keys where possible
Scan pipeline logs and artifacts
Apply the same review standards to agent-generated commits as human commits

After the work ends

Revoke task-specific tokens
Rotate credentials that may have been exposed
Remove stale MCP server entries
Review whether the agent's environment still contains only what it needs

Do Not Treat Prompt Rules as Security Controls

The PocketOS incident is useful because the agent reportedly had an instruction not to run destructive commands. It ran one anyway. System prompts can still shape behavior, slow the agent down, and make safer workflows more likely. They are reminders, not authorization boundaries.

Security controls should live where the action happens. If a command can delete a production database, the API should require confirmation, the token should be scoped away from production, or the tool should force human approval before the call executes. If a database connection is only needed for inspection, the credential should be read-only. If a CI/CD job only needs to deploy one service, its identity should not be able to modify unrelated infrastructure.

Prompt rules are the last layer. They do not replace scoped tokens, environment separation, approval gates, immutable backups, or secret scanning. This distinction matters because developers often notice the model's behavior first and the credential design second.

The safer habit is to ask: "If the agent ignores every instruction, what can it still do?"

That question turns agentic AI security back into normal security engineering: limit privileges, remove stale credentials, detect exposures early, require confirmation for irreversible actions, and keep production separate from development.

What's Coming: Agent Security Challenges on the Horizon

Coding agents in CI/CD. As agents move from local dev tools to automated pipeline actors, the credential exposure surface grows. An agent in CI/CD may have access to pipeline secrets, deployment permissions, and repository write access.

Self-provisioned credentials. More capable agents may create API keys and service accounts when they need access to a new service. If an agent creates a root-scoped token to get something done faster, you need to know.

MCP ecosystem expansion. As the MCP ecosystem grows, developers will connect coding agents to more external services, each with its own credentials. A well-connected coding agent can accumulate a serious credential surface before anyone has named it as one.

Prompt injection as credential exfiltration. A malicious input that manipulates a coding agent into revealing, logging, or exfiltrating credentials is an active research area and an emerging attack chain. If your agent reads untrusted content, such as external documentation, third-party code, or user-provided files, and also has access to credentials, those two facts together create a risk. The best mitigation today is limiting what credentials the agent can reach, not relying on the agent to recognize manipulation.

The next serious agent incident probably will not look exotic. It will look like a token left in the wrong place.

FAQs

1) What are the biggest AI agent security risks for developers using coding agents?

The biggest risks are overprivileged credentials in development environments that coding agents can find and use autonomously. Hardcoded or unscoped API tokens, production credentials accessible during dev work, committed MCP configs, and no approval gates for destructive operations are the failure modes that cause incidents.

2) How should I authenticate my AI agent to external APIs?

When your coding agent writes code that integrates with external APIs, push it toward workload identity for cloud-native environments, OAuth with short-lived scoped tokens for SaaS integrations, or vault-issued dynamic credentials for internal services. In your dev environment, audit every credential accessible to the agent and ensure it is scoped to the minimum required operations.

3) How do I secure MCP server connections?

Store MCP connection credentials in a secrets manager and inject them as environment variables at runtime. Do not embed them in config files. Scope each MCP server to the minimum access required. If your coding agent only needs to read from a database, configure read-only access. Scan repositories containing MCP configurations for accidentally committed secrets.

4) How do I prevent my AI agent from leaking secrets?

Coding agents can surface credentials in generated code, logs, and artifacts. Use pre-commit hooks to block secrets before they enter the repository, review generated code before committing, and avoid passing raw credentials through prompt context.

5) Should I give my coding agent access to production credentials?

No. Coding agents should operate in development and staging environments with credentials that are physically incapable of affecting production. If a production incident requires debugging with an agent, make that a deliberate, audited exception, not the default state of your environment.

6) How do I handle token rotation when I'm using coding agents?

Coding agents increase the surface where credentials are accessed and potentially exposed, which makes rotation discipline more important. Automate rotation where possible, set expiration dates when creating tokens, and rotate immediately after suspected exposure.

7) What should I do when an AI coding agent causes a credential-related incident?

Revoke the credential immediately at the issuing service. Assess what the credential permitted, check audit logs for activity during the exposure window, and investigate how the credential became accessible to the agent. Then fix the control failure: scoping, environment separation, approval gates, or scanning coverage.

8) How does secret scanning help with AI agent security?

Coding agents write code, config, and scripts. Secret scanning at the pre-commit stage catches credentials in agent-generated output before they enter the repository. Repository monitoring catches historical exposure, while CI/CD scanning catches credentials in build artifacts. GitGuardian covers these surfaces from local hooks through production monitoring.

How We Got a CISA GitHub Leak Taken Down in Under a Day

Dwayne McDaniel — Wed, 20 May 2026 12:28:33 +0000

On May 14, 2026, GitGuardian found what looked like leaked CISA secrets in a public GitHub repository named Private-CISA. It held 844 MB of data across the working tree and Git history. The working tree was 498 MB; the rest was Git history and objects.

The repository contained:

CI/CD build logs and deployment workflow documentation.
Kubernetes manifests, ArgoCD application files, and secret-related YAML files.
Terraform infrastructure code and related bundles.
GitHub Actions workflows and GitHub organization automation.
Internal documentation backups, including large OneNote / .docx exports.
Scripts for GitHub, Kubernetes, ArgoCD, and infrastructure operations.
References to AWS accounts, IAM identities, service accounts, internal service endpoints, registry locations, and secret-management paths.

The exposed material provided a detailed view into cloud infrastructure, deployment workflows, software supply-chain tooling, and internal operational practices.

At first, we thought it was a hoax, given how suspicious the directory names (Backup-April-2026/, All Backups/, LZ-Artifactory/, Kubernetes-Important-Yaml-Files/, ENTRA ID - SAML Certificates/ ...), file names (external-secret-repo-creds.yaml, CAWS GitHub Token.txt, Important AWS Tokens.txt, AWS-Workspace-Firefox-Passwords.csv, Kube-Config.txt ...), and their contents (private keys, personal and professional GitHub tokens, AWS secrets, ...) seemed too good to be true.

Personal documents, hostnames, and the careful organization of the files changed our minds. The repository was a catalogue of unsafe practices: plain-text passwords, backups committed to Git, and explicit instructions to disable GitHub's secret scanning

Our research team reported the leak through the CERT/CC portal on May 14 at 4:14 PM CET and worked personal contacts in parallel to speed disclosure.

GitGuardian Public Monitoring surfaced the leak first. By May 13, our Good Samaritan program had already sent nine emails to the commit author.

By the morning of May 15 we still had only the automatic acknowledgment. With the weekend approaching, we contacted Brian Krebs to forward the leak to his CISA contacts, and activated partners for a direct line in.

Around 16:00 CET on May 15 we reached CISA directly. The repository went offline around 6:00 PM EST on May 15, 2026. Seeing the repository taken down so fast was a relief. Credit to CISA for moving fast — most of our disclosures take far longer, and some are never fixed.

Disclosure Timeline

November 13, 2025 - Creation of the public Private-CISA Github repository and first exposures
May 14, 2026 - Incident detected by GitGuardian and reported to CERT/CC
May 15, 2026 - Incident directly reported to CISA by GitGuardian
May 15, 2026 - The Private-CISA GitHub repository is taken offline

The Future Of GitHub Actions Security And What You Can Do Right Now

Dwayne McDaniel — Tue, 19 May 2026 13:15:27 +0000

GitHub's new Actions security roadmap is a sign that the industry has finally accepted something many defenders have been saying for years: CI/CD is no longer a convenience layer. It is production and identity infrastructure, and it's secret-bearing. When it is compromised, the attacker does not just get a build. They get a path into source code, publishing systems, cloud environments, and the trust chain behind software delivery, as we have seen with several recent attacks.

GitHub is describing a structural shift in how Actions will work: deterministic workflow dependencies, centralized execution policy, tighter secret scoping, better telemetry, and native outbound network controls for hosted runners. Less ambient trust, fewer implicit permissions, more infrastructure-level control over what automation can do.

Most organizations are still operating in the messy reality where their workflows are already live, with their secrets already distributed across repositories, CI systems, collaboration platforms, registries, and cloud tooling. GitHub is building toward a safer actions platform. In the meantime, teams still need visibility, detection, and remediation for the environment they have today.

Changing The Trust Model

For a long time, GitHub Actions security has relied heavily on teams getting the YAML right. Pin your actions, avoid risky triggers, be careful with pull_request_target, scope your secrets tightly. All of that guidance still matters, but it has always placed a lot of burden on local workflow authors. The roadmap shows GitHub moving that burden upward into the platform itself.

One of the clearest examples is dependency locking for workflows. GitHub plans to add a dependencies section so workflows can lock direct and transitive dependencies to specific commit SHAs, with verification before jobs execute. That turns Actions dependencies into something closer to a managed dependency graph than a loose set of runtime references.

Recent supply chain attacks have repeatedly shown how dangerous mutable trust can be. A workflow that references an action by tag is convenient, but it's also a place where trust can drift. GitHub's roadmap effectively admits that convenience-first CI/CD needs stronger guardrails.

Execution policy is becoming a first-class control

Another major change is workflow execution protections built on GitHub rulesets. Many CI/CD incidents are not about one dramatic bug — they are about context collapse. The wrong actor triggers the wrong workflow on the wrong event, and suddenly an untrusted path gains access to trusted capabilities.

GitHub's planned controls let organizations define who can trigger workflows and which events are permitted, with organization-level policy instead of per-file guesswork. That means security teams can set boundaries around things like workflow_dispatch, push, and pull_request, and evaluate those policies before enforcement.

This is the platform catching up to reality. CI/CD risk is governance risk. It is not just syntax risk.

Secrets are being treated as contextual assets instead of shared utilities

The roadmap's changes around secrets may be the most important operationally. GitHub plans to introduce scoped secrets so credentials can be bound more precisely to repositories, branches, environments, workflow identities, and trusted reusable workflows. Secret management will no longer automatically ride along with repository write access.

This reflects a broader truth in modern software delivery: a secret is never just a string. It represents access, authority, and potential lateral movement. Once it leaves its intended lane, the problem is no longer limited to CI.

Better secret scoping inside Actions will help when it lands. It will not clean up the existing sprawl of tokens, API keys, service credentials, and cloud secrets already scattered across the rest of the development environment.

The near-term gap is not theoretical

GitHub's roadmap addresses a real pattern. Recent incidents involving tj-actions/changed-files, Nx, and trivy-action all followed the same pattern: attackers compromise the automation layer, harvest credentials, then use those credentials to expand access and impact.

The real question for defenders right now: while these new Actions controls are being built and rolled out, how do you reduce risk in the environment you already have?

GitGuardian helps with the environment teams actually have today

GitGuardian's Secrets Security and NHI Governance platform is built on the fact that secret exposure is rarely confined to a single repository or control plane. The platform scans across a broad set of internal sources where credentials may appear — version control systems, container registries, documentation platforms, messaging systems, package registries, and other connected systems. It is critical to think past the Git repo and consider anywhere an attacker is looking, including developers' local machines.

A leaked token may start in code, then show up in CI logs, then be pasted into a ticket, then remain duplicated in a collaboration thread. Security teams need a way to find the credential wherever it traveled.

Detection and remediation still matter even when prevention improves

Better prevention changes the rate of new incidents. It does not automatically resolve the backlog of existing exposure, nor does it remove the need for fast incident response during active compromise.

GitGuardian supports both detection and automated remediation — investigating incidents, validating risk, assigning ownership, and driving remediation.

That workflow becomes even more useful during supply chain incidents, where the central problem is often not just that code was tampered with, but that credentials may already have been harvested, reused, or staged for later abuse.

Honeytokens fit the current moment especially well

GitHub plans to improve observability with an Actions Data Stream and a native egress firewall for GitHub-hosted runners — both roadmap items.

If you need an earlier warning system in the meantime, GitGuardian Honeytoken can help. Honeytokens are decoy credentials that track unauthorized usage, with a specific emphasis on DevOps pipeline security and supply chain attack detection. Place monitored fake credentials where an attacker searching for real ones is likely to find them, then alert when those credentials are touched.

Attackers who compromise build and automation systems often go hunting for secrets very early. A honeytoken gives defenders a chance to detect that behavior before the attacker has turned a workflow compromise into something larger.

A Governance Story About Non-human Identities

Software delivery systems are now full of non-human identities making privileged decisions. Workflows authenticate to APIs. Actions call cloud services. Build systems publish artifacts. Bots trigger pipelines. Reusable workflows inherit trust from one repository to another. All of that adds up to a dense machine-to-machine access environment mediated largely by secrets.

GitHub is improving that environment from the platform side. GitGuardian NHI Governance helps organizations discover where the keys to those lanes already lie, who owns them, where they have spread, and what needs to be fixed first.

What Changes Now For Defenders

The main takeaway from GitHub's 2026 Actions security roadmap: CI/CD security is becoming more explicit, more policy-driven, and more infrastructure-aware. Deterministic dependencies, scoped secrets, execution protections, telemetry streams, and outbound network controls all reflect a more mature model for securing automation.

But the immediate defender takeaway is simpler. You do not need to wait for the roadmap to become generally available to start reducing risk.

You can reduce the ambient spread of secrets now.
You can monitor the broader internal ecosystem now.
You can tighten remediation around exposed credentials now.
You can place early warning tripwires for attacker behavior now.

That is where GitGuardian fits in this transition. GitHub is building a safer future state for Actions. GitGuardian helps security teams operate safely in the current state, where secrets are already distributed, workflows are already trusted, and attackers are already treating CI/CD as a high-value target.

Vercel April 2026 Incident: Non-Sensitive Environment Variables Need Investigation Too

Dwayne McDaniel — Mon, 18 May 2026 12:41:25 +0000

Vercel's April 2026 breach started with Context.ai, a third-party AI tool.

An attacker compromised the tool's Google Workspace OAuth app, hijacked a Vercel employee's account, then accessed environment variables that weren't marked "sensitive." Vercel is now asking customers to rotate those secrets, even though they were classified as non-sensitive.

Vercel contacted the limited subset of customers whose credentials were confirmed compromised. But the broader lesson applies to any organization: a third-party OAuth compromise can cascade into internal systems fast. Vercel called the attacker "highly sophisticated" based on their speed and detailed knowledge of Vercel's systems.

Investigate, Then Rotate

Assume any related secret is at risk until you've investigated it. Identify every exposed credential, check where it's used, and confirm whether it's active or already abused. Then revoke or rotate it, redeploy, and verify dependent services.

Vercel's guidance is direct: use the "sensitive" flag for environment variables that contain API keys, tokens, database credentials, or signing keys. Sensitive variables are stored in a way that prevents them from being read.

Scan Your Environment Variables

If you're a Vercel customer responding to this incident, start by pulling your environment variables locally and scanning them for exposed secrets.

Pull your environment variables for each project:

vercel env pull

Then scan the file with GitGuardian:

ggshield secret scan path .env.local

See: How To Use ggshield To Avoid Hardcoded Secrets

GitGuardian will identify which variables contain valid secrets — API keys, tokens, database credentials, signing keys. This gives you a prioritized list of what to rotate first. You can also scan across multiple projects by pulling each environment file and scanning the directory:

ggshield secret scan path .

Once you've identified exposed secrets, rotate them in your upstream services (like AWS, Stripe, or database providers) before updating the values in Vercel.

Harden Controls for the Next Incident

Vercel published the following guidance for customers:

Review the activity log for your account and environments for suspicious activity — in the dashboard or via the CLI.
Review and rotate environment variables. If any contain secrets (API keys, tokens, database credentials, signing keys) that were not marked as sensitive, those values should be treated as potentially exposed and rotated as a priority.
Take advantage of the sensitive environment variables feature going forward, so that secret values are protected from being read in the future.
Investigate recent deployments for unexpected or suspicious looking deployments. If in doubt, delete any deployments in question.
Ensure that Deployment Protection is set to Standard at a minimum.
Rotate your Deployment Protection tokens, if set.

The Bot Left a Fingerprint: Detecting and Attributing LLM-Generated Passwords

Dwayne McDaniel — Fri, 15 May 2026 13:15:27 +0000

In February 2026, researchers at Irregular published a detailed post about LLM-generated passwords, showing how passwords generated by LLMs follow notable patterns and are generally highly predictable.

The root cause is fundamental: LLMs are optimized to predict probable outputs, which is the exact opposite of what secure password generation demands.

That observation raised a natural follow-on question: if LLMs leave statistical fingerprints in the passwords they generate, can those fingerprints be detected and attributed? Can we look at a password found in a leaked dataset and say which model generated it? More importantly, can we measure how widely those LLM passwords are used in the wild? That is what this research set out to answer.

Extending the perimeter

We extended the scope of the analysis to 40 LLM models from 11 providers, including both closed-source (OpenAI GPT, Anthropic Claude, etc) and open-source (Qwen, DeepSeek, etc) models. We increased the password sample size to 200 for better statistical accuracy, generating a total dataset of 8,000 passwords.

An initial analysis confirmed the original findings: we observe a bias in generated passwords, inconsistent across models:

Anthropic's models show poor uniqueness: Claude Opus 4.6 is the worst, with only 35% of unique passwords.
Open-source Qwen, Llama, and Gemma models show between 50 and 60% uniqueness.
The GPT-5 family generates only unique passwords.

The uniqueness of generated passwords does not guarantee their security. Generated passwords tend to follow similar patterns and use common substrings. Nearly all models follow the same "upper, digit, symbol, lower" pattern repetition:

Anthropic models lock position 0 firmly: claude-opus always starts lowercase (100%), claude-haiku and claude-sonnet-4.6 always start uppercase (100%).
Llama models are 99–100% uppercase at position 0.
GPT-4.1-mini is 92% uppercase at position 0.

All models exhibit a strong statistical deviation from random. The most common substrings per model (factor vs. random in parentheses):

gpt-5.2: the 7! bigram in 52% of passwords (x4.5k) and vQ7!mZ substring in 6% (x41B)
Mistral-medium-3.1: the x7#pL9 substring in 65% of passwords (x448B)
Llama-3.3-70b-instruct: the 8d bigram in all passwords, and Gx#8dL in 96% — the worst score of all models.

Interestingly, some substrings are shared across multiple providers:

The L2 bigram appears in passwords of 10 out of 11 providers, with an average probability of 27% (x114)
The #kL9 substring appears in passwords from 4 providers (mistralai, deepseek, qwen, openai) at an average probability of 13% (x954M)

Fighting robots with a rusty sword

The previous results suggested that modeling LLM-generated passwords could be done using Markov chains — a mathematical model introduced by Russian mathematician Andrei Markov in 1906, a full 100 years before LLMs.

For password recognition, a Markov chain can be as simple as:

One state for each letter of the alphabet
Transitions set to the probability of encountering a character after the current state

We used the LLM-generated password sample to build multiple Markov chains:

One chain per selected model
One chain per model family or provider
One chain aggregating the whole LLM password dataset

Results:

The chains identify the right model in 55% of cases and the correct provider in 65% of cases.
The generic chain was, on average, half as surprised when seeing an LLM-generated password as when seeing a random value or generic password.

Hunting bot passwords in the wild

We classified a sample of passwords collected by GitGuardian's public monitoring platform: 34 million passwords observed on GitHub between November 2025 and March 2026.

In a conservative approach, we considered a password LLM-generated if:

A model-specific chain predicts it with >75% confidence
A provider-specific chain predicts it with >75% confidence
The general chain sees the password with a perplexity level <100

(We excluded xAI models because they often generate non-random-looking passwords like P@ssw0rdS3cur3!2023, which would capture weak human-generated passwords.)

With this method, we classified 28,000 passwords as LLM-generated. The most predicted providers are Anthropic, Qwen, and Google — representing 63% of all occurrences.

Provider	Count
Anthropic	7951
Qwen	6643
Google	3184
OpenAI	2812
Amazon	2661
Mistralai	1710
Meta Llama	1498
Cohere	1405
Deepseek	182
Microsoft	91

Anthropic passwords are the most certain candidates, with an average confidence level of 92%.

LLM-generated passwords have been committed consistently at an average rate of 1,500 per week during the study timeframe.

The passwords are mostly contained in JSON files, but a significant proportion are hardcoded in source and configuration files. 1,800 .env files were found to contain at least one LLM-generated secret — including application security keys, encryption keys, and passwords for third-party services.

# Company AWS Services Configuration
USE_AWS_SERVICES=true
AWS_REGION=us-east-1

# Database
DATABASE_PASSWORD=Kx9mP2vQ8nR5tY7w

A typical LLM-generated password used to connect to a database.

"lx01" = {
  name     = "lx01"
  password = "x7QpL2n9V8F5"
}

A typical LLM-generated password used as the default password of Terraform-generated machines.

Among the 8,700 commits containing a predicted Anthropic-generated password, 41 are announced as co-authored by Claude — validating that AI Agents can independently generate and hardcode passwords in code.

What this means in practice

The prevalence of LLM-generated passwords is not widespread when compared to total leaked passwords. But two behaviors are worth noting.

Some people are using LLMs as password generators

We observed LLM-generated passwords used in connection strings to web and database services. Unless the coding agent configured those services, a user purposely asked an AI to generate their password.

Asking an AI agent to generate a password is a bad practice. The password transits through the network, the LLM provider will know it, and it might end up logged in an agent log file — leaked before even reaching the developer's machine. And as we've shown, those passwords will be weak and mostly predictable.

AI Agents autonomously generate and hardcode passwords

We observed LLM-generated passwords hardcoded in Terraform files and committed by AI agents. While not widespread, this behavior exists — and even if the code isn't publicly leaked, the password predictability enables efficient online enumeration.

This risk should be taken into account when designing your AI security policy. Some of the passwords in this category were generated using flagship models, so the issue isn't limited to older or entry-level models.

Attacking and defending

Markov chains could also be used to attack LLM-generated passwords with much higher efficiency than brute-force. Common password-cracking tools already implement a Markov mode:

$ calc_stat opus_46.passwords opus_46.john.stats

$ vim john.conf
[Markov:opus46]
Statsfile = opus_46.john.stats
MkvLvl = 400
MkvMaxLen = 20
MkvMinLen = 16

$ john --markov=opus46 --stdout
k7$Lm9#Qx2vP!nW4rT&jR&j
k7$Lm9#Qx2vP!nW4rT&jR&8
[...]

John The Ripper generating Opus 4.6-looking passwords.

On the defender side:

LLMs should not be used as password generators. Use a vault, password manager, or dedicated tool.
Agent-generated passwords require tight guardrails. GitGuardian's ggshield now supports scanning AI agent hook events for secrets — as simple as:

$ ggshield install -t cursor -m global
$ ggshield install -t claude -m global

Setting up ggshield to scan Claude and Cursor hook events for secrets.

It's a small step, but given what's at stake, it's one no team shipping AI-assisted code can afford to skip.

GitGuardian Now Flags Admin and Overprivileged Identities Across AWS, Entra, and Okta

Dwayne McDaniel — Thu, 14 May 2026 13:41:39 +0000

Not all leaked secrets carry the same risk. A leaked credential attached to a read-only logging job is more of a hygiene issue. The same credential attached to an AdministratorAccess role hands an attacker complete control of the account. Treating both incidents identically in the queue wastes responder time on the first and delays action on the second.

GitGuardian's latest NHI Governance release introduces privilege context as a first-class signal in the platform. The system now identifies which machine identities hold admin-level rights, surfaces those that have accumulated more permissions than they actually use, and automatically escalates the severity of incidents landing on those high-impact identities. Your remediation queue starts to reflect the real blast radius of each finding.

The missing dimension in NHI risk

Most security teams have spent the last few years getting a grip on where their non-human identities live. Service accounts, OAuth apps, CI/CD tokens, IAM roles, and agentic AI workloads now sit inside inventories that were unimaginable three years ago. The OWASP Top 10 for Non-Human Identities formalized the obvious risk patterns, including leaked secrets, reuse, long-lived credentials, and broken offboarding.

Inventories still lacked one further dimension: the blast radius of each identity. An overprivileged NHI amplifies every other risk attached to it. A reused secret on a global admin account exposes the entire tenant. Recognizing that distinction at scale used to require manually crawling through IAM policies, directory role assignments, and custom permission sets. That work struggles to keep up across thousands of identities and multiple clouds.

Customer conversations repeatedly surfaced the same asks: visibility into orphaned and overprivileged accounts, real-time tracking of agent permissions, and a way to detect when a workload sits on more access than its job requires. AI agents now connect to trading systems and production data stores, raising the cost of unanswered privilege questions every quarter.

The Admin badge

When NHI Governance maps the permissions attached to an identity and finds an admin or equivalent role, that identity now carries an explicit "Identity level: Admin" badge in the inventory and detail view. Detection runs on well-known role and policy markers across AWS IAM, Microsoft Entra, and Okta.

AWS coverage surfaces managed policies such as AdministratorAccess, PowerUserAccess, and IAMFullAccess, alongside inline statements that grant Action: * on Resource: *.

Entra coverage spans directory roles like Global Administrator, Privileged Role Administrator, and Application Administrator, plus Azure RBAC roles such as Owner and Contributor, and high-privilege Microsoft Graph permissions like RoleManagement.ReadWrite.Directory.

Okta detection covers the built-in Super Admin role and custom admin role assignments.

The badge appears wherever the identity is listed, giving security and platform teams a single visual signal that a leak, a reused key, or a broken offboarding event sits on top of full account-level access.

The Overprivileged Identity policy

Admin status answers a binary question. Overprivilege sits in the messier middle, where identities accumulate permissions far beyond what their workloads actually require. The new Overprivileged Identity policy flags permission sets that have drifted. Detection covers wildcard actions, sweeping resource scopes, and large bundles of high-privilege graph grants. The effect over time is a steady push back toward least privilege for the long tail of NHIs that grew bigger one ticket at a time.

Risk criticality that reflects the blast radius

When a policy breach affects an admin NHI, its severity is automatically raised one level, with critical as the maximum. For example:

An internally leaked secret previously registered as high on an admin identity now registers as critical.
An overprivileged finding on a non-admin identity stays at medium. On an admin identity, the same finding moves to high.
Improper offboarding of an admin identity is rated critical rather than high.

The model is layered. A base severity per policy breach forms the foundation, with modifiers stacking on top for admin status and, where relevant, production exposure. The dashboard now aligns with how seasoned incident responders naturally triage.

A worked example

Imagine GitGuardian finds an internal secret leak in a private repository. The secret belongs to an Entra application registered with RoleManagement.ReadWrite.Directory — a permission that allows the app to grant itself any directory role. Without privileged context, the incident surfaces as a high-severity internal leak, sandwiched among hundreds of similar findings on read-only services.

With this release, NHI Governance recognizes the application's admin-equivalent rights, tags it with the Admin badge, and bumps the incident to critical. The responder opens the queue, finds the critical at the top, and acts on the priority the new severity reveals: rotate the secret, audit recent role assignments, and check for newly granted application permissions.

Three moves to put this to work this week

Sort your inventory by risk criticality. The identities your program should worry about most now rank at the top of the view, ahead of the long tail of low-impact noise.

Filter by Identity level: Admin and run an access review. Every admin NHI deserves a named owner, a documented purpose, and a rotation plan. Identities missing any of those three controls form your immediate remediation list.

Surface Overprivileged Identity breaches and pair the filter with environmental context. Overprivileged identities in a sandbox slot into the backlog. The same identities in production belong to this sprint.

From privilege context to better prioritization

Privilege has always been a missing axis in NHI risk. Stamping admin status onto an identity does the unglamorous work of separating the five incidents that could compromise an entire cloud account or directory tenant from an inventory of hundreds or thousands of incidents. With this release, NHI Governance moves that distinction from tribal knowledge into the product — across AWS, Entra, and Okta — inside the same workflow security teams already use every day.

Future increments will build on this foundation. Privilege escalation paths and usage-based overprivilege detection will extend the same model with stronger signals and additional API integrations. The most valuable action available today is opening NHI Governance, sorting by risk criticality, and seeing which identities the security team has been quietly under-prioritizing.

Available today to NHI Governance customers. Read the release note or the admin identities documentation for setup details.

Identity Access Management Strategy for Non-Human Identities

Dwayne McDaniel — Wed, 13 May 2026 13:00:01 +0000

TL;DR: Non-human identities now represent the majority of active identities in cloud-native enterprises. Most security leaders recognize this shift. Still, many organizations rely on an IAM strategy that focuses the majority of its resources on humans. This architectural mismatch creates a significant blind spot. Modern identity and access management strategies must treat non-human identities as governed assets with inventory, scoped authorization, short-lived authentication, continuous exposure detection, and enforceable revocation mechanisms.

Identity Creation Has Moved from HR to Code

In a traditional environment, digital identities originate in Human Resources — a new hire joins, HR triggers a workflow, and the IAM system provisions accounts. The process is linear and human-governed.

In contrast, non-human identities originate from infrastructure and software workflows. This changes the identity lifecycle management process. Common scenarios:

CI/CD pipelines provision roles automatically to deploy code.
Kubernetes generates service accounts dynamically.
SaaS integrations create API credentials outside of any formal IAM review.
AI systems generate new integration surfaces as they interact with other tools.

Identity velocity has increased beyond the speed of traditional governance. Machine identities don't go through approval workflows. When you embed identity creation into engineering workflows, you must integrate it into your identity management strategy. Governance cannot remain a downstream activity.

Scale and Persistence: The Compounding Risk of Machine Identities

Your non-human identity management strategy must account for the fact that these entities operate 24/7. Unlike humans who go home at the end of the day, many machine identities have persistent credentials used around the clock, often without human knowledge.

Machine identities scale automatically with infrastructure. An auto-scaling event could generate hundreds of new instances, each requiring workload identities. These identities rarely trigger lifecycle events — machine identities can linger for months after they finish their primary task.

This creates a structural compounding effect: more automation leads to more service accounts, which leads to more credentials, which leads to more exposure vectors.

Most IAM programs have a key asymmetry: organizations periodically review human access but rarely assess machine access. The result is persistence of privilege without awareness — thousands of identities with access to sensitive data and zero oversight.

Where Traditional IAM Programs Lose Control

Traditional programs assume stable identity populations and HR-driven lifecycles. Non-human identities introduce ephemeral creation, infrastructure-level provisioning, and credential-based authentication outside of standard SSO flows. Ownership is often shared or unclear, making regular access reviews nearly impossible.

Investigate your access management tool and you'll probably find it doesn't:

Discover hardcoded secrets hidden in source code or collaboration tools.
Correlate leaked credentials to specific identities.
Detect orphaned service accounts at scale.
Monitor authentication artifacts outside of standard IdP telemetry.

This is a failure of scope rather than tooling. You must redesign your IAM strategy around the concept of blast radius.

IAM Strategy Is Ultimately About Blast Radius

Every IAM design decision determines the damage a compromised credential can cause and how quickly you can contain it:

Broad roles and rights increase lateral movement risk.
Long-lived tokens increase the exposure window.
Shared credentials eliminate attribution, making breaches harder to trace.
Poor revocability slows your team when stopping an active breach.

The Strategic Pillars of Non-Human Identity IAM

1. Authoritative Identity Inventory

An effective non-human identity management strategy starts with a complete inventory of service accounts, workload identities, federated identities, SaaS integration credentials, and associated secrets. Map each identity to its credential, owner, and access scope. Without mapping, access reviews have no foundation and revocation has no target.

2. Authentication Modernization

Static API keys are common but dangerous. Modern strategies favor OIDC/OAuth 2.0 with scoped delegation, managed identities, workload federation, and certificate-based identity.

Note: Managed identities are cloud-provider-specific constructs (e.g., Azure Managed Identities, AWS instance profiles). Workload identity federation takes a standards-based approach, allowing workloads to authenticate using short-lived tokens without static credentials.

Eliminating static secrets reduces exposure risk — but it won't solve overprivilege. Combine modern authentication with strict access policies.

3. Privilege Containment and Scope Discipline

Service accounts often accumulate privilege over time because broad access is operationally convenient. To counter this: enforce a unique identity per workload, use environment segmentation, and avoid shared service accounts at all costs.

Use minimal IAM role design and remember that least privilege for machines requires continuous reassessment. Role-based access control (RBAC) provides a structured baseline; attribute-based access control (ABAC) enables more granular, context-aware enforcement for dynamic machine workloads.

4. Lifecycle Governance and Rotation Discipline

Automate governance for machines: automated provisioning and deprovisioning, "expiration by default" as standard policy, automated rotation of secrets and certificates.

Your rotation policy is incomplete without exposure detection. If a secret leaks, rotating it every 90 days isn't enough — you need to know about the exposure the moment it happens. Continuous monitoring shortens the compromise window when prevention fails.

5. Continuous Exposure Monitoring

Modern IAM must be continuous. An effective strategy detects real-world credential compromises in repositories, logs, and generated artifacts.

GitGuardian provides continuous monitoring for secret exposure across internal and public environments, correlating discovered credentials to your identity inventory and enabling immediate revocation workflows before compromised credentials are exploited.

According to research, 77% of security leaders fear undiscovered non-human identities in their environments, and 50% of organizations have reported breaches linked to compromised machine identities.

Operating Model: Who Owns Machine Identity Risk?

There's often tension among IAM teams, cloud platform teams, DevSecOps teams, and application owners. Develop a clear ownership model that includes centralized reporting on NHI risk. Executive oversight and shared metrics ensure NHI IAM is treated as a cross-functional architecture, not a narrow security project.

Maturity Roadmap for Enterprise Adoption

Phase 1: Visibility and Risk Baseline — Use secrets security tools to detect exposed secrets and map gaps in your ownership model. Establish your baseline security risks.

Phase 2: Containment and Modernization — Reduce static credentials, implement short-lived authentication, enforce unique identities for every workload, scope privileges as tightly as possible.

Phase 3: Continuous Governance — Integrate NHIs into standard certification cycles, automate secret rotation, continuously monitor for exposure. Define executive KPIs reflecting containment maturity.

The Future of Machine-Centric IAM

We're moving toward AI-generated infrastructure and machine-to-machine trust negotiation. IAM strategies will evolve from static policy enforcement to adaptive identity governance. Companies will standardize identity risk scoring and automated privilege tuning, with secret visibility as a critical input signal for identity risk posture.

The organizations that integrate visibility, scoped authorization, and continuous secret monitoring into their architecture will enable secure automation. Those who don't will experience identity-driven incidents that the right IAM policies could have prevented.

Summary

An effective identity and access strategy shouldn't focus on user authentication alone. It should focus on containing autonomous access at scale. Non-human identities are the primary vector of enterprise attack surface expansion. By integrating visibility, lifecycle governance, and continuous monitoring, you can protect sensitive data and maintain a strong security posture — even as your automation efforts scale.

FAQs

How should IAM programs redefine success metrics for non-human identities?

Track completeness of identity-to-owner mapping, percentage of short-lived credentials in use, exposure-to-revocation time, and reduction of orphaned identities. These reflect containment maturity, not just compliance.

What is the most common architectural mistake in NHI IAM programs?

Treating authentication modernization as sufficient. Replacing API keys with managed identities reduces exposure risk but doesn't solve overprivilege. Strong authentication does not compensate for a lack of least privilege access.

How does secret exposure detection integrate into IAM strategy?

Secret detection provides real-time telemetry about credential compromise outside formal IAM channels. Integrating this exposure data enables rapid revocation and rotation, and allows risk scores to be adjusted based on real-world exposure.

Should non-human identities be included in access certification processes?

Yes, but not through manual quarterly reviews. Certification for NHIs should incorporate automated privilege analysis, activity-based validation, and exposure telemetry.

What differentiates mature NHI governance from basic secrets management?

Secrets management focuses on secure credential storage. Mature NHI governance includes identity inventory, ownership mapping, scoped authorization, automated rotation, exposure detection, and revocation discipline — an architectural control framework, not just a vault implementation.

Top 11 Identity Orchestration Tools and Platforms for 2026

Dwayne McDaniel — Tue, 12 May 2026 12:23:46 +0000

TL;DR: Identity orchestration unifies fragmented IAM environments by connecting identity providers, directories, access policies, and governance workflows into a single, automated control plane. The top identity orchestration tools in 2026 fall into several categories: identity orchestration engines, IAM platforms with orchestration capabilities, identity governance and lifecycle platforms, and secrets security and NHI exposure prevention. Most enterprises need an orchestration layer to unify identity flows and a secrets security layer to ensure credentials and non-human identities (NHIs) aren't compromised.

Why Identity Orchestration Is a Top Priority in 2026

For context, the average enterprise manages identities across 5 to 10+ identity providers, directories, and access management systems.

The result? Fragmented access policies, inconsistent lifecycle management, identity blind spots, and a sprawling attack surface. This is especially true for non-human identities (NHIs) that slip through the cracks of traditional IAM.

This is why identity orchestration — the practice of connecting, coordinating, and automating identity management across multiple systems through a unified control plane — is so important. Rather than ripping and replacing your existing identity stack, identity orchestration software sits above it, enforcing consistent policies, automating lifecycle workflows, and centralizing visibility across all connected systems.

The Need for Identity Orchestration Software

Multi-cloud and hybrid identity sprawl. Organizations running workloads across AWS, Azure, GCP, and on-premises end up with disconnected identity silos.
Legacy-to-modern IAM migration complexity. Many companies run critical applications on legacy systems that depend on LDAP or on-premises Active Directory.
SaaS and third-party integration explosion. Every SaaS tool comes with its own identity requirements.
Non-human identity proliferation. API keys, service accounts, OAuth tokens, and certificates now outnumber human identities in most enterprise environments.
Zero-trust architecture requirements. Zero trust demands continuous verification and centralized policy enforcement across every identity interaction.
Compliance complexity. Meeting SOC 2, ISO 27001, and PCI DSS requirements across a multi-vendor IAM stack creates significant overhead without a centralized governance layer.

The NHI Blind Spot in Identity Orchestration

Identity orchestration platforms manage identity flows and access policies. But these tools can't detect if the credentials moving through said flows are compromised. If an API key was hardcoded in a repository two years ago and has been sitting exposed in git history ever since, rotating it through an orchestration workflow would only partially help until someone finds and remediates the original leak.

This is why it's important to integrate a dedicated secrets security platform like GitGuardian with the specific identity orchestration solution you choose.

Key Capabilities of Modern Identity Orchestration Platforms

1. Identity Unification and Fabric Architecture — Connect multiple identity providers, directories, and cloud IAM systems through a single control plane with protocol normalization across SAML, OIDC, OAuth, SCIM, and LDAP.

2. Workflow Automation and No-Code Orchestration — Visual workflow builders for identity journeys, provisioning, deprovisioning, and lifecycle events.

3. Multi-Cloud and Hybrid Support — Cross-cloud identity federation, on-premises app bridging, and Kubernetes support.

4. Non-Human Identity Coverage — Service account discovery, API key and token lifecycle orchestration, machine identity visibility.

5. Governance, Compliance, and Audit — Centralized audit trails, compliance reporting for SOC 2/ISO 27001/PCI DSS, risk scoring and access reviews.

Top Identity Orchestration Tools for 2026

1. Strata Identity

Category: Identity orchestration and identity fabric platform

Strata Identity pioneered the "identity fabric" approach. The platform abstracts identity infrastructure into a unified orchestration layer, helping companies modernize legacy apps, consolidate multi-cloud identities, and enforce consistent policies without rip-and-replace migrations.

Pros: True identity fabric approach with strong multi-IdP unification. Excellent for legacy-to-modern migration. Strong multi-cloud and hybrid support.

Cons: Not focused on secrets exposure detection. Organizations should layer secrets security tooling to cover leaked credentials passing through orchestration workflows.

Enterprise Fit: Ideal for large enterprises with complex, multi-IdP environments undergoing legacy IAM modernization. Website: strata.io

2. Ping Identity (PingOne DaVinci)

Category: No-code identity orchestration engine

PingOne DaVinci lets identity teams build adaptive authentication flows and visual identity journeys without custom development, with a library of connectors for IdPs, MFA providers, and fraud detection tools.

Pros: Powerful no-code orchestration with mature connector ecosystem. Adaptive access and risk-based authentication. Well-integrated with the Ping Identity platform.

Cons: Best within the Ping ecosystem. No secrets exposure detection.

Enterprise Fit: Strong for enterprises already in the Ping ecosystem. Website: pingidentity.com

3. Simeio

Category: Managed identity orchestration services

Simeio combines an identity orchestrator platform with managed identity services, connecting disparate IAM platforms like Okta, Azure AD, and SailPoint.

Pros: Managed-service model reduces operational burden. Good multi-vendor IAM unification.

Cons: May not suit organizations preferring self-service platforms.

Enterprise Fit: Quality for enterprises needing managed orchestration across multiple IAM vendors. Website: simeio.com

4. Auth0 (Okta)

Category: Developer-centric identity platform with orchestration capabilities

Auth0 provides a developer-first identity platform with flexible orchestration through its "Actions and Rules" framework. Strong support for Machine-to-Machine (M2M) authentication via OAuth2 client credentials flow.

Pros: Very developer-friendly. Flexible Actions framework. Strong community and marketplace ecosystem.

Cons: Orchestration is code-driven, requiring developer involvement. Not a multi-IdP fabric.

Enterprise Fit: Excellent for developer-led organizations and SaaS companies. Website: auth0.com

5. Microsoft Entra ID (Azure AD)

Category: Enterprise IAM platform with orchestration and governance

Microsoft Entra ID provides identity orchestration through conditional access policies, identity governance workflows, and workload identity management as part of the Microsoft ecosystem.

Pros: Deep Microsoft/Azure integration. Strong conditional access and governance. Native workload identity support.

Cons: Limited for multi-vendor, multi-IdP orchestration outside Azure. No secrets exposure scanning.

Enterprise Fit: Essential for Microsoft-centric enterprises. Website: microsoft.com/en-us/security/business/identity-access/microsoft-entra-id

6. TrustBuilder

Category: European identity orchestration and access management

TrustBuilder emphasizes European data sovereignty and GDPR-aligned identity governance with a visual workflow editor and adaptive authentication.

Pros: Strong visual workflow orchestration. Good fit for European enterprises with data sovereignty requirements.

Cons: Smaller ecosystem than US-based platforms. Limited NHI exposure visibility.

Enterprise Fit: Suitable for European enterprises needing orchestration with GDPR compliance. Website: trustbuilder.com

7. Tech Prescient (Identity Confluence)

Category: Customized identity orchestration and automation

Tech Prescient offers Identity Confluence, a customizable orchestration platform with white-glove implementation services for complex enterprise requirements.

Pros: Highly customizable. Strong consulting support. Good hybrid coverage.

Cons: More services-oriented than a pure SaaS product.

Enterprise Fit: Good for enterprises with complex, customized requirements. Website: techprescient.com

8. SailPoint

Category: Identity governance and orchestration platform

SailPoint is a leading IGA platform that has expanded into identity orchestration with workflow automation, AI-driven access recommendations, and support for both human and non-human identities.

Pros: Market-leading IGA capabilities. AI-driven access governance insights. Broad connector ecosystem.

Cons: More IGA than dedicated orchestration. No secrets exposure detection.

Enterprise Fit: Quality choice for enterprises needing IGA as their orchestration foundation. Website: sailpoint.com

9. Saviynt

Category: Cloud-native identity governance and orchestration

Saviynt provides cloud-native IGA with orchestration capabilities, integrating IGA and PAM capabilities with continuous risk scoring.

Pros: Strong cloud-native architecture. Good IGA + PAM integration. Risk-based analytics.

Cons: More IGA than orchestration. Less focused on developer workflows and secrets exposure.

Enterprise Fit: Solid for cloud-first enterprises needing IGA with orchestration and PAM. Website: saviynt.com

10. ConductorOne

Category: Identity security and access orchestration

ConductorOne automates access reviews, streamlines provisioning, and provides an identity graph showing who has access to what across SaaS and cloud apps.

Pros: Fast to deploy with a modern, lightweight approach. Strong automated access reviews. Good NHI visibility for service accounts.

Cons: Still-growing connector ecosystem. Less focused on legacy/on-premises identity. No secrets exposure detection.

Enterprise Fit: Great for modern, cloud-first teams. Website: conductorone.com

11. Okta (Workforce Identity Cloud)

Category: Enterprise IAM platform with orchestration workflows

Okta's Workforce Identity Cloud provides SSO, adaptive MFA, lifecycle management, and identity governance through Okta Workflows — a no-code automation engine with 7,000+ pre-built integrations.

Pros: Massive integration ecosystem. Powerful no-code Workflows engine. Strong adaptive MFA.

Cons: Orchestration stays within the Okta ecosystem. No secrets exposure detection or NHI credential scanning.

Enterprise Fit: Best for enterprises already using Okta as a primary IdP. Website: okta.com

The Secrets Security Layer Every Orchestration Stack Needs

None of the tools above offer secrets security and NHI exposure intelligence — using them in isolation weakens your security posture.

GitGuardian

Category: Secrets security and NHI exposure intelligence for identity orchestration

GitGuardian is an enterprise-grade secrets security and NHI exposure platform that provides the critical security layer identity orchestration stacks need. While orchestration platforms unify and automate identity flows, GitGuardian ensures the credentials, API keys, tokens, and service account secrets moving through those flows aren't compromised.

Core Features: Internal Secrets Monitoring, Public Secrets Monitoring, NHI Governance, CI/CD Pipeline Scanning (via ggshield), Collaboration Tool Coverage (Slack/Jira/Confluence/Teams), Vault Integration (HashiCorp Vault, CyberArk), Agentic AI Security.

Enterprise Fit: Essential for any large company deploying identity orchestration and wanting to ensure credentials flowing through their workflows are secure and properly governed.

Website: gitguardian.com

Implementation Strategy for Enterprise Identity Orchestration

Phase 1: Identity Discovery and Orchestration Deployment — Inventory all identity providers and federated trust relationships. Deploy orchestration aligned with your architecture. Bridge legacy and modern identity protocols.

Phase 2: Credential Hygiene and Secrets Exposure Remediation — Scan all repositories (including full git history), CI/CD pipelines, and collaboration tools for leaked secrets. Identify and remediate hardcoded credentials. Deploy continuous secrets monitoring.

Phase 3: NHI Governance and Continuous Monitoring — Discover and inventory all non-human identities. Automate secret rotation and certificate renewal. Enforce least-privilege for all NHIs. Establish clear ownership models across AppSec, IAM, and Platform Engineering.

The Future of Identity Orchestration

Identity fabric convergence — Dedicated orchestration platforms, IGA tools, and PAM solutions are converging into unified platforms.
AI-driven orchestration — Autonomous identity workflows and adaptive policy recommendations driven by ML.
Non-human identity as a first-class concern — As machine identities proliferate across Kubernetes, CI/CD, and agentic AI systems, platforms without strong NHI coverage will fall short.
Secrets security integration becomes standard — Detection of exposed credentials is moving from a specialized function to an expected orchestration layer.
Decentralized and verifiable identity — New cross-organization federation patterns without centralized identity stores.

If you're currently deploying identity orchestration workflows, secure the credentials that flow through them. Book a demo of GitGuardian to see how our platform fits into your identity security strategy.

API Keys Security & Secrets Management Best Practices

Dwayne McDaniel — Mon, 11 May 2026 12:39:03 +0000

TL;DR: Master API key management best practices by never storing unencrypted secrets in git, enforcing automated secrets scanning, and avoiding plaintext sharing in messaging systems. Use dedicated secrets management tools, apply least privilege and short-lived keys, and implement robust rotation and monitoring strategies.

We have compiled a list of some of the best practices to prevent API key leakage and keep secrets and credentials safe. Secrets management doesn't have a one-size-fits-all approach, so this list considers multiple perspectives so you can be informed in deciding to or not to implement strategies.

Download the cheat sheet

Never store unencrypted secrets in .git repositories

It is common to wrongly assume that private repositories are secure vaults that are safe places to store secrets. Private repositories are not appropriate places to store secrets.

Private repositories are high-value targets for bad actors because it is common practice to store secrets within them. In addition, .git is designed to sprawl. Repositories get cloned onto new machines, forked into new projects and new developers regularly enter and exit a project with access to complete history. Any hard-coded secrets that exist within a private repository's history will exist in all new repositories born from that source.

If a secret enters a repository, private or public, then it should be considered compromised.

A secret in a private repo is like a password written on a $20 bill, you might trust the person you gave it to, but that bill can end up in hundreds of peoples hands as a part of multiple transactions and within multiple cash registers.

If already committed and want to remove an API key from the git history, see: Git Clean, Git Remove file from commit - Cheatsheet

Avoid `git add *` commands on git

Using wildcard commands like git add * or git add . can easily capture files that should not enter a git repository. This includes generated files, config files, and temporary source code. When making a commit, you should preferably add each file by name and use git status to list tracked and untracked files.

Advantages: Complete control and visibility over what files are committed. Reduces the risk of unwanted files entering source control.

Disadvantages: Takes additional time when making a commit. Can mistakenly miss files when committing.

TIP: Committing early and committing often will not only help navigate file history and break up otherwise large tasks, in addition it will reduce the temptation to use wildcard commands.

Add sensitive files in .gitignore

To prevent sensitive files from ending up within git repositories a comprehensive .gitignore file should be included with all repositories and include:

Files with environment variables like .env or configuration files like .zshrc, application.properties or .config
Files generated by another process (such as application logs or checkpoints, unit tests/coverage reports)
Files containing "real" data (other than test data) like database extracts.

GitHub published a collection of useful .gitignore templates.

Don't rely on code reviews to discover secrets

It is extremely important to understand that code reviews will not always detect hard-coded secrets, especially if they are hidden in previous versions of code. Reviewers are only concerned with the difference between the current and proposed states of the code; they do not consider the entire history of the project.

If secrets are committed to a development branch and later removed, these secrets won't be visible or of importance to the reviewer. The nature of git means that if a secret gets overlooked in history it is exposed forever.

TIP: As a rule, automation should be implemented wherever predefined rules can be established, like secrets detection. Human reviews should be left to check code for errors that cannot be easily predefined, such as logic.

Use automated secrets scanning on repositories

Even when all best practices are followed, mistakes are common. GitGuardian offers a free secrets scanning solution for developers to detect both generic API keys and specific secrets (more than 450 providers are supported!), installable both on private and public repositories for free.

Visibility is the key to great secret management. If you don't know you have a problem, you cannot take action to fix it.

Don't share your secrets unencrypted in messaging systems like Slack

A common secret sprawl enabler is sending secrets in plain text over messaging services. These systems are high-value targets for attackers. It only takes one compromised email or Slack account to uncover a trove of sensitive information, as secrets exposure extends beyond source code into various communication and collaboration tools.

Store secrets safely

There is no silver bullet solution for secrets management. Different factors such as project size, team geography, and project scope, must be considered. Multiple solutions may need to coexist.

Use encryption to store secrets within .git repositories

Encrypting your secrets using tools such as git secret or SOPS and storing them within a git repository keeps secrets synced across teams.

Advantages: Your secrets are synced. Disadvantages: You have to deal with your encryption keys securely. No audit logs. No RBAC. Hard to rotate access.

Use local environment variables when feasible

An environment variable is a dynamic object whose value is set outside of the application. This makes them easier to rotate without having to make changes within the application itself.

Advantages: Easy to change between deployed versions without changing any code. Less likely to be checked into the repository. Simple and clean.

Disadvantages: May not be feasible at scale when working in teams — no easy way to keep developers, applications, and infrastructure in sync.

Use Secrets Management Tools

Secrets management systems such as Hashicorp Vault or AWS Key Management Service are encrypted systems that can safely store your secrets and tightly control access.

Advantages: Prevents secrets from sprawling. Provides audit logs.

Disadvantages: Must be hosted on highly-available and secure infrastructure. Requires codebase changes to integrate. Access keys must be carefully protected.

Restrict API access and permissions

By restricting the access and permissions of the API key you not only limit damage and restrict lateral movement but also provide greater visibility over when the API key is being used outside of its scope.

💡 This idea can be pushed even further by using API keys as a decoy to intercept hackers — a concept called a honeytoken. Learn more about the Honeytoken module in GitGuardian.

Default to minimal permission scope for APIs

Make sure the permissions of that API match the task it is fulfilling. Have separate APIs for read-only and read/write permissions to avoid overprivileged secrets. It is common for developers to use API keys with excessive permissions — this increases the potential damage of a data breach.

Whitelist IP addresses where appropriate

IP whitelisting provides an additional layer of security by providing a whitelist of IP addresses from your private network so external services only accept requests from trusted sources.

Advantages: Limited requests to select trusted sources. Disadvantages: Not always feasible. Can prevent legitimate requests. Needs constant maintenance.

Use short-lived secrets

By using short-lived secrets, the risk of undetected leaked API keys is mitigated, ensuring that even if an attacker gains access to a secret, it would be harmless, unlike most exposed secrets that remain valid for extended periods.

Revoke and rotate all API keys often to prevent unrevoked secrets from lurking in your systems.

Imagine you own a company with hundreds of employees that all have keys to your office — keys will inevitably get lost, employees will leave, new keys will get cut and you will soon lose visibility over where each key is. It would be widely considered good practice to change the locks from time to time.

Advanced API Key Storage and Cryptographic Protection

Enterprise API key management demands sophisticated storage mechanisms with cryptographic protection layers. Single-purpose keys are a fundamental principle — use dedicated keys for encryption versus authentication to prevent cryptographic side effects.

For applications requiring local key storage, implement Hardware Security Modules (HSMs) or secure enclaves. When HSMs aren't feasible, use secure key generation through cryptographically secure random number generators. Consider key derivation strategies where multiple API keys derive from a single master key using strong secret diversification methods.

API Key Monitoring and Anomaly Detection

Implement monitoring systems that track API key usage patterns — request frequency, geographic distribution, and accessed resources — to establish baseline behaviors. Deploy alerting for suspicious activities such as unusual request volumes, unexpected IP ranges, or attempts to access resources outside normal scope.

Establish audit trails capturing successful API calls, failed authentication attempts, permission escalations, and administrative changes. Integrate with SIEM systems to enable real-time threat detection and automated response workflows.

Conclusion

Managing and storing secrets is a challenge that requires vigilance from even the most experienced developer. There is no perfect checklist that a developer can follow.

Policies, tools, and strategies will differ from project to project, but it is crucial for developers to understand the consequences of their choices so that secrets management can be an informed, active strategy throughout the entire development process.

Summary: Best Practices for API Key and Credentials Security

Never store unencrypted secrets in .git repositories — avoid wildcard git add, use .gitignore, use automated scanning
Don't share secrets unencrypted in messaging systems like Slack
Store secrets safely — use encryption, environment variables, or secrets-as-a-service solutions
Restrict API keys access and permissions — minimal scope, IP whitelisting, short-lived secrets

💡 Ready to find out which secrets management approach is right for you? Take the GitGuardian Secrets Management Needs Quiz

FAQs

What are the most critical API key management best practices for large development teams?

Core best practices include avoiding unencrypted secrets in Git repositories, enforcing automated secrets scanning, and applying least-privilege policies to all keys. Regular key rotation, centralized secrets management, and encryption of all credentials both at rest and in transit are essential.

How should organizations approach API key rotation and lifecycle management?

Automate rotation schedules based on privilege and risk: rotate high-privilege keys weekly or daily, and rotate low-privilege keys monthly. If any key in a rotation chain is compromised, revoke all related keys immediately.

Why is relying solely on code reviews insufficient for detecting hard-coded secrets?

Code reviews typically cover only recent changes and may overlook secrets committed previously and later removed. These secrets persist in repository history and remain exploitable. Automated secrets scanning provides comprehensive coverage across current code and historical commits.

What advanced storage options are recommended beyond environment variables?

Robust alternatives include dedicated secrets managers (e.g., HashiCorp Vault, AWS Secrets Manager), Hardware Security Modules (HSMs), and secure enclaves offering cryptographic protection, granular permissioning, and automated rotation.

How can organizations monitor API key usage and detect anomalies?

Monitor request volume, originating IP addresses, time-of-day patterns, and resource access behavior. Configure alerts for unusual activity and forward logs to SIEM platforms for real-time analytics and automated incident response.

What are the risks of sharing secrets in messaging platforms like Slack?

Sharing secrets in plaintext on messaging platforms exposes them if accounts are compromised. Attackers can exploit these credentials for lateral movement or privilege escalation. Always use dedicated secrets management tools to share sensitive information securely.

Local Guardrails for Secrets Security in the Age of AI Coding Assistants

Dwayne McDaniel — Fri, 08 May 2026 13:01:13 +0000

Software supply chain security used to feel like a problem that lived somewhere else.

The repository and build system were top of mind. Package registries, continuous integration and continuous delivery pipelines, release automation, cloud platforms, and artifact stores also became the focus of concern. These still matter and need protection, but the attack surface has shifted closer to where developers work every day.

The developer laptop is no longer just the place where code gets written. It is part of the supply chain.

The security implications are easy to underestimate. A modern workstation touches source code, package managers, cloud accounts, registry tokens, secure shell keys, service accounts, build scripts, artificial intelligence coding assistants, terminals, local caches, and environment files. It is where credentials are created, copied, tested, logged, and too often forgotten.

Attackers understand this. They are not only looking for a vulnerable production service or a poisoned build step. They are looking for the access material that lets one system trust another.

We have to update our defense models. Security cannot wait until code reaches a remote repository or a pipeline. By then, a credential may already be in Git history, a model prompt, a local log, a build artifact, or a package install script's reach.

The control point has to move earlier in the software creation process.

The Common Thread Is Credential Theft

GitGuardian's recent breach research points to a clear pattern across software supply chain attacks: attackers increasingly target the credentials embedded in developer workflows.

In April 2026, we analyzed three supply chain campaigns that affected npm, PyPI, and Docker Hub over a 48-hour period. The ecosystems and techniques varied, but the goal was consistent. Each campaign focused on stealing useful credentials from developer environments or continuous integration and delivery pipelines.

One compromised npm package used a postinstall hook to steal npm publish tokens, then used that access to publish infected versions of packages the victim could reach. A PyPI campaign harvested secure shell keys, cloud credentials, environment variables, and crypto wallets. Across those campaigns, the attacker's objective was clearly to collect valid access and use it to reach the next system.

This is what makes the problem so damaging.

Developers Are Attractive Targets

A developer may have access to source control, cloud accounts, package registries, artifact stores, staging environments, incident tools, and internal application programming interfaces. A build runner may hold deployment credentials, package publishing tokens, and access to production-adjacent infrastructure. One exposed token can become a bridge across several layers of the delivery process.

That is why credential exposure is different from many other bugs. An attacker does not always need to exploit a software flaw, maintain persistence, or modify production code. Sometimes, authenticated access is enough. Sometimes, a short-lived foothold on a developer machine can uncover a credential with broader reach.

The GitGuardian 2026 State of Secrets Sprawl report makes the scale of the situation clear. We found over 28.6 million new secrets detected in public GitHub commits in 2025, a 34 percent year-over-year increase. Internal repositories are roughly six times more likely than public repositories to contain hardcoded credentials. About 28% of incidents originate entirely outside repositories, in collaboration systems such as Slack, Jira, and Confluence.

The repository is no longer the boundary. If a secret can be found on the machine in plaintext, it is likely to spread elsewhere in plaintext and be usable by anyone who finds it.

The Workstation Now Holds Too Much Context To Ignore

Developer laptops are attractive because they contain context.

They hold source trees, dotfiles, shell history, local environment files, integrated development environment settings, package manager configuration, build artifacts, terminal output, AI agent logs, and temporary debugging notes. Many of these files are invisible during normal review. Many never leave the machine. Some sit in directories that developers rarely inspect.

That makes local exposure difficult to manage with repository-only controls.

A credential can appear in a .env file, get printed into terminal history, land inside a test config, show up in build output, or be copied into an AI prompt during troubleshooting. None of that requires a malicious commit. None of it necessarily triggers a centralized scanner. Yet each moment can create real access risk.

We need, as an industry, to scan the places where credentials are collected outside Git. Project workspaces, dotfiles, build output, and agent folders can all store copied tokens, configuration blocks, troubleshooting output, and cached context. Attackers harvest this local data because it can lead directly to valid access.

The Shai-Hulud data gives that concern weight. Across 6,943 compromised machines, it found 33,185 unique credentials, with at least 3,760 still valid when first checked. That is not a theoretical workstation problem. It is a practical attacker workflow.

Compromise the machine. Search the context. Extract the access. Move on.

The workstation has become a security boundary because so many tools assume the local environment is trusted. Package managers run install scripts. Extensions read project files. Terminals expose environment variables. Local automation touches real systems. AI agents can read files, run commands, and summarize outputs.

Each of those actions may be useful, but each can also become a path for accidental exposure or malicious instruction.

AI-assisted development adds a newer layer to the same problem. AI coding tools now work closer to the developer's files, terminal, editor, and environment variables. A prompt can contain a credential. A tool can call and read a sensitive file. A generated command can print access material into logs or model context. An agent can combine harmless-looking steps into a risky action.

The exposure surface is no longer just human typing plus code review. It now includes the interaction between humans, local tools, automated agents, and external services. And as we found in our report, more people are using coding assistants, and many of them that do let the agent co-author their commits are leaking twice as many secrets per commit.

Security controls have to meet the workflow where it actually happens.

Earlier Checkpoints Reduce Damage

Traditional supply chain controls still matter. Teams still need source control protections, dependency scanning, secure continuous integration and delivery, artifact integrity, release controls, and production deployment guardrails.

But those controls often fire after the risky moment has already happened.

A developer may have created a local file with a credential. An AI assistant may have received sensitive context. A package install script may have read environment variables. A token may have entered local Git history before it ever reaches a remote repository.

Rotating a credential after it reaches a shared repository can become a full incident response exercise. Someone has to identify ownership, revoke the credential, issue a replacement, check usage, test dependent applications, review access, clean history where possible, and document the event. That work is necessary, but it is expensive.

Catching the same issue while the developer is still editing a file is simpler. Remove it. Replace it with a safe reference. Keep moving.

The strongest model treats credential detection as a continuous developer-side control, not an occasional cleanup task. The tool has to sit where developers already work: in the editor, in Git hooks, in the terminal, and inside AI coding workflows.

Protecting Your Developers' Secrets

ggshield is the GitGuardian CLI for scanning developer workflows. You can run ggshield locally or in continuous integration environments, where it provides guardrails across the software development lifecycle and detects hundreds of types of hardcoded credentials.

A local scan catches problems before code moves into shared infrastructure. A continuous integration scan catches problems after code leaves the laptop. A pre-receive hook can prevent a secret from being pushed to a shared repo or system. Using the same tooling across these points gives teams consistency without forcing developers into a separate security process.

Git Hooks Add Another Layer Of Protection

Using ggshield pre-commit hooks means a scan runs before Git creates a commit. Teams can configure it through the pre-commit framework, install it locally for specific repositories, or install it globally across current and future repositories on a developer workstation.

The global option is important. Not every leak happens in the main codebase. Temporary repositories, test folders, side projects, cloned examples, and one-off experiments all create exposure. A repository-by-repository rollout leaves gaps. A global hook gives the developer machine a broader default.

A pre-push hook catches a later moment. It runs before code leaves the machine for a remote repository. GitGuardian documents local, framework-based, and global installation modes for this control as well. Together, pre-commit and pre-push hooks create two useful gates: one before local history becomes durable, and one before code reaches shared infrastructure.

Finding Secrets On Save

GitGuardian's VS Code extension uses the bundled ggshield CLI to scan code as developers write or modify it. A scan is run automatically on saving a file. Findings are shown instantly and directly inside the editor through code annotations, status bar warnings, and the Problems panel. This extension also works with Cursor, Antigravity, and Windsurf.

Security controls fail when they are too late, too noisy, or too far away from the mistake. A good local control gives feedback in context. It explains what happened. It helps the developer fix the issue before it becomes a ticket, a broken build, or an incident.

AI Tools Need Guardrails At The Handoff Points

AI coding tools deserve special attention because they change where leakage can occur.

An AI workflow may expose sensitive material before code exists as a file. A developer might paste a credential into a prompt while debugging. An agent might read a local configuration file. A tool call might execute a command that prints environment variables. Output from that command might then move into the model context or local logs.

That is a different path than traditional source code leakage.

GitGuardian's AI coding tools integration addresses this by placing controls inside the hook systems of tools such as Cursor, Claude Code, and VS Code with GitHub Copilot. The integration scans three stages: prompt submission, pre-tool use, and post-tool use.

Prompt submission scanning checks content before it reaches the model and blocks the prompt when credentials are found. Pre-tool use scanning checks commands, file reads, and Model Context Protocol calls before execution, blocking risky actions before they run. Post-tool use scanning checks outputs after execution and sends a desktop notification when credentials appear.

That structure fits how agentic tools operate.

The risky moment may be a prompt. It may be a file read. It may be a shell command. It may be the output of a tool the developer did not manually inspect. A repository-only control sees too little of this flow. A hook inside the AI workflow can stop exposure at the handoff point.

The editor catches the issue while the developer writes. AI hooks catch sensitive material before prompts, tool calls, or outputs move it somewhere risky. Git hooks catch credentials before they enter commit history or leave the laptop. Continuous integration and server-side controls provide backup once code reaches shared systems.

Layered Prevention Without Forcing A Separate Workflow

Developer environments are now connected, automated, and increasingly assisted by tools that can act on local context. Security has to account for that reality. Waiting for a remote scan is too late for credential exposure.

The better model is straightforward: find credentials earlier, block them closer to where they appear, and reduce the chance that a developer's laptop becomes the easiest path into the software supply chain.

GitGuardian's ggshield, IDE extensions, AI hooks, and Git hooks all point toward that model. They bring detection into the places developers already use, rather than asking developers to leave their workflow for security. They reduce the time between mistakes and feedback. They give teams a consistent detection engine across local development, AI-assisted coding, Git workflows, and automation.

The supply chain now includes the workstation.

Treat it that way.

Git Clean, Git Remove file from commit - Cheatsheet

Dwayne McDaniel — Thu, 07 May 2026 13:07:34 +0000

TL;DR: Learn how to remove files from git commits, whether staged, recent, or deep in history, to eliminate exposed secrets and sensitive data. This guide covers safe removal techniques, advanced history rewriting with git-filter-repo, and critical security steps like credential revocation. Understand the risks of incomplete cleanup and why automated secrets detection and pre-commit scanning are essential for robust codebase security.

Learn how to safely remove confidential information from your git repository. Whether you need to excise an entire file or edit a file without removing it, this tutorial will guide you through the process. Plus, get tips on preventing future headaches with GitGuardian!

You know that adding secrets to your git repository (even a private one) is a bad idea, because doing so risks exposing confidential information to the world. But mistakes were made, and now you need to figure out how to excise confidential information from your repo. Because git keeps a history of everything, it's not often enough to simply remove the secret or file, commit, and push: we might need to do a bit of deep cleaning.

Thankfully, for simpler cases, git provides commands that make cleaning things up easy. And in more complicated cases, we can use git-filter-repo, a tool recommended by the core git developers for deep cleaning an entire repository.

First and foremost, if there is reason to think that the secret has escaped into the world, and you can revoke the secret, do so. How to revoke a secret is going to vary quite a lot depending on what the secret protects. If you don't know how to revoke it, you will need help from the owner of the resource protected by the secret.

Need to quickly see what scenario applies to you? Check out our cheatsheet flow chart below.

Download the git history cheatsheet

Now, let's consider different scenarios to see how to clean things up.

Have you pushed your work up yet?

NO

No? That's great. Please don't push it up just yet. If you have any uncommited work, we can use git stash to save it. This sets your work aside in a temporary "stash" so that we can work with the git repository without losing anything you haven't committed yet. When we're done cleaning things up, you can use git stash pop to restore your work.

YES

If you have already pushed a commit containing a secret, or just discovered a secret in your existing history, things get more complicated if there are other people working on this branch. If you work alone, there's nothing to do at this point, you can skip to the next step. If you work as part of a team, things get more complicated because we need everyone to act in a coordinated way.

First of all, we need to determine who else is affected by the secret's presence, because we'll need to coordinate everyone's actions. If the secret only appears in the branch you're working on, you only need to coordinate with anyone else who is always working off of that branch. However, if you found the secret lurking further back in git history, perhaps in your master or main branch, you'll need to coordinate with everyone working in the repository.

Let the others affected know that a secret was found that needs to be excised from everyone's git history. When you edit the git history to remove a file, it can cause problems with your teammates' local clones; moreover, they can end up re-inserting the secret back into the public repository when they push their work. So it is important that everyone affected is in sync for the excision to work. This means that everyone needs to stop what they are doing, close outstanding PRs, and push up work that's in progress.

Now, let's make a fresh clone.

Delete your existing clone in its entirety.
Make a fresh clone with git clone [repository URL]
Change into the project directory with cd [project name]
Download the entire repository history: git pull --all --tags.

The last step will look a little bit familiar. git pull tells git to grab updates from the remote repository, and apply them in the current branch (when it makes sense to do so, that is, when the local branch is set to track a remote branch). But git is smart, it doesn't pull everything down, only what's needed. This is where the --all flag comes in. This flag tells git to grab every branch from the remote repository. And the --tags flag tells git to grab every tag as well. So this command tells git to download the entire repository history, a complete and total clone. We have to do this, because it is possible that the commit containing the secret exists in more than one branch or tag. We need to ensure we don't just scrub our secret from a portion of the repository history. As a result, this command can take a very long time, if the repository is very large.

Move on to the next step.

Git Remove File from Commit: Understanding the Difference Between Staged and Committed Files

Before diving into file removal techniques, it's crucial to understand the distinction between staged and committed files in Git's workflow. When you execute git add, files move to the staging area (index), but they're not yet part of the repository history. Once you run git commit, these staged changes become part of a commit object with a unique SHA hash.

This distinction is critical when you need to remove file from git commit because the approach varies significantly. For staged files that haven't been committed yet, simple commands like git reset HEAD <filename> or the newer git restore --staged <filename> will unstage the file without affecting your working directory. However, once files are committed, you're dealing with Git's immutable history, requiring more sophisticated techniques like git reset --soft HEAD~1 followed by selective staging, or git commit --amend for the most recent commit.

Understanding this workflow prevents common mistakes where developers accidentally delete files from their working directory when they only intended to remove them from a commit. Always verify your Git status with git status before executing removal commands to ensure you're targeting the correct state.

How complicated is the situation?

The secret is in the last commit, and there's nothing else in the last commit

In this case, we can drop the last commit in its entirety. We do this with

git reset --hard HEAD~1

What does this command do? Let's break it apart a little bit. git reset is how we tell git that we want to undo recent changes. Normally, this command by itself tells git to unstage anything we've added with git add, but haven't committed yet. This version of resetting isn't sufficient for our purposes. But git reset is more flexible than that. We can tell git to take us back in time to a previous commit as well. We do that by telling git which commit to rewind to. We can use a commit's identified (it's "SHA"), or we can use an indirect reference. HEAD is what git calls the most recent commit on the checked out branch. HEAD~1 means "the first commit prior to the most recent" (likewise HEAD~2 means "two commits prior to the most recent").

Finally, the --hard tells git to throw away any differences between the current state and the state we're resetting to. If you leave off the --hard your changes, including the secret, won't be discarded. With --hard, the differences will be deleted, gone forever (which is precisely what we want!).

Once you've done a hard reset, that's it! You're done. Your work has been destructively undone, and you can pick back up where you were.

The secret is in the last commit, but there were other changes too

In this case, we don't want to completely drop the last commit. We want to edit the last commit instead. Edit your code to remove the secrets, and then add your changes as usual. Then, instead of making a new commit, we'll tell git we want to amend the previous one:

git add [FILENAME]
git commit --amend

We all know git commit, but the --amend flag is our friend here. This tells git that we want to edit the previous commit, rather than creating a new one. We can continue to make changes to the last commit in this way, right up until we're ready to either push our work, or start on a new commit.

Once you've amended the commit, you're done! The secret's gone, you can carry on as you were.

The secret is beyond the last commit

It's complicated

If you know you committed a secret, but have since committed other changes, things get trickier quickly. In anything but the simplest cases, we are going to want a more powerful tool to help us do a deep clean of the repository. We're going to use git-filter-repo, a tool recommended by the git maintainers that will help us to rewrite history in a more user-friendly way than the native git tooling.

A technical aside to those familiar with the concept of rebasing. (If you don't know what that means, feel free to skip this paragraph.) All of the cases covered below can of course be managed using native git tools, particularly by rebasing. Sometimes rebasing is relatively painless, of course, but in the kinds of scenarios we're presenting here, rebasing is going to be a tedious and deeply error-prone process. This is why I am favoring purpose-built tools like git-filter-repo over rebasing. It is far better to avoid opening the possibility for making mistakes. From my own personal experience, recovering from a botched rebase is extremely time consuming, and often nearly impossible. Better to use the right tool for the job.

First, install git-filter-repo.

Next, let's assess the situation to determine which technique is right for your situation. Sometimes secrets are files, and sometimes secrets are lines of code. For example, if you accidentally committed an SSH key or TLS certificate file, these are contained in specialized files that you'll need to excise. On the other hand, maybe you have a single line of code containing an API key that's part of a larger source file. In that case, you want to modify one or more lines of a file without deleting it.

Git-filter-repo can handle both cases, but requires different syntax for each case.

Excise an entire file

To tell git-filter-repo to excise a file from the git history, we need only a single command:

git filter-repo --use-base-name --path [FILENAME] --invert-paths

The --use-base-name option tells git-filter-repo that we are specifying a filename, and not a full path to a file. You can leave off this option if you would rather specify the full path explicitly.

Normally, git-filter-repo works by ignoring the filenames specified (they are, as the name suggests, filtered out). But we want the inverse behavior, we want git-filter-repo to ignore everything except the specified file. So we must pass --invert-paths to tell it this. If you leave off the --invert-paths, you'll excise everything except the specified file, which is the exact opposite of what we want, and would likely be disastrous. Please don't do that.

Edit a file without removing it

If you only need to edit one or more lines in a file without deleting the file, git-filter-repo takes a sequence of search-and-replace commands (optionally using regular expressions).

First, identify all the lines containing secrets that need to be excised. You'll also need to work out a plan for how you will replace those lines. Perhaps just deleting them is enough. But perhaps they need to be modified to prevent a runtime crash. Next, create a file containing the search-and-replace commands, called replacements.txt. Make sure it's in a folder outside of your repo, for example, the parent folder.

The format of this file is one search-and-replace command per line, using the format:

ORIGINAL==>REPLACEMENT

For example, suppose that you've hard-coded an API token into your code, like this:

AUTH_TOKEN='123abc'

Now suppose that you've decided that it's better to load the API token from an environment variable, as such:

AUTH_TOKEN=ENV['AUTH_TOKEN']

We can tell git-filter-repo to search for the hard-coded token, and replace with the environment variable by adding this line to replacements.txt:

'123abc'==>ENV['AUTH_TOKEN']

If you have multiple secrets you need to excise, you can have more than one rule like this in replacements.txt.

Finally, assuming you placed replacements.txt in the parent directory, we invoke git-filter-repo with our search-and-replace commands like this:

git filter-repo --replace-text ../replacements.txt

Sometimes you might get an error saying you're not working from a clean clone. That's OK. Git-filter-repo is making irreversible changes to your local repository, and it wants to be certain that you have a backup before it does that. Of course, we do have a remote repository, and we're working from a local clone. And of course we are very interested in making irreversible edits to our commit history—we have a secret to purge! So there's no need for git-filter-repo to worry. We can reassure it that we are OK with making irreversible changes by adding the --force flag:

git filter-repo --replace-text ../replacements.txt --force

And now you have a clean git history! You'll want to validate your work by compiling your software or running your test suite. Then once you're satisfied that nothing is broken, move on to the next step to propagate the new history to your remote repository and the rest of the team.

Advanced Scenarios: Removing Files from Multiple Commits

While the current article covers basic scenarios, many developers encounter situations where they need to git remove files from commit across multiple commits in their history. This commonly occurs when sensitive data like API keys or configuration files were committed multiple times before being detected.

For commits that aren't the most recent, you'll need to use interactive rebase with git rebase -i HEAD~n where n is the number of commits to review. During the interactive rebase, you can mark commits for editing with edit, then use git reset HEAD~1 to unstage files from that specific commit, remove the unwanted files, and continue with git rebase --continue.

Alternatively, for more complex scenarios involving the same file across many commits, git filter-repo --path <filename> --invert-paths provides a more robust solution. This tool rewrites the entire repository history, permanently removing the specified file from all commits. However, this approach requires careful coordination with your team since it fundamentally alters the repository's commit hashes, making it incompatible with existing clones.

Always create a backup branch before attempting multi-commit file removal: git branch backup-before-cleanup ensures you can recover if something goes wrong during the history rewriting process.

Do you need to coordinate with your team?

No

If you only just added the secret, and haven't pushed any of your work yet, you're done. Just keep working like you had been, and no one will ever know. Don't forget if you need to restore uncommitted work by popping it from the stash with git stash pop.

Otherwise, we'll need to overwrite what's on your remote git repository (such as GitHub), as it still contains tainted history. We can't simply push, however: The remote repository will refuse to accept our push because we've re-written history. So we'll need to force push instead. Moreover, if our re-writes to history affect multiple branches or tags, we'll need to push them all up. We can accomplish all of this like so:

git push --all --force && git push --tags --force

Note: The --all argument does not automatically push any updated tags. Git does not allow the push arguments --all and --tags to be used in the same call. If you need to run both commands, you can do so with the single line, thanks to the &&.

YES

If you work as part of a team, now comes the hard part. Everyone you identified as affected at the beginning of this process still has the old history. They need to synchronize against the revised history you just force-pushed. This is where errors can happen, and more importantly, where frustration can occur.

Ideally everyone pushed their work up before you edited the history. In that case, everyone can simply make a clean clone of the repo and pick up where they left off.

But if someone failed to push their work up before you re-wrote history, they're going to find they have a number of conflicts that need to be resolved when they pull. Instead, they need to fetch the new history from the remote repository, and rebase their hard work on the re-written history. To do this:

git fetch

git rebase -i origin/[branchname]

If you aren't familiar with git fetch, this command tells git to download new data from the remote repository, but unlike git pull, it doesn't attempt to merge new commits into your current working branch. So the fetch here is requesting all the newly re-written history.

Once all the new history is pulled down, the developer will need to re-apply all their hard work on top of the re-written history. This is done by rebasing. For this reason, rebasing is out of scope for this tutorial.

Security Implications: When File Removal Isn't Enough

From a cybersecurity perspective, simply knowing how to remove a file from git commit is only the first step when dealing with exposed secrets or sensitive data. Even after successful removal from Git history, the sensitive information may have already been exposed through various vectors that require immediate attention.

If the repository was ever public or accessible to unauthorized users, you must assume the sensitive data has been compromised. This means immediately revoking any exposed credentials, rotating API keys, and updating passwords. Git's distributed nature means that anyone who cloned or forked the repository before your cleanup still has access to the sensitive data in their local copies.

For organizations using GitGuardian's secrets detection capabilities, the platform can help identify when sensitive data has been exposed and provide guidance on proper remediation steps. This includes not just the technical Git operations, but also the security protocols necessary to minimize damage from the exposure.

Additionally, consider implementing pre-commit hooks and automated scanning to prevent future incidents. Tools like GitGuardian's pre-commit hooks can catch secrets before they enter your repository, eliminating the need for complex history rewriting operations and reducing security risks associated with exposed credentials in version control systems.

Conclusion

If you've made it this far, congratulations! You've successfully and securely eliminated a secret or file from your git history. But it didn't have to be this way. You can prevent all this headache with GitGuardian.

GitGuardian is an automated secret detection solution that integrates with your git repos to scan your code for secrets. GitGuardian first makes an initial scan to clean your history, then integrates with your devops pipeline to scan all incremental changes as they arrive and notify you before you have to do complex surgery! Try it out here.

If you are interested in other cheat sheets about security we have put together these for you:

How to improve your Docker containers security
Best practices for managing and storing secrets including API keys and other credentials

FAQs

What is the safest way to remove a file from a Git commit after it has been pushed?

To safely remove a file from a Git commit after pushing, use history-rewriting tools like git filter-repo to purge the file from all relevant commits. After rewriting history, coordinate with your team and force-push the updated repository. Always revoke any exposed secrets immediately, as removal from Git does not prevent prior exposure.

How do I remove a file from a Git commit if it is only staged and not yet committed?

If a file is staged but not committed, use git reset HEAD <filename> or git restore --staged <filename> to unstage it. This removes the file from the staging area without affecting your working directory, ensuring it will not be included in the next commit.

What are the implications of using git filter-repo to remove files from multiple commits?

Using git filter-repo to remove files from multiple commits rewrites the repository history, changing commit hashes. This requires all collaborators to re-clone or rebase their work on the new history. Always create a backup branch before proceeding and communicate changes to your team to avoid workflow disruptions.

How do I remove sensitive data from a single recent commit without losing other changes?

To remove sensitive data from the most recent commit without discarding other changes, edit the file to remove the secret, stage the updated file, and run git commit --amend. This updates the last commit with your modifications, effectively removing the sensitive data.

What security steps should be taken after you remove file from git commit containing secrets?

After removing a file from a Git commit that contained secrets, immediately revoke or rotate any exposed credentials. Assume the secret may have been accessed if the repository was public or shared. Implement automated secrets detection and pre-commit hooks to prevent future exposures and ensure compliance with security policies.

How do I coordinate with my team when rewriting Git history to remove sensitive files?

Before rewriting history, notify all affected team members and ensure they push any outstanding work. After force-pushing the cleaned history, teammates must re-clone the repository or rebase their changes onto the new history. Clear communication and a coordinated process are essential to prevent conflicts and data loss.

This article is a guest post. Views and opinions expressed in this publication are solely those of the author and do not reflect the official policy, position, or views of GitGuardian.

Short-Lived Credentials in Agentic Systems: A Practical Trade-off Guide

Dwayne McDaniel — Thu, 07 May 2026 12:44:19 +0000

Agentic systems need short-lived credentials as a baseline security control. That point is pretty clear. The harder part is when teams move from architecture diagrams to production systems and discover how much operational machinery underpins that decision.

Security teams often frame credential lifetime as a clean principle. Short-lived good and long-lived bad. Production systems rarely live inside principles alone. In reality, they live inside retry logic, partial failures, identity providers, cloud platform quirks, third-party APIs, and on-call rotations. All this is made more difficult by the probabilistic nature of AI systems.

Agents behave differently from traditional services. A narrow service usually connects to a known set of systems and follows a fairly stable path. An agent can work across tools, call external APIs, carry context from one step to the next, and continue work after the original trigger is gone. The runtime path is less predictable, and the permission model has to account for that.

Authentication is one of the few reliable controls that bounds what an autonomous system can reach, modify, and retain access to over time. In agentic systems, an authentication choice directly shapes blast radius and revocability.

The real decision sits inside production friction

Production teams are balancing real constraints. They have to consider token issuance, refresh timing, identity federation, vault availability, third-party APIs, local development, failure recovery, and the cost of debugging expired credentials mid-workflow. That is why the more useful question is "Where does short-lived access materially reduce blast radius, and where does the operational overhead need a more deliberate design?"

A good answer ties credential lifetime to agent behavior, privilege, and execution model. A mature answer adds continuous secret monitoring on top, because agents still leak credentials, retries still fail, and temporary exceptions have a way of becoming permanent.

More Systems, More Context, More Places To Leak Secrets

Agentic systems tend to touch more systems than single-purpose services. They commonly need to authenticate to APIs, SaaS tools, internal platforms, cloud resources, data stores, and orchestration layers. They often carry temporary context, delegated permissions, and state across those steps. That broader surface expands the number of places where a token can escape.

Credentials can show up in logs, traces, prompts, tool arguments, memory stores, CI pipelines, deployment configs, notebooks, and local test environments. AI-assisted development adds more volume to all of those surfaces. The GitGuardian State of Secrets Sprawl 2026 report showed 28.65 million hardcoded secrets added to public GitHub in 2025, with leak rates in AI-assisted code running roughly double the broader GitHub baseline.

That data fits the reality that many teams already feel. More generated code means more output to review, more automation artifacts to inspect, and more opportunities for sensitive data to land where it should never have been written in the first place.

Standing permissions become more dangerous in autonomous workflows

A long-lived credential attached to an agent carries a different kind of risk than the same credential attached to a predictable service. An agent can retry automatically, call adjacent tools, invent tools, pivot across systems, and continue acting after the original operator has moved on. A shared access token can also blur accountability across agents, environments, or tenants.

Credentials in an agentic system are standing permissions attached to software that can improvise and are extremely goal-oriented. Authentication defines what an agent can reach, how long it can keep reaching it, and how quickly a team can shut it down.

What Short-Lived Credentials Actually Buy You

TTL, or time to live, is the maximum period a credential remains valid. Shorter TTL reduces the maximum window of abuse after a leak. That is the core security gain, and it is easy to quantify.

A static key valid for 90 days stays useful for up to 7,776,000 seconds. A 15-minute token stays useful for 900 seconds. That is an 8,640x reduction in the maximum exposure window.

That number doesn't erase risk, but it does cap it. An attacker with a short-lived token has less time for lateral movement, repeated calls, persistence, and quiet misuse. Incident responders also benefit because expiry often does containment work even when formal revocation is slow, cached, or inconsistently enforced across systems.

Having the shortest feasible TTL is critical as breakout times, the time from initial access to lateral movement, have been falling each year. Breakout times have been witnessed at under a minute in some cases.

Short lifetime matters most when privilege is high

The value of a short TTL rises with privilege, reach, and uncertainty. High-privilege tokens should have the shortest lifetime a system can support reliably. Credentials used across trust boundaries deserve the same discipline. The same goes for tokens accessible to LLM-adjacent components, external tool connectors, or stateful agent memory, where leakage paths are harder to predict.

The unit of issuance matters too. Per-task tokens usually beat agent-global tokens. Per-session delegated access usually beats long-running shared access. Per-agent identity is much easier to audit than a service account reused across every instance in a workflow.

Short-lived credentials reduce the size of an incident when a token is found and abused. They also improve attribution because each issued credential can be tied to a narrower slice of work.

Safe TTL Depends on the Kind of Agent

Not all agents are the same, and this needs to be factored into any discussion of access and time-to-live. Here are a few different use cases that all fall under the broad umbrella of "Agentic AI." Note: all TTL suggestions are based on general best practices; only you and your team can make a governance plan that best fits your specific needs.

Interactive user-facing agents

User-facing copilots, internal assistants, and triage agents acting on behalf of a specific user usually fit best with a 5 to 15-minute TTL. Their access is tied closely to an active session. Silent refresh is often feasible. The security goal should be to quickly remove or reduce access when the user context ends.

Background workflow agents

Scheduled document processing, enrichment jobs, and routine operational workflows often need more runtime headroom. A 15 to 60-minute TTL is usually a practical range. These systems still benefit from workload identity and on-demand issuance, but they also need sufficient time to complete routine work without causing unnecessary renewal failures.

Long-running autonomous agents

Multi-hour orchestration, remediation, and research workflows need a different pattern. A single broad credential that lives for hours creates too much concentrated risk. A better design segments access by stage, tool, or action class. Each step gets the narrowest possible credential for that slice of work. A 1 to 6-hour TTL may be operationally reasonable for some stages, but compartmentalization does more security work than the number alone.

Fallback cases and explicit exceptions

Some third-party dependencies still only support static API keys. Some legacy systems are hard to retrofit. Some refresh paths are fragile enough that teams keep a longer-lived fallback credential in reserve. Those exceptions need strict ownership, narrow scope, review cycles, and strong monitoring. They should sit within an exception process, not within the normal architecture.

Safe TTL includes scope, issuer trust, revocation path, and observability, not just predicting reasonable reissuance intervals.

Why Dynamic Issuance Gets Hard in Production

Identity and runtime complexity pile up fast, and the operational friction is real. OAuth token exchange flows can be awkward in distributed systems. Workload identity federation varies across cloud providers. Vault and broker systems become important control planes that need their own availability and recovery story.

Runtime logic adds more complexity. Tokens need caching. Expiry windows need careful handling. Clock drift can create edge cases. A refresh failure in the middle of a workflow can leave behind partial writes, repeated actions, and difficult replay logic.

Developer experience shapes the security outcome

Teams also feel this in day-to-day engineering. Local development becomes harder when credentials are minted dynamically. Staging environments need more supporting services. Debugging takes longer when the auth path includes brokers, temporary tokens, and policy evaluation. Application, platform, and security teams all need a shared operating model.

That pressure explains why static credentials keep showing up. Teams do not choose them because they enjoy the risk. They choose them because dynamic issuance moves a large share of the work into day-two operations.

Brokered and Vaulted Access and Ephemeral Credentials

A healthy pattern is straightforward: the workload proves its identity, and a broker, vault, or cloud identity plane verifies that identity against policy. Only then can the system issue scoped short-lived credentials for a specific task window. When the token expires, the workload has to authenticate again and pass policy again.

While in general, moving any keys to vaults is a strong first step towards reducing standing credential risk, it should not be the end goal. We should be moving towards vault-issued dynamic credentials, cloud-native IAM security tokens, OAuth delegated access, workload identity federation, and sidecar or node-local broker designs.

Good implementation choices narrow the blast radius further

Per-task issuance beats broad agent-global issuance. Brief caching can help reliability, but the cache should never outlive the intended task boundary. Identity proof should be separate from permission grants so the scope can change without rewriting the trust model. Issuance events should be logged. Secrets themselves should never be logged.

That is the control plane story. But, it still leaves one practical question unanswered: "How do we know when the real world drifts away from the intended design?"

Ephemeral Credentials Reduce Exposure. GitGuardian Finds The Failures Around Them.

Short-lived credentials solve one class of problem very well. They shrink the abuse window after a leak. But they do not prevent credentials from leaking, and they do not guarantee that every agent in a real environment uses ephemeral access as the architecture diagram suggests. This is where GitGuardian can help.

Agentic systems create more code, configs, prompts, logs, and automation artifacts. Every one of those surfaces can possibly contain a secret, a token, or a fallback credential that was never supposed to persist. Some will be short-lived and still live enough to matter. Some will be refresh tokens with a longer value. Some will be static keys created during a rushed integration and forgotten after the launch.

Some will sit outside the approved issuance path entirely.

GitGuardian gives teams continuous visibility into that sprawl. It catches exposed secrets in source code, collaboration flows, development pipelines, and operational artifacts before those credentials become a hidden standing risk. That function grows more valuable, not less, in environments that have already adopted short-lived credentials. Mature teams still need a way to find the exceptions, the leaks, and the shortcuts.

The heart of the journey is operational, right where GitGuardian lives

The hardest part of a credential strategy is usually not the first policy decision, but maintaining that strategy under delivery pressure, platform variance, and human shortcuts. This is where GitGuardian can help security teams move from principle to enforcement.

GitGuardian helps teams detect whether their non-human identities have fallen outside their governance policies. You need to know about leaked tokens during their active lifetime, forgotten fallback keys that linger after a migration. You need a clear way to identify secrets introduced by AI-assisted development and surface shadow credentials that bypass the official broker or vault flow. You can not shorten the path from exposure to response without this level of real-time insight.

In practical terms, GitGuardian becomes the feedback loop for your credential architecture. It tells you whether your move toward ephemeral access is actually reducing the number of secrets in code and config. It tells you whether engineering teams are still creating one-off exceptions. It tells you where the safety net needs tightening before a small shortcut becomes a durable blind spot.

GitGuardian helps teams coordinate migration efforts

A shift toward short-lived credentials often needs buy-in from platform teams, developers, and engineering leadership. That buy-in comes more easily when the security team can show where current exposure actually lives.

GitGuardian helps produce that picture. It gives teams a way to inventory existing identities, identify the highest-risk credentials, and prioritize migrations where the security gain is largest. That changes the internal conversation. The move to ephemeral credentials becomes a measurable risk-reduction program rather than a generic security ask.

In agentic environments, the GitGuardian platform supports the transition away from static credentials, helps detect the real-world failures that still happen during that transition, and gives teams continuous visibility after the new model is in place.

Start With Visibility, Then Fix The Highest-Risk Paths

To move towards better agentic access, you need to make a plan.

Begin by inventorying agent-to-system credentials across code, configs, pipelines, notebooks, and runtime integrations. Find the static keys with the highest privilege and widest reuse. Add continuous secret detection everywhere those artifacts live.

You need visibility before you can cleanly reduce standing risk.

Move new workflows to dynamic identity

Use workload identity, brokered short-lived tokens, or scoped delegated access for new agent workflows. Set TTL by agent class rather than by team preference. Instrument issuance and expiry events. Measure refresh failures and recovery paths.

Break broad permissions into stages

As systems mature, split long-running workflows into stages with separate credentials. Remove shared credentials across agents and tenants. Drill revocation and rotation so the response becomes operational muscle memory. GitGuardian will catch the exceptions, leaks, and drift that architecture alone will miss.

Treat long-lived credentials as governed exceptions

Reserve long-lived credentials for explicit cases with clear owners, narrow scope, regular review, and compensating controls. Exception paths have a habit of becoming permanent, and this is something teams must stay on top of. Continuous monitoring is what keeps an exception from quietly turning back into the default.

The Best Strategy Is Measurable and Hard to Abuse

Short-lived credentials should be the default for agentic systems because they sharply reduce exposure when a credential crosses its intended boundary. That is the right baseline. Production systems still have to carry the weight of token brokers, workload identity, refresh logic, and brittle third-party integrations.

If you are looking for a better path forward, we suggest tying TTL to agent behavior and privilege. Use dynamic issuance where it materially reduces blast radius. Segment long-running workflows. Keep long-lived credentials inside explicit exception handling. Then add continuous secret monitoring as the layer that sees what the model misses, catches what the rollout leaves behind, and shortens the distance from leak to response.

Ephemeral access changes the risk curve. GitGuardian helps teams prove they are actually moving along with it. We would love to help you get started on your path to better agentic access management.