devopsy.kinsta.cloud

Tag: non-human identities

GitHub Ties Every Commit to the Account That Pushed It

GitHub is adding a new piece of identity data to every commit: The authenticated account that pushed it.

The feature, called push attribution, entered limited public preview on October 12 for GitHub Enterprise customers. GitHub now records the user who pushed each commit and shows that pusher identity in the UI and the API, next to the existing author and committer fields. It also adds a repository rule that can block pushes when the committer doesn’t match the person doing the pushing.

It sounds like a small change. But it closes a gap that has existed since the beginning of Git.

The Problem With Author and Committer Fields

Git was built as a distributed system. Commits get created on a laptop, passed between collaborators, and pushed to a remote later. So the author and committer fields are just text the client supplies. Anyone can set user.name and user.email and claim to be anyone.

GitHub’s changelog spells out the risk. Anyone with write access to a repository can set those fields to any name and email. An attacker who compromises a low-privilege account can forge commits that look like they came from a trusted maintainer. That can slip past review policies and muddy audit trails.

GitHub has always authenticated pushes. It didn’t, however, keep a durable, per-commit record of who pushed. Once a commit landed, the only identity on display was the one the client claimed.

Signed commits help. A GPG, SSH, or S/MIME signature proves the key holder created the commit, and GitHub shows a Verified badge when the check passes. But signing is opt-in. Many teams don’t enforce it, and unsigned commits still display whatever name the author typed.

What Changes With Push Attribution

The preview adds two things.

First, every commit pushed to a repository gets an authenticated pusher identity. That identity sits apart from the author and committer metadata, and it shows up wherever commits are displayed. Reviewers and incident responders get one identity on each commit that the client didn’t make up. Instead of matching push events in audit logs to individual commits, they can see the pusher on the commit itself. GitHub says teams can use it to spot-check suspicious activity and speed up security investigations.

Second, there’s a new ruleset condition called “Committer must match pusher.” When enabled, it blocks any push where the committer metadata doesn’t match one of the authenticated pusher’s verified email addresses. Administrators add it through rulesets, the same mechanism already used to control who can push to a branch and how commits must be formatted.

The first piece makes spoofing visible. The second makes it harder to pull off in the first place.

“Commit authorship has been self-reported since Git began, and enterprise audit trails were built on it anyway,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group. “Push attribution puts one identity on each commit that the client cannot invent.”

Why It Matters Now

Software supply chain attacks often come down to trust. The 2024 backdoor in the xz Utils compression library showed how much damage follows when someone gains maintainer-level trust and abuses it. Push attribution wouldn’t stop a patient insider like that. But it does make it harder for someone with a stolen low-privilege token to impersonate the people a team trusts most.

AI coding agents add another layer. Bots, agents, and automation tokens now write and push more commits instead of people at keyboards. When something goes wrong, teams need to know which account actually put the code into the repository. A commit can carry a human’s name in the author field while an agent’s token did the push. Push attribution records that difference instead of hiding it.

What to Check Before Turning on the Rule

The pusher field is passive. The ruleset isn’t, and it could break some workflows.

Plenty of legitimate processes push commits that carry someone else’s committer email. A maintainer pushing a contributor’s branch. A release bot pushing commits made elsewhere. A migration that imports years-old history. Teams should inventory these patterns before enabling the rule broadly.

Ashley expects that inventory to reveal a lot. “Release bots, shared tokens, and agents running on borrowed credentials all surface at once,” he said. “The match rule is where teams find out how many workflows depend on one identity acting for another.”

His advice is to fix identity first. “Engineering leaders should give every agent its own accountable identity before enforcing the rule, or the bypass list becomes the new audit.”

The announcement also leaves open questions. It doesn’t yet explain how the rule treats bypass lists, bot identities, deploy keys, GitHub-generated commits, or commits with multiple authors. That’s normal for a limited preview. But it means teams should test in a few repositories before rolling it out.

Push attribution doesn’t replace existing controls either. Tight write-access management, required reviews, and commit signing still matter. A compromised account with legitimate access can still push malicious code under its own name. The difference is that the name will now be accurate.

Availability

Push attribution is available now as a limited public preview for GitHub Enterprise customers. Organizations that want in need to contact their GitHub account team. GitHub hasn’t said when the feature will reach general availability or whether it will come to other plans.

For DevOps teams, the takeaway is simple. Git’s author fields have always been a claim, not proof. GitHub now records the identity that actually pushed and lets admins require the two to match. It won’t stop every attack. But it takes an easy one off the table.

October 14, 2026
Secrets Sprawl and Rotation: A Practical Vault Management Playbook
In 2025 alone, security firm GitGuardian detected 28.65 million new hardcoded secrets exposed in public GitHub commits — a 34% increase year over year and the largest single-year jump the company has recorded in five years of publishing its annual State of Secrets Sprawl report. Since 2021, that number has grown 152%, far outpacing the 98% growth in GitHub’s active developer base over the same period. Secrets sprawl isn’t a hypothetical DevOps hygiene problem anymore. It’s accelerating faster than most security teams can respond to it, and AI-assisted development is a large part of why.

The financial stakes keep climbing alongside it. IBM’s newly released 2026 Cost of a Data Breach Report puts the global average cost of a breach at $4.99 million, a 12% increase over the prior year and a new record high. In IBM’s 2025 edition, breaches where compromised credentials were the initial access vector carried a $4.67 million average cost on their own, and organizations took an average of 246 days just to identify and contain them. A single hardcoded credential, sitting in a repository or a config file for months, is exactly the kind of quiet, slow-burning exposure that produces numbers like these.

Why Secrets Sprawl is Getting Worse, Not Better

The intuitive assumption is that better tooling and more awareness should be shrinking this problem over time. The data says the opposite is happening, and AI-assisted coding is a specific, identifiable accelerant.

GitGuardian’s 2026 report found that secrets tied to AI services grew 81.5% year over year, making them the fastest-growing category of leaked credentials in the entire dataset. Model context protocol (MCP) configuration files, which became a de facto standard for connecting LLMs to external tools and data sources in 2025, already had 24,008 unique secrets exposed in their first year of widespread use. The report links this pattern partly to official documentation that suggests passing API keys as command-line arguments or storing them directly in JSON config files. The report also found that commits produced with AI coding assistance leaked secrets at roughly twice the rate of the GitHub-wide baseline. This was not because AI tools are malicious, but because they generate working code quickly, including secrets, without the natural pause a developer might take to ask whether a credential belongs in that file.

The consequences of this pattern aren’t abstract. GitGuardian’s research points to the Smithery.ai incident as a concrete illustration: A path-traversal vulnerability in an MCP registry exposed overprivileged tokens, granting arbitrary code execution across more than 3,000 hosted servers from a single flaw. That’s what secrets sprawl actually costs when it intersects with infrastructure that’s more centralized and more automated than the credentials scattered across it were ever designed to be.

Two other findings from the same report should reshape how security teams think about the shape of this problem, not just its size. First, internal repositories are six times more likely than public ones to contain hardcoded secrets; the sprawl problem is worse exactly where fewer external eyes are watching. Second, and more troubling, 64% of secrets that leaked in 2022 are still valid and exploitable today. Detection without remediation and rotation isn’t solving anything; it’s cataloging a problem that never actually gets fixed.

Step One: Get Secrets out of Code Entirely

The starting point for any serious secrets program is removing hardcoded credentials from source control and configuration files and centralizing them in a purpose-built secrets manager — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault or Google Secret Manager are the common choices, and the specific product matters less than the discipline of having exactly one control plane rather than credentials scattered across a dozen tools and files.

In practice, this means infrastructure code references a secret at runtime instead of embedding the value directly:
- data “vault_generic_secret” “db_creds” {
- path = “database/creds/readonly”
- }
- resource “aws_db_instance” “app” {
- identifier = “appdb”
- username = data.vault_generic_secret.db_creds.data[“username”]
- password = data.vault_generic_secret.db_creds.data[“password”]
- }
The credential itself never touches version control. Terraform state still needs its own protections — state files can contain resolved secret values — but that’s a narrower, more tractable problem than an organization-wide habit of pasting API keys directly into .env files and Terraform variables under deadline pressure.

Step Two: Enforce Least Privilege Inside the Vault Itself

Centralizing secrets in one place is necessary but not sufficient. Without access controls, a single compromised service account can retrieve far more than it should ever need, turning one small breach into a much larger one. Fine-grained policies scoped to exactly what each service or role requires are what actually limit the blast radius:
- path “database/creds/production” {
- capabilities = [“read”]
- allowed_parameters = {
- “role” = [“readonly”]
- }
- }
The principle here is simple and easy to state but consistently hard to enforce in practice: A service that only ever needs read access to a database should have no path, under any policy, to a credential capable of writing to it. Every broad grant made ‘just in case’ during an incident and never walked back afterward is exactly the kind of standing risk that GitGuardian’s “64% still valid” finding describes at scale.

Step Three: Make Secrets Short-Lived by Default

Static, long-lived secrets are dangerous specifically because they don’t expire on their own. A credential leaked once in 2022 that nobody rotated is, per the data above, still a live risk in 2026. Dynamic secrets flip this: Instead of a fixed, standing credential, the secrets manager generates a short-lived one on demand, tied to a specific request, that expires automatically.

HashiCorp Vault’s database and cloud secrets engines are a common way to implement this — for example, generating a temporary AWS IAM identity scoped to a single task, valid for a bounded window, rather than handing a service a permanent access key it holds indefinitely. For secrets that genuinely can’t be made dynamic (some third-party API keys, for instance), a rotation strategy modeled on blue/green deployments works well in practice: Maintain both a current and a next-version secret, validate that the new one works end-to-end, then cut over and revoke the old one rather than rotating in place and hoping nothing breaks mid-transition.

The goal in both cases is the same: Shrink the window during which a leaked credential is actually useful to an attacker, since detection and remediation alone clearly aren’t keeping pace with the volume of secrets being created.

Step Four: Assume You’ll Need to Prove What Happened

A secrets manager without audit logging tells you what secrets exist, but nothing about who accessed them, when or whether that access was expected. Enabling audit devices — piping access logs to a SIEM, Splunk instance or equivalent — turns “we think this credential might be compromised” into “we can see exactly when and how it was used,” which is the difference between a fast, contained response and a slow, uncertain one.

This matters more, as AI agents get direct access to infrastructure. An agent with a standing credential and no logged trail of what it did with that credential is a much harder incident to investigate than one whose every access is recorded against a specific task and timestamp.

A Practical Playbook

Bringing this together into a sequence a team can actually execute:

Discover What’s Already Exposed: Run a secrets-scanning tool such as GitGuardian or TruffleHog across your full repository history, not just the current branch. Leaked secrets frequently persist in old commits long after the file that contained them was ‘fixed’. Given that 64% of secrets leaked in 2022 are still valid, assume old findings are still live until you’ve confirmed otherwise.
1. Remove and Rotate, Don’t Just Delete: Purging a secret from source history without rotating the underlying credential leaves the exposure intact — the value is already out, likely already scraped and cached elsewhere. Rotate first, then clean the history
2. Stand up a Single Secrets Manager: Consolidate into one control plane rather than a patchwork of environment variables, CI/CD secret stores and cloud-provider-specific tools that nobody has a complete inventory of.
3. Apply Least-Privilege Policies From Day One: Default every new service account and role to the narrowest access that lets it function and require an explicit, logged decision to widen it — never the reverse.
4. Convert Static Secrets to Dynamic Ones Wherever the Secrets Engine Supports It: Start with the highest-value targets. Database credentials and cloud IAM roles are usually both the most common and the most damaging if leaked.
5. Automate Rotation for Everything That Can’t be Made Dynamic: Implement scheduled rotation, blue/green cutover and automatic revocation of the previous version once the new one is confirmed to be working.
6. Enable Audit Logging and Route it Somewhere Your Security Team Actually Monitors: A log nobody reviews provides the appearance of visibility without the substance of it.
7. Pay Specific Attention to AI Tooling: Treat MCP configuration files, AI agent service accounts and CLI-passed API keys as a distinct category worth auditing on their own, given how disproportionately fast that category of leak is growing.
8. Revisit the Entire Inventory Quarterly: Secrets sprawl isn’t a project with an end date. GitGuardian’s own data shows the problem accelerating year over year, which means a program that isn’t actively maintained will fall behind, not stay even.
Conclusion

Secrets sprawl persists not because teams don’t know hardcoded credentials are risky, but because detection alone doesn’t fix anything. A scanner that finds a leaked key changes nothing if nobody rotates it, and the data shows that gap is exactly where organizations are failing. Centralizing secrets in a single control plane, enforcing least privilege inside it, converting static credentials to short-lived dynamic ones and treating audit logging as non-negotiable together close that gap in a way that scanning by itself never will.

With breach costs at a record $4.99 million globally and secrets exposure still growing faster than the developer population producing it, the return on actually finishing this work — not just starting it — has never been more direct.
October 8, 2026
The Trust Graph: Why Infrastructure Diagrams No Longer Describe Modern Systems

There is a ritual I’ve watched play out in more incident retros than I can count. Someone pulls up the architecture diagram — the one in Confluence, the one that hasn’t been touched since the last audit — and starts tracing boxes. Load balancer. VPC. RDS instance. EKS cluster. Everyone nods because the diagram is comforting. It’s also increasingly a lie of omission.

It doesn’t show the GitHub Action that has write access to three cloud accounts. It doesn’t show the OIDC federation between your CI runner and your production IAM role. It doesn’t show the third-party SaaS chatbot holding a long-lived OAuth token that your sales team connected to Salesforce 18 months ago and forgot about. It doesn’t show any of the things that actually decide whether an attacker gets from “found a bug in a support ticket” to “exfiltrated your customer database.”

That’s because the diagram was never wrong, exactly. It was just answering a question nobody asks anymore. Modern systems don’t fail — or get breached — because a box in a topology diagram went down. They fail because a ‘relationship’ between two identities was more powerful, more persistent or less scrutinized than anyone realized. Call it what it is: A trust graph. Most engineering organizations are troubleshooting the wrong picture entirely.

Put the two pictures side by side and the gap is obvious:

Traditional Diagram Trust Graph

The left-hand diagram tells you where packets travel. The right-hand one tells you where an attacker travels — and increasingly, where a normal Tuesday-afternoon outage travels too. Networks determine where packets go. Trust determines where attackers go. Those used to be roughly the same map. They aren’t anymore, and the distance between them is where every incident in this piece actually happened.

The Diagram Problem

Infrastructure diagrams describe ‘what exists’. They don’t describe ‘what can act on what’. A Kubernetes service account, a Terraform state file with an assumed role, a GitHub Actions workflow with an OIDC trust policy to AWS, an AI agent with a standing API key to your CRM — none of these show up as nodes on a topology map; yet, each one is a live, exploitable edge in the actual system that runs your business.

I’d argue this gap is now the single biggest blind spot in platform engineering, and the numbers back it up. Palo Alto Networks’ 2026 Identity Security Landscape report — the successor to CyberArk’s long-running survey, following the acquisition — puts the ratio of machine identities to human identities at 109 to 1, up from 82 to 1 just a year earlier. Of every 109 machine identities for each human, 79 are AI agents. Other vendors land on different numbers — Veza says 17:1, Entro Labs says 144:1 in cloud-native environments — and the spread itself is the point. Nobody can agree on the ratio, but every measurement agrees on the direction.

None of that would matter much if these identities sat still. They don’t. They authenticate constantly; they hold standing permissions and — this is the part that should keep platform teams up at night — roughly 80% of organizations report having no formal, documented policy for creating or retiring them. We spent a decade building governance around human accounts: Onboarding, offboarding, access reviews, MFA. Then we quietly built a second workforce, 10 to over a 100 times larger, with almost none of that discipline attached.

A Vocabulary for the Thing We’re Actually Looking At

If the trust graph is real, it needs its own language, because ‘IAM’ and ‘network topology’ don’t capture the dynamics that matter operationally.

‘Trust nodes’ are any identity capable of independent action — a service account, a workload identity, a CI job, an AI agent, a webhook integration. Not every node is equally dangerous; what matters is what it’s trusted to do.

‘Trust edges’ are the relationships that let one node act as, or on behalf of, another — an OIDC federation, an assumed IAM role, an OAuth grant, a shared secret baked into a pipeline. An edge is a promise: ‘If you present this credential, I will treat you as authorized’.

‘Trust amplification’ happens when a low-privilege node sits upstream of a high-privilege one. A GitHub Action that seems trivial — say, a file-diffing utility — becomes catastrophic the moment it’s allowed to print CI runner memory into a public log, because that memory contains the actual secrets used downstream. The action itself was never the target. It was the amplifier.

‘Trust bottlenecks’ are the single edges that, once compromised, unlock disproportionate reach — a shared CI bot token used across an entire GitHub organization, or a single SaaS integration connected into every business unit’s Salesforce instance.

‘Trust cascades’ are what happens when an amplifier meets a bottleneck: One compromised edge propagates outward across systems that were never architecturally related, only ‘trust-related’.

These aren’t abstractions. 2025 gave us two textbook cases, back to back.

Case One: The Amplifier

On March 14, 2025, at roughly 9 a.m. Pacific, a popular open-source GitHub Action called tj-actions/changed-files — used in over 23,000 repositories — started quietly printing CI/CD secrets into public build logs. Attackers had retroactively modified multiple version tags to point at a malicious commit, meaning even organizations pinned to a specific release were affected. The compromise ran for roughly 15 hours before GitHub pulled the repository. The vulnerability was assigned CVE-2025-30066.

The forensic trail, pieced together by StepSecurity, Wiz and Palo Alto’s Unit 42, is a near-perfect illustration of trust amplification. Investigators found that the attacker likely first compromised a separate, less-visible action, reviewdog/action-setup, and used a leaked token from that dependency to reach the higher-value tj-actions repository. Unit 42’s later analysis suggested the campaign actually began as a targeted operation against Coinbase’s repositories before the attacker apparently lost that focus and widened the blast radius indiscriminately.

Look at what that means in trust-graph terms. reviewdog/action-setup was a low-privilege trust node — a setup utility, the kind of dependency nobody reviews twice. However, it sat upstream of tj-actions/eslint-changed-files, which sat upstream of tj-actions/changed-files itself, which was a trust edge running inside 23,000 separate CI pipelines. That’s a trust amplifier by definition: A small, boring node whose downstream reach was enormous. Also, because every one of those 23,000 pipelines trusted the same tagged reference, the compromised action functioned as a trust bottleneck — one credential, one repository, one retagged commit — and the blast radius touched every organization that depended on it. No topology diagram would ever have flagged reviewdog/action-setup as load-bearing. On the trust graph, it was one of the most connected nodes in the software supply chain.

Case Two: The Cascade

Five months later, the pattern repeated at a different scale, through a different kind of node: An AI agent.

Between August 8 and 18, 2025, a threat cluster tracked as UNC6395 used stolen OAuth tokens belonging to Salesloft’s Drift — an AI chatbot widely embedded into corporate Salesforce instances for live chat and lead generation — to walk into hundreds of enterprise environments without triggering a single password prompt. Over roughly 10 days, the group ran systematic queries against more than 700 organizations, including Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint and Zscaler, exporting support-case data at scale. Since Drift’s OAuth tokens had been granted broad reach, investigators later found the same stolen credentials also opened doors into Slack, Google Workspace, AWS, Azure and OpenAI accounts connected through the same integration.

The attackers weren’t after Salesforce itself. They were combing exported case text for plaintext AWS keys, Snowflake tokens and VPN credentials that customers had pasted into support tickets — using one trust edge to go fishing for the credentials needed to open the next one. Google put the confirmed toll at over 700 organizations impacted. Fastly, Workday and Toast each independently confirmed exposure and moved to sever the integration and rotate tokens once notified.

Nothing about this incident involved a firewall misconfiguration, an unpatched server or a phished employee clicking a bad link in the conventional sense. It involved one AI agent’s OAuth grant sitting at the center of an enormous number of downstream trust edges — a single node whose blast radius nobody had mapped, because nobody draws a diagram of ‘what a chatbot integration is allowed to touch’.

The Reliability Angle Nobody’s Pricing in Yet

Security teams are (slowly) absorbing this. Reliability and platform teams mostly aren’t, and that’s the second half of the argument. About 10 years ago, an outage was usually a resource problem — CPU, memory, disk, a bad deploy. Increasingly, it has become an authorization problem: An expired workload identity token, a revoked service account nobody flagged as load-bearing, an OIDC trust relationship that silently broke after a provider-side change.

This is the automation paradox in one sentence: The more you remove humans from a deployment pipeline, the more that pipeline’s reliability depends on identity, not infrastructure. A human on-call engineer can route around a broken dependency. An automated pipeline authenticating via a dead workload identity just fails, silently, at 2 a.m. and the postmortem reads like a security incident even though nothing was ‘hacked’. The OWASP Foundation formalized this shift in its 2025 Non-Human Identities Top 10, codifying failure modes — improper offboarding of retired service accounts, secret leakage into logs and repos, insecure machine-to-machine authentication — that read like an SRE runbook as much as a security framework, because at this point, they’re the same document.

The scale of what’s now ungoverned is the part that should reframe how platform teams prioritize. GitGuardian’s 2026 State of Secrets Sprawl report found 28.65 million hardcoded secrets added to public GitHub repositories in 2025 alone — a 34% jump year over year, the largest single-year increase on record — with AI-service-related leaks specifically up 81.5%. Of the secrets confirmed live back in 2022, roughly 64% remain exploitable as of this January — meaning most organizations aren’t just failing to prevent new exposure, they’re failing to clean up exposure they already know about.

What This Actually Changes About the Job

If you accept that the trust graph is the real architecture, a few practical things follow and none of them are “buy another dashboard.”

First, threat modeling has to include CI/CD dependencies as first-class production infrastructure, not developer tooling. reviewdog/action-setup wasn’t a footnote; it was the entry point. Every transitive action, every third-party GitHub App, every Terraform module pulled from a public registry is a trust edge with the same blast-radius potential as a misconfigured security group — arguably more, because almost nobody reviews it with the same rigor.

Second, every SaaS integration and AI agent needs an owner and a documented scope, the same way a production database needs one. “We connected Drift to Salesforce for lead routing” is a perfectly reasonable business decision. “Nobody remembers what data Drift can touch, or that its OAuth token never expires” is the actual vulnerability, and it’s a governance failure, not a technical one.

Third — and this is the harder cultural shift — reliability engineering and identity security need to stop being separate disciplines with separate tooling and separate on-call rotations. An expired workload identity that breaks a deployment pipeline and a stolen OAuth token that exfiltrates customer data are the same category of failure: A trust edge that behaved in a way nobody had modeled. Treating one as an SRE problem and the other as a SOC problem guarantees blind spots exactly where the two disciplines don’t talk to each other.

The old diagram isn’t wrong. It’s just describing a system that stopped being the whole story around the time OIDC federation, service meshes and autonomous agents became normal. The graph that actually determines whether your organization has a good week or a very bad one is the one made of trust edges — and right now, almost nobody is drawing it, reviewing it or putting an owner’s name on it. That’s not a tooling gap. It’s an architecture gap, and it’s the one worth arguing about in 2026.

July 23, 2026
Your CI/CD Pipeline Has Non-Human Identities You Forgot About
A deployment starts failing late on a Friday evening.

The initial assumption is that something changed in the application release. Teams start checking container images, Terraform plans and recent commits. Nothing looks wrong.

A few hours later, someone discovers the actual issue: a deployment token tied to an old automation workflow expired months ago. The token was still being used by a pipeline nobody realized was active.

The original engineer who created it had already moved to another team.

Situations like this are becoming normal in modern delivery environments. Not because organizations suddenly lost visibility into human access, but because CI/CD systems now create machine identities constantly. Most of them are temporary. Some become permanent without anyone planning for it.

A few years ago, infrastructure access mostly revolved around employees, administrators and service accounts that teams could track manually. That model no longer holds up very well.

Today’s pipelines rely on build runners, deployment bots, ephemeral workloads, repository integrations, infrastructure automation accounts and short-lived cloud credentials moving across multiple systems at once. Some exist for minutes. Others stay around for years after their original purpose disappeared.

The harder part is figuring out how much access quietly exists between systems.

Most organizations can usually tell you which employees still have production access. Tracking older automation workflows, deployment runners and pipeline credentials is often much less clear.

Machine Access Builds Up Quickly in CI/CD Systems

Modern software delivery pipelines create and consume identities almost nonstop.

A single deployment workflow may involve:
- repository actions
- build runners
- container registries
- cloud workload identities
- Kubernetes service accounts
- infrastructure automation tools
- artifact signing systems
- secret managers
- deployment orchestrators
Each step often introduces another credential, access dependency or permission change.

A GitHub Actions workflow might assume a cloud role during deployment. A Kubernetes controller may retrieve secrets dynamically at runtime. Terraform automation could receive temporary permissions to create infrastructure resources before handing execution to another pipeline stage.

None of this is unusual anymore. Most teams depend on these workflows daily.

A lot of existing access management processes still assume identities are relatively static and tied to employees.

CI/CD environments behave very differently.

Identities appear temporarily during builds. Permissions get copied between environments to speed up deployments. Automation accounts survive long after projects are retired because removing them feels risky. A pipeline integration created during an outage quietly becomes part of the environment long-term.

Over time, these workflows start depending on access paths nobody fully tracks anymore.

In many environments, the delivery pipeline itself quietly becomes one of the most privileged systems in the organization.

It shows up in small ways first. An old Jenkins runner still has production deployment permissions even though the project was retired months ago. A GitHub Actions workflow keeps using the same cloud role across development and production because splitting access would slow down releases. A Kubernetes service account originally scoped for one namespace quietly gains broader cluster permissions after multiple troubleshooting changes over time.

Why Traditional IAM Visibility Starts Breaking Down

Traditional IAM processes were built around employees joining, changing roles and eventually leaving.

Automation does not follow the same lifecycle.

One deployment workflow may use:
- a repository token
- a cloud role
- a Kubernetes service account
- a shared deployment credential
- several secrets injected at runtime
After a while, it becomes difficult to tell who still owns what.

Security teams may know the service account exists, but not which pipeline still depends on it. Infrastructure teams may rotate one credential without realizing another automation workflow still references the old version. Permissions granted during emergency fixes remain in place because nobody wants to risk breaking deployments later.

This is how temporary access slowly becomes permanent infrastructure.

Shared automation credentials make the problem worse. In some environments, multiple pipelines reuse the same secrets across staging and production simply because separating them would require refactoring old workflows. In some cases, old deployment repositories still retain access tokens for cloud environments that are no longer actively maintained, simply because nobody is fully certain what might break if they are removed.

Teams also copy permissions between projects more often than they realize.

A deployment role that originally needed read-only storage access suddenly receives write permissions because another pipeline required it during a migration. Later, a different project reuses the same configuration template. The permissions continue expanding even though nobody revisits the original assumptions.

The result is usually not one catastrophic configuration mistake.

It is years of small operational shortcuts accumulating quietly across delivery systems.

Most of them look harmless individually.

Together, they create environments where organizations no longer have a reliable inventory of which non-human identities can access critical systems.

Security Problems Teams Usually Miss

The risks usually do not come from one obviously dangerous credential sitting in a repository.

Most of these problems build up slowly across multiple systems.

A deployment pipeline may still have access to production environments long after the original application was decommissioned. Shared secrets reused across environments make lateral movement easier during incidents. Build runners sometimes receive broad infrastructure permissions simply because restricting them would require redesigning older workflows.

Repository integrations create another blind spot. An automation token added temporarily during a migration may continue retaining write access years later because nobody wants to risk breaking the pipeline by removing it.

Teams also underestimate how much production access exists inside CI/CD systems themselves. Build infrastructure often connects directly to artifact registries, cloud environments, deployment platforms and secret managers at the same time.

Once attackers gain access to a pipeline with elevated permissions, the CI/CD environment can become a path into multiple systems at once.

What Actually Helps

Another dashboard showing thousands of machine identities usually does not solve the real problem.

What teams usually need instead is clearer ownership and shorter trust chains.

A good starting point is inventorying which non-human identities still have production access and which systems actually depend on them. Many organizations discover old deployment runners, unused automation accounts or long-lived credentials that nobody intentionally kept.

Separating build and deployment permissions also helps reduce unnecessary exposure. Build systems do not always need direct production access. In many environments, they inherited those permissions simply because the pipeline evolved faster than the security model around it.

Short-lived workload identities reduce some of the long-term credential problems that static secrets create. Regular reviews of repository integrations, cloud role assumptions and pipeline-to-cloud trust relationships help prevent older exceptions from becoming permanent infrastructure.

A few operational practices help reduce long-term access sprawl:
- Inventory which non-human identities still have production access.
- Separate build and deployment permissions wherever possible.
- Regularly review old pipeline integrations and cloud role assumptions.
Most importantly, CI/CD systems should be treated as production infrastructure themselves.

They already hold privileged access across large parts of the environment. Security reviews that focus only on applications while ignoring delivery pipelines leave a significant portion of operational risk unexamined.

Most organizations already know who their employees are.

Fewer know which machines still have access to production.
May 14, 2026