Just-in-time access for AWS: what changes for NHI governance

At a glance

What this is: This is Teleport’s analysis of just-in-time access for AWS, showing how ephemeral privileges and unified audit logging can reduce standing privilege, audit gaps, and governance drift across humans, pipelines, and AI agents.

Why it matters: IAM, PAM, and NHI teams need to treat AWS access as a temporary governance event because long-lived permissions create audit blind spots, overprovisioning risk, and inconsistent control across mixed actor types.

👉 Read Teleport's analysis of just-in-time access for AWS governance

Context

AWS access control is not only a permissions problem. In fast-moving environments, the harder issue is whether identity governance can keep pace when humans, CI/CD pipelines, and AI agents all request access through the same cloud primitives.

Just-in-time access changes the governance model by issuing short-lived, task-scoped credentials instead of persistent access. For IAM and NHI programmes, that shifts control from pre-provisioning and recertification toward issuance time, expiry, and unified attribution.

The article frames AWS as a case for consistent least privilege across multiple actor types. That is a typical problem in modern cloud estates, where the governance gap is usually not the access primitive itself but the operational drift around it.

Key questions

Q: What breaks when AWS access is still based on standing privileges?

A: Standing privileges create a governance gap because access can outlive the task, the approval, and sometimes the operator. That makes overprovisioning, audit blind spots, and hidden reuse far more likely. In AWS, the failure is not only excess access. It is the absence of a reliable expiry boundary that forces privileges to disappear when the work is done.

Q: Should organisations prioritise just-in-time access over broad access reviews?

A: Yes, when the objective is to reduce active exposure rather than just document it. Access reviews tell you what exists, but just-in-time access changes how long privilege exists in the first place. For high-risk permissions, reducing standing access usually delivers faster risk reduction than another review cycle.

Q: What are the signs that AWS security controls are failing in practice?

A: Common warning signs include public-read S3 access, Security Groups open to 0.0.0.0/0, CloudTrail not enabled across all regions, unencrypted EBS or RDS resources, and Lambda functions granted AdministratorAccess. If these patterns appear in templates or deployed accounts, the control environment is not enforcing least privilege or baseline hardening consistently.

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

Ephemeral privileges in AWS access

Just-in-time access replaces standing entitlements with short-lived credentials that are issued only when a request is approved. In AWS, that usually means role assumption, federated identity, or temporary certificates tied to a task and a time-to-live. The control objective is not faster access for its own sake. It is to collapse the window in which privilege exists, so the identity is only empowered for the job it was approved to do. That design matters because static keys, persistent roles, and reused sessions are hard to govern consistently across large cloud estates.

Practical implication: move sensitive AWS access from durable entitlements to time-bound issuance rules with clear expiry and approval boundaries.

Unified audit trails across humans, pipelines, and AI agents

A JIT model only becomes governable when every session is tied back to the identity, request, and policy that created it. That is especially important in AWS, where console actions, API calls, EC2 sessions, and pipeline jobs can otherwise fragment across different logs. A unified audit trail does more than support forensics. It creates a consistent accountability layer across actor types, including AI agents that act through Bedrock or other workflow hooks. Without that correlation, access may be temporary but governance remains incomplete.

Practical implication: require one correlated audit record for each temporary AWS session, regardless of whether the actor is human, machine, or AI.

Why AWS-native primitives do not solve governance drift on their own

AWS provides access building blocks such as STS AssumeRole, OIDC federation, IAM Authenticator, and Identity Center. Those primitives are necessary, but they do not automatically solve the operational problem of consistent governance at scale. The article’s core point is that teams still need policy logic for approvals, TTLs, and revocation across EKS, EC2, console use, CI/CD, and Bedrock-triggered workflows. Without that orchestration layer, access can remain technically valid even when it is no longer operationally justified.

Practical implication: review whether your AWS access architecture has policy enforcement around the primitives, not just the primitives themselves.

Threat narrative

Attacker objective: The objective is to turn persistent AWS access into an ungoverned execution path that supports unauthorized cloud actions while avoiding clear attribution.

1. Entry occurs when an attacker or over-privileged actor gains access through static IAM keys, long-lived roles, or copied kubeconfigs that were never meant to persist beyond a task.
2. Credential abuse follows when those persistent credentials or sessions are reused outside their intended window, allowing access to EKS, EC2, the AWS Console, or pipeline environments.
3. Impact emerges as overprovisioned access expands the blast radius, enabling unauthorized changes, hidden console activity, or compromised automation that is difficult to attribute and revoke.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.
• Amazon AWS Hacked Accounts Crypto-Mining: Compromised IAM credentials across multiple AWS accounts fuel large-scale crypto-mining campaign.

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

Just-in-time access is really a governance model for ephemeral privilege, not an access-speed feature. The article is strongest when it shows that AWS velocity creates more governance pressure, not less, because permissions must now be issued, bounded, and attributed in near real time. That makes expiry and request context the control plane, not a secondary detail. Practitioners should treat JIT as a lifecycle discipline for temporary privilege.

The assumption that access can be reviewed after it is granted breaks down when sessions are intentionally short-lived. Access review processes were designed for privileges that persist long enough to be observed and certified. When access is task-scoped to minutes or a single job, the governing control moves to issuance time and the review cycle becomes an after-the-fact record, not the decision point. The implication is that recertification alone cannot govern ephemeral AWS access.

Consistent least privilege across humans, CI/CD, and AI agents is becoming the minimum viable control for cloud governance. The article correctly collapses the artificial boundary between operator types because AWS risk now spans interactive users, pipelines, and AI-driven workflows. That means governance programmes built around one actor class will miss the others, especially where the same role can be exercised by a person, a job, or an agent. Practitioners should design controls that survive actor mix, not assume one identity model fits all.

Shadow access paths are the real control failure in AWS estates. Static keys, shared kubeconfigs, and broad console sessions create access routes that remain available long after the business justification has expired. Those routes are not just inconvenient. They are the conditions under which overprovisioning becomes invisible and audit evidence becomes fragmented. Practitioners should focus on removing persistent paths that bypass policy-bound issuance.

Unified attribution is now a control requirement, not a reporting convenience. In mixed AWS environments, the difference between a governed session and a blind spot is whether each action can be tied back to the request, actor, and time window that authorised it. That matters equally for compliance and incident response. Practitioners should make correlation across CLI, console, API, and pipeline activity part of the access design itself.

From our research library:

• 91% of organisations say at least half of their privileged access is always-on, and only 1% have fully implemented just-in-time privileged access, according to a CyberArk study.

What this signals

Ephemeral privilege only works when issuance becomes the control point. AWS teams often focus on faster access, but the actual governance gain comes from replacing standing entitlements with short-lived credentials that expire at the end of the task. That shift matters most where humans, pipelines, and AI agents all operate in the same cloud account set.

Actor consistency is becoming the defining challenge for cloud identity programmes. If the same AWS role model is applied differently to engineers, CI/CD jobs, and AI agents, governance will fragment even when the underlying platform is identical. The practical response is to standardise approval, expiry, and audit requirements across all three actor types.

For practitioners

• Enforce task-scoped AWS credentials Issue temporary access only when a request, approval, and expiry window are all present. Make the credential lifetime shorter than the task and ensure the session cannot outlive the approved use case.
• Remove persistent kubeconfig distribution Stop distributing reusable kubeconfigs for EKS access where short-lived cluster credentials can be tied to the requester and recorded centrally. This closes one of the easiest shadow access paths in AWS estates.
• Bind console access to request context Require AWS console sessions to carry an approval record, role constraint, and session duration so that console actions can be traced back to a specific request and identity.
• Treat AI agents like governed identities Apply the same issuance rules, expirations, and logging expectations to Bedrock-triggered workflows and other AI-driven access as you do to human operators and CI/CD jobs.
• Correlate AWS activity into one audit trail Merge CLI, console, API, and automation logs so security and compliance teams can reconstruct who acted, under which policy, and for how long without manual log stitching.

Key takeaways

• AWS access becomes materially easier to govern when privilege is issued for a task and expires automatically at the end of that task.
• The main risk in fast-moving AWS environments is not the presence of access primitives, but the governance drift created by persistent sessions and inconsistent attribution.
• Identity teams should design AWS controls around issuance time, expiry, and unified audit evidence so access remains temporary and explainable.

Key terms

• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.
• 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.
• 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.
• Unified audit trail: A single evidence stream that links identity proofing, authentication, consent, and executed actions across human and non-human actors. It matters because split logs prevent teams from reconstructing what the agent was allowed to do and what it actually did.

What's in the full article

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

• Step-by-step JIT implementation examples for EKS, EC2, the AWS Console, CI/CD, and Bedrock workflows
• Specific session patterns such as short-lived certificates, TTL settings, and approval-linked access windows
• Details on how Teleport correlates CLI, API, console, and pipeline activity into one audit trail
• Practical examples of how temporary AWS access is bound to roles, requests, and expiration events

👉 The full Teleport blog post covers EKS, EC2, console, CI/CD, and Bedrock access patterns in 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.