Your infrastructure has a non-human trust problem

At a glance

What this is: This is an analysis of why modern infrastructure has a non-human trust problem, with Teleport arguing that static secrets and broad permissions still dominate NHI access patterns across CI/CD, IaC, multi-cloud, and MCP use cases.

Why it matters: It matters because IAM, PAM, and IGA teams need to govern machine and workload identities with the same discipline applied to human access, while also accounting for agentic automation and runtime trust decisions.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Teleport's analysis of non-human trust across CI/CD, IaC, and MCP

Context

Modern infrastructure now runs on machine and workload identities as much as human users, which means access control has to govern bots, runners, service accounts, and AI-triggered actions as first-class identities. The problem is not automation itself, but the fact that many of these identities still rely on static secrets, broad roles, and weak traceability. For a deeper baseline on the lifecycle and visibility problems behind this pattern, see the Ultimate Guide to NHIs.

The article’s core point is that trust is being granted to non-human actors at the moment they execute, not at the moment they are reviewed. That changes the identity governance problem from periodic certification to runtime control, especially in CI/CD, infrastructure-as-code, multi-cloud federation, and MCP-enabled AI workflows. The practical question for IAM teams is whether current policy, logging, and offboarding models can handle ephemeral machine access without assuming human-style behaviour.

Key questions

Q: How should security teams eliminate static secrets from CI/CD pipelines?

A: Security teams should move from stored credentials to runtime-issued access wherever possible. Use federation for cloud auth, inject short-lived secrets only into the job step that needs them, and keep the secret out of source control, logs, and artifacts. The aim is to remove standing exposure, not just hide it better.

Q: Why do non-human identities increase cloud IAM risk so quickly?

A: Non-human identities increase cloud IAM risk because they multiply faster than human accounts and often carry persistent access with weak ownership. Service accounts, tokens, and API keys can stay active long after the workload or integration changes. Without lifecycle controls, they become a hidden source of standing privilege and lateral movement potential.

Q: What breaks when AI agents rely on shared service accounts or API keys?

A: Shared credentials hide which actor actually performed the action, make revocation coarse, and blur accountability across humans and machines. They also let multiple agents inherit the same authority, which increases blast radius and makes incident investigation much harder when something goes wrong.

Q: Who is accountable when an MCP agent accesses the wrong resource?

A: Accountability sits with the teams that defined consent, token handling, and policy review for the MCP deployment. If token passthrough, weak audience checks, or incomplete client approval allowed the request, that is a governance failure, not an agent anomaly. Frameworks such as NIST CSF and Zero Trust architecture expect explicit access validation.

Technical breakdown

Static secrets in CI/CD pipelines create durable trust paths

CI/CD systems often need fast, repeatable access to cloud and cluster resources, but that speed is commonly achieved with long-lived API tokens, SSH keys, or environment variables. Those credentials are operationally convenient but hard to govern because they persist beyond the job, are easy to copy, and are rarely tied to a specific workload identity. In practice, the issue is not just secrecy but identity ambiguity: the pipeline becomes a durable trust path rather than a controlled execution event.

Practical implication: move pipeline access to short-lived, job-scoped credentials so the identity disappears when the run ends.

Ephemeral workload identity changes how IaC authorisation works

Infrastructure-as-code tools such as Terraform or Pulumi need privileges to create and modify production resources, but those privileges are often granted through broad cloud service accounts or injected secrets. Ephemeral workload identity narrows the trust boundary by binding credentials to a specific job, repository, and environment. That makes authorisation closer to intent and less like standing access, because each deployment can inherit only the minimum role needed for that execution window.

Practical implication: map each IaC workflow to a distinct role and remove shared cloud keys from deployment paths.

MCP requires identity controls for model-triggered actions

The Model Context Protocol connects AI systems to tools and data sources, which means the security problem is not just model output but action execution. If an AI agent can trigger commands, it needs authenticated identity, scoped authority, and logging that ties the action back to the request context. Without that, prompt-driven automation can become unauthorised infrastructure control, especially when the same shared credential is used across multiple tasks or users.

Practical implication: treat MCP sessions as privileged non-human actors and bind every tool call to a scoped, auditable identity.

Threat narrative

Attacker objective: The attacker aims to turn machine trust into durable infrastructure control by abusing non-human credentials that were never meant to outlive the workflow.

1. Entry occurs when static secrets, shared API keys, or long-lived certificates are embedded in CI/CD, IaC, or MCP workflows and become usable outside the original execution context.
2. Escalation occurs when those credentials carry broad permissions across repositories, clusters, or cloud accounts, allowing machine identities to do more than the job actually requires.
3. Impact occurs when an exposed or over-scoped non-human identity is reused for unauthorized deployment, lateral cloud access, or model-triggered command execution at scale.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static credential trust is the real infrastructure governance failure. The article describes a world where bots, runners, and agents still authenticate through long-lived secrets and broad service accounts. That is not a tooling detail. It is a governance failure because the identity layer is being asked to prove trust after the fact, when the access path already exists. The practitioner implication is that non-human access must be treated as a lifecycle problem, not a secrets-only problem.

Ephemeral access is the right control shape for non-human identities, but only if it is tied to execution context. Short-lived certificates and per-job authorization reduce persistence, but they only work when the workload, repository, environment, and action are bound together. Otherwise, you just replace one credential type with another. The implication is that NHI governance should focus on scope, context, and expiry as a single control plane.

Cross-cloud federation exposes the identity blast radius created by inconsistent policy models. When AWS, GCP, and Azure workloads all rely on different trust primitives, the weakest federation path becomes the easiest way to over-extend access. Unified identity policy is therefore not a convenience feature, but a governance requirement for reducing misconfiguration and privilege drift. Practitioners should measure whether a workload can move across environments without creating a new standing trust relationship.

MCP makes runtime trust explicit, which is why agent identity must be governed like privileged infrastructure access. The article correctly treats model-triggered actions as auditable events, not casual API calls. That matters because AI-mediated operations collapse the line between request and execution. The right framing is not whether the model is clever, but whether every tool call is tied to a bounded identity, a role, and a verifiable action trail.

Non-human identity maturity is now a baseline control, not an optimisation project. The Ultimate Guide to NHIs shows how common excessive privilege and poor visibility remain across machine identities. When a modern infrastructure stack depends on CI/CD, IaC, federation, and MCP, those weaknesses become operational fragility as much as security risk. Identity teams should therefore treat NHI governance as part of core resilience engineering.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader view of how these failures show up in the real world, see 52 NHI Breaches Analysis.

What this signals

Non-human identity governance is moving from control inventory to runtime accountability. As infrastructure becomes more software-defined, the old assumption that access can be reviewed after assignment stops working cleanly. Teams should expect greater pressure to prove identity provenance, job scoping, and expiry enforcement across every automated path, especially where pipeline and agent activity converge.

Ephemeral trust will become the default language for machine access programmes. The governance question is no longer whether to allow automation, but whether automation can exist without a durable standing credential behind it. That shift will push IAM, PAM, and platform teams toward shared policy models that treat workload identity as part of infrastructure lifecycle management rather than a separate security silo.

Identity blast radius is the concept practitioners should start measuring. When one non-human credential can span repositories, clouds, and toolchains, the problem is not just privilege level but how far the trust relationship reaches before it is constrained. Programmes that cannot map that blast radius will struggle to justify their current review cadence or their offboarding model.

For practitioners

• Eliminate durable secrets from automation paths Replace hardcoded tokens, shared SSH keys, and injected environment credentials with short-lived workload identities bound to a specific job or session.
• Split cloud roles by workflow and environment Assign separate least-privilege roles for each repository, deployment target, and environment so a single pipeline credential cannot cross boundaries.
• Bind MCP actions to auditable identities Require every tool call from an AI-enabled workflow to carry a scoped identity, role claim, and immutable log trail that links the action to the session.
• Unify federation policy across clouds Standardise workload identity issuance and trust policy across AWS, GCP, Azure, and edge systems so governance does not change by platform.
• Review NHI offboarding and rotation as a lifecycle control Treat runners, service accounts, and workload certificates as governed identities that need revocation, expiry, and ownership review when systems or pipelines change.

Key takeaways

• Modern infrastructure still relies on non-human identities that are trusted far beyond the job they are meant to perform.
• The evidence points to a persistent governance gap between machine access and human identity controls, especially where privileges persist across jobs and clouds.
• Teams should shift to short-lived, scoped workload identity and treat automation trust as a lifecycle and audit problem, not just a secrets problem.

Key terms

• Workload Identity: The identity assigned to a software workload — such as a containerised application, serverless function, or microservice — enabling it to authenticate to other services without storing static credentials.
• Ephemeral Credentials: Ephemeral credentials are short-lived access artefacts issued for a limited task or session. They reduce the window for abuse, but they only improve security when paired with strong scope limits, telemetry, and automatic revocation at task completion.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Teleport's full post covers the operational detail this analysis intentionally leaves for the source:

• Step-by-step examples for issuing short-lived certificates to CI/CD runners and bots in real workflows.
• Implementation detail for GitHub OIDC, AWS role assumption, and SPIFFE-based workload identity patterns.
• MCP-specific examples showing how scoped identity and audit logging are applied to model-driven actions.
• Concrete deployment patterns for multi-cloud federation with central trust and expiration handling.

👉 The full Teleport post covers workload identity examples, federation patterns, and MCP access controls in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.