TL;DR: AWS access should be temporary, task-scoped, and fully auditable across humans, CI/CD, and AI agents, using short-lived certificates, TTLs, and unified logs to reduce standing privilege and governance drift, according to Teleport. The bigger issue is not access speed but whether identity programmes can govern ephemeral privilege consistently across every actor type.
NHIMG editorial — based on content published by Teleport: 5 Ways to Keep AWS Fast with Just-in-Time Access
By the numbers:
- 17 minutes, redentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: How should security teams implement just-in-time access for AWS workloads?
A: Start by classifying every privileged AWS path, including console, CLI, pipeline, and agent-triggered access, then issue temporary credentials only for an approved task window.
Q: Why do long-lived AWS credentials create more risk than task-scoped access?
A: Long-lived credentials expand the time available for misuse, copying, and lateral movement, especially when they exist in laptops, pipelines, or shared systems.
Q: What breaks when AWS access logs are split across multiple systems?
A: When console, CLI, and automation logs are disconnected, teams lose the ability to prove who performed a privileged action and under what approval.
Practitioner guidance
- Map every privileged AWS path to a request and expiry policy Document how console, CLI, EC2, EKS, pipeline, and agent access is issued, approved, time-limited, and revoked.
- Eliminate reusable credentials from automation and agent workflows Replace stored AWS keys in pipelines and AI-triggered workflows with ephemeral credentials bound to the exact job or task.
- Tie privileged actions to a single audit record Require one traceable identity record for every elevated action, including who requested it, what policy allowed it, when it expired, and which commands ran.
What's in the full article
Teleport's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples for EKS, EC2, console, CI/CD, and Bedrock agent access patterns.
- Details on how short-lived certificates and TTL policies are applied in practice across AWS sessions.
- Guidance on how unified audit logs are correlated with CloudTrail and SIEM output.
- Examples of how approval workflows are wired into request-driven access paths.
👉 Read Teleport's analysis of just-in-time AWS access for humans, pipelines, and AI agents →
AWS just-in-time access and AI agents: are your controls ready?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
Standing AWS privilege is the real liability, not AWS speed. The article correctly frames velocity as the operational pressure, but the deeper issue is that persistent access assumes humans and workloads will remain slow enough for governance to catch up. That assumption fails when engineers, pipelines, and agents all need access on demand. Practitioners should treat standing access as the exception path, not the default state.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to the same report.
A question worth separating out:
Q: Should organisations treat AI agent access to AWS differently from CI/CD access?
A: Yes. CI/CD access is usually job-bound and repeatable, while AI agent access can be more context-sensitive and less deterministic at runtime. Both should be ephemeral, but agent sessions need tighter scoping, explicit approval boundaries, and stronger attribution because the workflow can change while it is running.
👉 Read our full editorial: Just-in-time access for AWS: what changes for NHI governance