TL;DR: Teleport says modern infrastructure now depends on non-human identities that still rely on static credentials, excessive permissions and minimal oversight across CI/CD, IaC, multi-cloud federation and MCP-driven automation. Human-paced trust models do not survive machine-paced execution, so governance must shift to short-lived identity and job-scoped authorization.
At a glance
What this is: Teleport argues that infrastructure now runs on NHIs that are still trusted with long-lived secrets and broad permissions, creating visibility and resiliency gaps across automation paths.
Why it matters: IAM, PAM and NHI teams need to treat CI/CD, IaC, federation and MCP access as governed machine identity lifecycles, not as incidental automation detail.
👉 Read Teleport's analysis of non-human trust problems in infrastructure
Context
Non-human trust problems emerge when automated systems are allowed to act with human-level reach but without human-level review. In this article, that problem shows up in CI/CD runners, infrastructure-as-code jobs, cloud federation and MCP-enabled AI actions, all of which depend on machine credentials that are often too long-lived and too broadly trusted.
Teleport frames the issue as an identity governance problem, not just an infrastructure convenience problem. The core issue is that non-human identities are frequently authenticated with static secrets and broad permissions even though their actions are runtime-bound, job-bound and frequently cross-environment.
The article also extends the discussion into AI-triggered infrastructure actions through MCP, which makes the trust gap more visible. Once prompts can trigger operational changes, identity, authorisation and audit controls have to be designed for machine speed rather than human approval cycles.
Key questions
Q: What breaks when CI/CD pipelines rely on static secrets?
A: Static secrets create a reusable attack path into production infrastructure. Once they are copied into workflow files, logs, runner images, or environment variables, a single compromise can expose broad access long after the original job finishes. That is why pipeline secrets should be treated as production identity, not temporary configuration.
Q: Why do broad machine permissions increase infrastructure risk?
A: Broad permissions increase risk because automation rarely needs permanent, cross-environment authority to finish one task. When a workload identity can deploy, mutate and restart beyond its immediate job, the credential becomes a lateral movement path. Least privilege only works when the scope matches the execution context, not the team’s convenience.
Q: How do teams know if machine identity governance is actually working?
A: Look for evidence that each service account has a current owner, a narrow purpose, a short credential lifetime, and a clear retirement path. If any of those are missing, the programme may appear controlled on paper while still leaving durable access paths in production.
Q: What is the difference between static credentials and workload identity?
A: Static credentials are reusable secrets stored somewhere on disk or in a manager, while workload identity uses runtime-issued assertions or certificates that expire quickly and are tied to a specific service or task. For NHI governance, workload identity is preferable because it limits reuse, reduces persistence, and narrows the blast radius of theft.
Technical breakdown
Why static credentials fail in CI/CD automation
CI/CD systems are execution identities, not just delivery tools. When runners, bots or build agents authenticate with long-lived tokens, shared SSH keys or environment variables, compromise of the pipeline becomes compromise of the credential itself. The problem is not only leakage but persistence: the same secret may be reused across jobs, environments and repositories, expanding blast radius and making revocation slow. Short-lived certificates shift the trust boundary to the job, while scoped issuance makes each workflow session unique and auditable.
Practical implication: treat every CI/CD credential as ephemeral workload identity and eliminate reusable secrets where the pipeline can mint time-bound identity instead.
How IaC permissions drift into overprivilege
Infrastructure-as-code workflows often inherit broad cloud service account permissions because teams optimise for deployment success rather than per-task authorisation. That creates a mismatch between declared intent and effective access: a Terraform or Pulumi run may need to create one resource, but the credential can also alter unrelated infrastructure. Per-job identity issuance and role assumption narrow this gap by binding the credential to a repository, environment and job context. The control issue is scope, not tooling speed.
Practical implication: map IaC execution roles to specific deployment tasks and remove standing cloud keys from automation paths.
Why MCP changes the trust model for AI-triggered operations
MCP is important here because it gives models a standardized path to tools and data sources, which means the identity problem moves from UI trust to runtime authorisation. Once an AI model can trigger actions directly, shared API keys and coarse RBAC no longer answer the question of which prompt caused which action. Short-lived cryptographic identities, explicit action scoping and per-action logging are the technical response, because the agent or model context needs accountability at execution time, not after the fact.
Practical implication: bind AI-triggered infrastructure actions to short-lived identities, explicit scopes and tamper-evident audit logs.
Threat narrative
Attacker objective: The objective is to turn one compromised machine credential into control over deployments, cloud resources and operational tooling.
- Entry occurs when an attacker reaches a CI/CD system, IaC runner or MCP-connected agent that already trusts a reusable credential or broadly scoped workload identity.
- Credential access happens through exposed secrets, shared keys or leaked tokens that can be reused across jobs and environments without immediate revocation.
- Escalation follows when the same identity can deploy code, assume cloud roles, restart services or call tools beyond the original task boundary.
- Impact is achieved when the attacker uses that inherited trust to alter infrastructure, access cloud resources or execute unauthorized operational actions at scale.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Non-human trust debt is now a governance problem, not a tooling problem: Modern infrastructure accumulates trust debt when machine identities are granted more reach than their task requires and then left in place. The article shows that the same pattern repeats in CI/CD, IaC, federation and MCP because the underlying governance model still assumes slower, more reviewable access. Practitioners should read this as a signal that NHI governance has become a first-class control plane.
Short-lived identity is the only durable answer to machine-paced execution: Static secrets and standing permissions were designed for workflows that changed slowly and were easy to review. That assumption fails when bots, runners and agents create, consume and discard access inside a single job or prompt-driven session. The implication is that access control must be issued at runtime, not merely certified after the fact.
MCP exposes the control gap between prompt and privilege: The article’s MCP discussion shows that AI-triggered infrastructure actions are not a separate problem from NHI governance; they are an extension of it. Once a model can invoke tools, the real question becomes whether the action can be attributed, bounded and revoked at the same speed as the prompt that caused it. Teams should treat this as an auditability and scope problem, not an AI novelty.
Runtime trust boundaries: The named concept here is the boundary between identity issuance and identity use in automated systems. When that boundary is too loose, the same credential can outlive the job, the deployment or the prompt that needed it. Practitioners should use this concept to challenge any workflow that still depends on durable secrets for transient machine activity.
From our research library:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: Ultimate Guide to NHIs
What this signals
Runtime trust boundaries: The operational boundary between issuance and use is now the control point that matters most for NHIs in infrastructure. If a credential can outlive the job, the deployment or the prompt, then the environment is still running on standing trust rather than governed trust.
CI/CD, IaC and MCP all reward speed, but speed without scoped identity turns automation into an access multiplier. Teams should expect more pressure to move from secret distribution to ephemeral identity issuance, because that is the only model that scales when machines, not people, are doing the work.
For practitioners
- Replace standing secrets with short-lived workload identity Issue time-bound credentials for CI/CD runners, bots and deployment jobs so each workflow gets only the access needed for that execution window.
- Bind IaC roles to deployment context Scope cloud permissions by repository, environment and job so infrastructure-as-code runs cannot reuse broad service accounts across unrelated targets.
- Separate AI-triggered actions from shared API keys Require MCP-connected agents to obtain per-action identity and explicit operation scopes instead of using one reusable key for many tool calls.
- Log machine-to-machine activity with identity context Capture which workload or agent triggered each deployment, role assumption or infrastructure change so investigators can tie actions back to a specific non-human identity.
Key takeaways
- Modern infrastructure increasingly depends on machine identities that are trusted for too long and too broadly across deployment paths.
- The article ties that trust gap to CI/CD, IaC, multi-cloud federation and MCP-enabled automation, where reused credentials and wide permissions expand blast radius.
- Practitioners need to shift governance from secret management alone to runtime identity issuance, scoped authorisation and auditable machine actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centers on static secrets leaking into automation paths and MCP workflows. |
| NHI-05 — Overprivileged NHI | Broad service account and runner permissions are a core failure mode in the article. | |
| NHI-07 — Long-Lived Secrets | The article repeatedly contrasts durable secrets with short-lived machine identity. | |
| Recommendation — Remove exposed machine secrets from pipelines and replace them with ephemeral credentials. Restrict each workload identity to the minimum task-specific scope it actually needs. Phase out reusable long-lived credentials in favour of time-bound identity issuance. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The compromise path described depends on stolen secrets being reused across automation boundaries. |
| Recommendation — Map pipeline and workload credential exposure to credential access and lateral movement detections. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle and rotation are central because the article is about replacing static secrets. |
| Recommendation — Apply authenticator management to retire static automation credentials and enforce expiry. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud federation and workload identity are a primary subject across the article's examples. |
| Recommendation — Use IAM controls to govern machine identities across cloud and workload boundaries. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The MCP section shows AI-triggered actions failing when identity and privilege are too coarse. |
| Recommendation — Constrain agent identities so tool use cannot exceed the specific action scope granted. | ||
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- 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.
- Device Trust Boundary: The device trust boundary is the point where an endpoint is considered sufficiently verified to access systems, data, or services. It defines the security line between trusted and untrusted device states, based on posture, identity, integrity, and policy. In practice, it governs whether a device can authenticate, connect, or receive sensitive access.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples for securing GitHub Actions, Jenkins and GitLab runners with short-lived credentials
- Terraform and cloud role-assumption patterns for repository-scoped deployment identities
- The MCP access model used to scope AI actions, log prompt-triggered operations and eliminate shared API keys
- A worked example of multi-cloud workload identity using SPIFFE-style certificates and central trust policies
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org