Zero trust in AWS still fails where static credentials persist

At a glance

What this is: This recap argues that zero trust in AWS breaks down when teams keep relying on long-lived credentials, broad access, and fragmented controls while infrastructure and AI usage keep expanding.

Why it matters: For IAM, PAM, and NHI practitioners, the issue is that cloud access governance now has to cover humans, workloads, and AI systems without assuming any of them will stay stable long enough for legacy review cycles to work.

By the numbers:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Teleport's recap of zero trust security for AWS environments

Context

Zero trust in AWS means verifying identity, limiting privilege, and logging activity continuously instead of assuming network location or persistent trust. The problem is that modern cloud environments move faster than access models built around static users, long-lived secrets, and manual approvals, and that gap now extends to AI systems as well as human operators.

Teleport’s recap is useful because it treats AWS access as an identity governance problem, not just a tooling problem. The same operational pressure that drives teams toward faster delivery also pushes them toward broader access, more exceptions, and weaker lifecycle control across humans, workloads, and emerging AI agents.

The result is a familiar pattern for identity teams: access expands faster than governance, and auditability arrives after the fact. That is typical in cloud programmes that have modernised infrastructure faster than they have modernised identity controls.

Key questions

Q: How should security teams reduce reliance on static credentials for workloads?

A: Start by identifying which workloads can authenticate with cloud identity, Kubernetes identity, OIDC, certificates, or attestation instead of carrying reusable secrets. Then issue short-lived credentials at runtime only when access is needed. This reduces exposure, simplifies lifecycle control, and lowers the chance that leaked material can be reused across systems.

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: What do teams get wrong about RBAC in multi-account AWS setups?

A: They often treat RBAC as a one-time design choice instead of an operating discipline. In practice, roles drift as exceptions accumulate, account boundaries multiply, and teams inherit access they no longer need. Effective RBAC in AWS requires continuous governance over role scope, resource coverage, and revocation, not just policy documents.

Q: How can organisations audit access across humans, workloads, and AI systems?

A: Use shared logging and identity records that show who or what authenticated, what resources were reached, and what actions followed. That allows audit and investigation to span users, service accounts, and AI systems without separate governance models. The main test is whether the logs can support lifecycle review and containment decisions after the fact.

Technical breakdown

Why static AWS credentials break zero trust

Static credentials such as IAM users, long-lived SSH keys, and database passwords create standing trust. In zero trust terms, that means the identity remains usable well beyond the moment of need, which increases the blast radius of theft, reuse, and forgotten access paths. When infrastructure scales dynamically, the credential outlives the workload or the task it was meant to support. That is why the model fails in cloud environments: the identity is still valid even when the original business need has changed.

Practical implication: replace persistent secrets with short-lived authentication paths tied to verifiable identity and resource scope.

How RBAC and policy centralise access across multi-account AWS

Role-based access control works when roles map cleanly to job function, resource type, and risk level. In fragmented cloud estates, the challenge is not the concept of RBAC itself but the drift between intended role design and the exceptions created by real operations. Unified policy layers can reduce that drift by applying consistent rules across accounts, clusters, and service types. For identity teams, the technical issue is whether policy is enforced at the point of access or merely documented after the fact.

Practical implication: standardise access policy across AWS accounts so exceptions do not become the de facto control model.

Why session recording matters for audit and incident review

Session recording and audit logging turn access into evidence. In cloud and NHI governance, that matters because the question is not only who authenticated, but what they did once access was granted. Recording is especially important where humans, services, and AI-assisted workflows can all trigger privileged actions through different channels. Without durable logs, you cannot reconstruct whether access stayed within approved scope or crossed into misuse, misconfiguration, or hidden privilege escalation.

Practical implication: ensure access activity is recorded in a way that supports audit, forensics, and lifecycle review.

Threat narrative

Attacker objective: The objective is to turn one persistent identity foothold into broader cloud control, data access, or long-term persistence inside AWS infrastructure.

1. Entry begins when attackers or unauthorized actors exploit long-lived IAM users, SSH keys, or database passwords that remain valid far beyond the original use case.
2. Escalation occurs when broad or over-privileged access lets the actor move from a single credential to wider cloud resources, increasing the number of systems and accounts they can touch.
3. Impact follows when the actor can use that access to alter infrastructure, exfiltrate data, or persist inside environments that were assumed to be protected by zero trust controls.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 dependence is the clearest sign that zero trust has not been fully operationalised in cloud identity. Long-lived IAM users, SSH keys, and passwords create a trust model that persists after the task, after the shift, and often after the original owner no longer needs access. That is not zero trust in practice, even if the programme uses the language of zero trust. Practitioners should treat every persistent secret as unresolved standing privilege.

Least privilege in AWS is a governance problem before it is a technical one. The article’s core message is that access scope must be designed around actual resource and role boundaries, not broad organisational convenience. When engineering teams need frictionless access, exceptions become normal and policy becomes aspirational. The implication is that identity teams must own access design across accounts, workloads, and administrative paths, not merely approve requests.

Cloud access control now spans human, workload, and AI identities in the same operational plane. Teleport’s recap explicitly notes that organisations now have to consider securing AI agents as part of the cloud access problem. That broadens the identity perimeter beyond users and service accounts into systems that may act at runtime with different patterns of privilege use. Practitioners should stop treating AI access as separate from the broader NHI and IAM control model.

Short-lived certificates and passwordless access are only meaningful when they are backed by lifecycle governance. Eliminating static credentials reduces exposure, but it does not remove the need to know who or what should still have access, where that access is valid, and how it is audited. The broader lesson is that zero trust without identity lifecycle discipline becomes cosmetic. Identity teams should align authentication changes with recertification, offboarding, and audit review.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• That same survey found that only 13% of organisations feel extremely prepared for agentic AI, while 69% say identity management must fundamentally shift to address it.
• For a deeper governance view, see Ultimate Guide to NHIs , Standards for the control landscape that should frame cloud, workload, and AI identity policy.

What this signals

Static trust is becoming the weakest link in cloud identity programmes. As environments spread across accounts, clusters, and AI-assisted workflows, the legacy assumption that a credential can safely outlive a task no longer holds. Teams that still anchor access in persistent secrets will find their review processes lagging behind real operational risk, even when their controls look mature on paper.

Runtime access governance will increasingly sit at the intersection of IAM and NHI management. The practical challenge is not only authentication, but deciding which identities are allowed to exist with authority in the first place. When access is issued for systems rather than people, lifecycle management, auditability, and revocation become the controls that determine whether zero trust is real or merely branded.

For practitioners

• Eliminate standing cloud credentials Inventory IAM users, SSH keys, database passwords, and other long-lived secrets that still grant direct access to AWS resources, then prioritise those with broad reach or no recent use. Replace them with short-lived access paths tied to verified identity and task scope.
• Standardise access policy across AWS accounts Define one policy model for roles, resources, and approval boundaries across multi-account environments so teams do not create account-by-account exceptions that weaken control consistency. Use RBAC where it genuinely fits, but keep policy enforcement centralized.
• Treat session logs as governance evidence Make sure interactive and administrative access is recorded with enough detail to support audit, incident review, and privilege investigations. Logs should show who accessed what, through which identity, and what activity occurred during the session.
• Include AI systems in access reviews Add AI agents and other non-human actors to the same review cycle used for workloads and privileged users, especially where they can call cloud tools or change infrastructure. Review scope, ownership, and revocation paths as part of the identity lifecycle.

Key takeaways

• Zero trust in AWS fails when teams keep treating standing credentials as acceptable access architecture.
• The operational evidence points to a simple pattern: broader access, weaker lifecycle control, and more audit friction go hand in hand.
• Cloud IAM, NHI governance, and emerging AI access models now need one shared control plane for privilege, review, and logging.

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 Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Session Recording: Session recording is the capture of user activity during a privileged session, such as commands, queries, or administrative actions. It gives security and audit teams a verifiable record of what happened after authentication, which is essential when access itself is not enough to prove control.
• JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.

What's in the full article

Teleport's full webinar recap covers the operational detail this post intentionally leaves in the source:

• The live demo of passwordless authentication across AWS access paths and why it changes day-to-day administration.
• The step-by-step example of how session recording and audit logging are applied across access workflows.
• The mechanics of integrating just-in-time access privileges with AWS console and CLI usage.
• The practical framing for handling AI systems as part of the same cloud access problem set.

👉 The full Teleport recap covers the webinar demo, access controls, and audit details in more operational depth.

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.