Zero trust in AWS still fails where static credentials persist

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: Zero trust in AWS breaks down when long-lived credentials and broad access remain in place alongside fast-changing cloud, container, and AI-driven environments.

Why it matters: IAM, PAM, and cloud security teams need to treat static credentials as a structural zero trust problem because the access model must match the pace of modern AWS operations.

By the numbers:

• 68% of cyberattacks involve the human factor in some way, including privilege misuse, stolen credentials, and social engineering attacks.

👉 Read Teleport's recap of zero trust in AWS and static credential risk

Context

Zero trust in AWS is not just a network design question. It is an identity governance problem when long-lived credentials, over-broad roles, and inherited access paths remain available in environments that scale up and down continuously.

This article recaps a Teleport webinar focused on how modern AWS environments, containers, and distributed engineering workflows make static access models increasingly misaligned with operational reality. The same pattern applies wherever human, machine, and workload access are managed through credentials that outlive the session or task they were meant to serve.

The underlying issue is not that AWS lacks control points. It is that zero trust cannot be enforced cleanly when the identity model still depends on persistent secrets and manual trust assumptions.

Key questions

Q: What breaks when zero trust in AWS still depends on static credentials?

A: Static credentials reintroduce standing trust into a model that assumes access should be short-lived and continuously bounded. In AWS, that means IAM users, SSH keys, and database passwords can survive longer than the task they support, creating reuse, audit, and revocation problems that zero trust is supposed to eliminate.

Q: Why do long-lived machine credentials increase cloud risk?

A: Long-lived machine credentials create standing privilege, which gives attackers a reusable access path if the secret is exposed. In cloud environments, that risk compounds because credentials are often copied into code, pipelines, and configuration files, making discovery and lateral movement faster once a single secret is found.

Q: How can security teams tell whether zero trust is actually working in AWS?

A: Look for evidence that access is issued for a narrow purpose, expires automatically, and is auditable across accounts and resource types. If teams still rely on long-lived credentials, broad roles, or manual revocation to control AWS access, zero trust is only partially implemented.

Q: How should security teams govern IAM access for AI agents in AWS?

A: Treat each AI agent as a non-human identity with its own execution role, trust policy, and review cycle. Scope permissions to the smallest working set, remove wildcard access, and validate what the agent can actually do across downstream services. The safest control is to govern the role, not the prompt.

Technical breakdown

Why static AWS credentials break zero trust enforcement

Static credentials create a durable trust relationship that zero trust is designed to avoid. Long-lived IAM users, SSH keys, and database passwords can be reused across sessions, copied into tooling, and left active after the original need has passed. In AWS, that persistence collides with ephemeral compute, distributed engineering access, and frequent environment change. The result is an identity layer that assumes trust can be granted once and left in place, even though the environment no longer behaves that way. Zero trust is not just about proving identity at login. It is about making every access path short-lived, scoped, and continuously re-evaluated.

Practical implication: replace persistent access paths with short-lived, task-scoped credentials and remove IAM users where they are only serving legacy convenience.

How least privilege changes in multi-account AWS environments

Least privilege in AWS is not only about smaller roles. It is about aligning identity scope with account boundaries, resource types, and operational context so that access does not expand as environments multiply. As teams add accounts, services, and automation, broad permissions often accumulate because the path of least resistance is to reuse roles or centralise too much access. That creates shadow access, where permissions exist beyond the team’s current intent or visibility. In a zero trust model, least privilege must be enforced through policy design, identity binding, and auditability, not treated as a one-time IAM cleanup.

Practical implication: review whether role sprawl, inherited access, and cross-account trust are hiding privileges that no longer match current operational need.

Where AI agents fit into AWS identity governance

The article notes that companies now have to consider securing AI agents, which can face both malware and identity attacks. That matters because an AI agent acting inside AWS is not just another workload when it can interact with tools, request access, or trigger actions that resemble operator behaviour. The governance question shifts from simple service authentication to how an entity that may act dynamically is constrained, monitored, and auditable. Even when the deployment is still early, the identity model has to anticipate non-human actors that may need narrow, revocable access without inheriting human-style standing privilege.

Practical implication: classify AI agents as governed identities with explicit scope, logging, and revocation paths instead of treating them as generic automation.

Threat narrative

Attacker objective: The attacker aims to turn durable cloud access into a reusable path for unauthorized activity across AWS resources.

1. Entry begins with long-lived credentials such as IAM users, SSH keys, or database passwords that remain usable long after issuance.
2. Escalation occurs when those credentials carry permissions broader than the immediate task and can be reused across accounts or environments.
3. Impact follows when persistent access enables misuse, privilege abuse, or audit gaps that a zero trust model was meant to prevent.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

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

Static credential persistence is the failure mode zero trust exposes first: zero trust in AWS cannot be real while IAM users, SSH keys, and database passwords remain standing access paths. Those credentials encode an assumption that trust can be established once and reused safely across changing environments. In cloud estates that scale dynamically, that assumption breaks faster than the control plane can recover. Practitioners should treat persistent credentials as a structural governance defect, not a configuration detail.

Least privilege becomes a runtime discipline, not a provisioning event: the article's AWS examples show why broad access is often an artifact of environment growth rather than explicit intent. When accounts, workloads, and operators multiply, static policy boundaries drift away from actual use. That makes entitlement review insufficient on its own because the problem is not just excessive privilege, but privilege that remains available between changes. Practitioners need to govern the lifetime of access, not merely its initial scope.

Trusted identity must now cover humans, workloads, and AI agents under one governance model: the article explicitly extends zero trust thinking to machine access and AI agents, which is where identity programmes start to converge. Human authentication, workload identity, and agent governance are no longer separate conversations when all three can touch the same cloud resources. The practical implication is that access policy, audit, and revocation logic must work across actor types without assuming a human operator is always in the loop.

Shadow access is the hidden cost of modern AWS convenience: when teams prioritise frictionless developer access, they often accept broader permissions and longer-lived credentials than the environment can safely tolerate. Over time, that creates access paths that are difficult to inventory, harder to certify, and easier to forget. This is why zero trust discussions in cloud programmes should be evaluated as identity governance issues, not just network architecture decisions. Practitioners should map where convenience has become standing privilege.

Ephemeral access should be the default control objective for cloud identity: short-lived credentials, session logging, and tightly bound roles are the practical counterweight to AWS sprawl. The article's framing shows that audit readiness and operational usability do not have to be in conflict if access is issued for a narrow purpose and removed automatically. The important shift is organisational: teams should measure how much of their cloud access still depends on persistence rather than necessity.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Static credential persistence: zero trust programmes fail fastest when cloud access still depends on credentials that outlive the session. The governance implication is that lifecycle and revocation now matter as much as authentication strength, because standing access creates trust debt that accumulates across AWS accounts and automation paths.

AWS zero trust work also exposes a programme design issue: access review controls cannot compensate for credentials that are issued once and reused indefinitely. When the control objective is ephemeral access, security teams need issuance-time governance, not just periodic certification, and that is where many cloud IAM programmes still lag.

NIST SP 800-207 Zero Trust Architecture remains the right reference point for this shift because the article is really about continuous verification in cloud identity, not perimeter segmentation. Practitioners should use it to test whether AWS access still depends on implicit trust anywhere in the chain.

For practitioners

• Eliminate standing IAM users Migrate human and machine access away from long-lived IAM users, SSH keys, and database passwords where a short-lived session model is possible. Focus first on the credentials that are reused across multiple AWS accounts or automation paths.
• Bind access to roles and resources Use fine-grained RBAC that ties permissions to identity, role, and resource type instead of broad account-level access. Recheck cross-account assumptions wherever teams have normalised reuse of the same role across environments.
• Audit for shadow access paths Inventory where access still persists after the original operational need has ended, especially in containers, serverless workloads, and distributed engineering environments. Treat orphaned permissions and inherited trust as zero trust failures, not housekeeping issues.
• Apply governed access to AI agents Define explicit scope, logging, and revocation for AI agents that can touch AWS resources or toolchains. Do not let agent access inherit human-style standing privilege by default, even if the workflow feels automated.

Key takeaways

• Zero trust in AWS fails when long-lived credentials, broad roles, and reused access paths still define how teams work.
• The article ties that failure to modern cloud sprawl, containers, and emerging AI agent access patterns, not to AWS alone.
• The practical answer is to move governance toward short-lived access, tighter RBAC, and explicit revocation for every identity type.

Key terms

• Static Credential: A static credential is a long-lived secret such as an API key, password, token, or certificate that exists outside the moment of use. It creates persistent attack surface because it can be copied, stored, reused, and exposed across code, pipelines, configuration files, and third-party environments.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• 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.

What's in the full article

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

• Live webinar recap with AWS and Teleport speakers on applying zero trust in modern AWS environments
• Demo coverage of passwordless authentication, session recording, and audit logging across multiple AWS accounts
• Examples of how AWS CLI and console access can be secured without changing developer workflows
• Discussion of how Teleport positions identity, policy governance, and short-lived certificates in cloud access control

👉 Teleport's full post covers the webinar demo, AWS access model changes, and compliance logging 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.