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

At a glance

What this is: This is an analysis of just-in-time AWS access, showing how ephemeral privileges, approvals, and audit trails reduce standing access risk across humans, pipelines, and AI agents.

Why it matters: It matters because IAM teams need one governance model that handles human access, workload credentials, and emerging AI agent sessions without relying on long-lived permissions.

By the numbers:

• 17 minutes

👉 Read Teleport's analysis of just-in-time AWS access for humans, pipelines, and AI agents

Context

AWS teams often optimise for speed first and governance second, which is why standing privileges, shared roles, and broad console sessions accumulate faster than they can be reviewed. Just-in-time access is the control pattern that narrows that gap by issuing temporary privileges only for an approved task.

The governance problem is broader than human user access. In environments that include CI/CD and AI-driven workflows, the same access model has to govern human operators, service accounts, and agent-triggered actions without creating long-lived credential debt. That is the identity problem this article is really about.

Key questions

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. Bind each request to a policy, an approver, and an expiry so access cannot be reused after the work is done. Use the same governance model across humans and non-human identities.

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. Task-scoped access reduces the window in which compromise matters and makes the resulting actions easier to attribute. The key gain is not speed, but shrinking reusable privilege.

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. That weakens incident response, audit evidence, and entitlement review. A temporary session without a correlated audit trail is still a governance gap, not a controlled access model.

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.

Technical breakdown

Ephemeral AWS credentials and TTL-bound privilege

Just-in-time access replaces persistent entitlements with time-limited credentials tied to a specific request. In AWS environments, that typically means short-lived certificates or role assumptions that expire automatically after the approved window. The mechanism matters because it collapses the useful lifetime of access to the task itself, rather than to the account or workload that requested it. That reduces the chance that an old credential remains valid after the work is done, while also making the request, approval, and use of access easier to correlate in logs.

Practical implication: measure whether privileged AWS sessions expire by design and whether expired access can still be reused from cached material.

Unified audit trail across console, CLI, and pipeline access

AWS access becomes materially harder to govern when console actions, CLI commands, and automation jobs are logged in different systems with different identity context. A unified audit trail binds each access event to the actor, request, and policy that allowed it, which is what turns temporary access into something reviewable. Without that correlation, temporary access is still temporary, but it is not fully attributable. For security teams, attribution is the difference between reducing risk and merely shrinking duration.

Practical implication: require one traceable identity record for every privileged action, regardless of whether it came from a person, job, or agent.

AI agent access and context-aware authorization

The article extends just-in-time access to AI agents that trigger AWS workflows. That is significant because an agent that can start a workflow, select actions, and consume tools needs access that is both task-bound and tightly scoped to the approved context. The control pattern here is not simply credential issuance. It is making sure the agent cannot carry broad privilege between tasks, especially when the workflow spans Bedrock, MCP, or downstream AWS resources. This keeps agent access closer to request-time authorization than to persistent machine entitlement.

Practical implication: treat agent-triggered workflows as high-risk privileged paths and bind them to explicit TTL, scope, and logging controls.

Threat narrative

Attacker objective: The objective is to obtain durable, difficult-to-audit AWS privilege that outlives the original request and can be reused across infrastructure workflows.

1. Entry occurs when static IAM keys, shared roles, or persistent agent credentials are reused across AWS workflows instead of being issued only for a single approved task.
2. Credential access expands when those credentials are copied to laptops, pipelines, or agent integrations, creating reusable privilege outside the intended session.
3. Impact follows when broad or lingering access lets an attacker or misbehaving automation move through EKS, EC2, console, or Bedrock-related resources with limited accountability.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Just-in-time access works because it converts entitlement into a bounded event. The value is not only shorter exposure, but also a cleaner governance record for approval, issuance, use, and expiry. That aligns with OWASP Non-Human Identity Top 10 concerns around over-privilege and secret persistence, and it fits Zero Trust expectations for continuous verification. Practitioners should judge JIT by whether it removes reusable privilege, not by whether it is merely time-limited.

AI agent access exposes a new identity governance boundary. The article’s agent example shows that non-human access is no longer just service accounts and CI/CD. When an agent can trigger action in AWS, the governance model has to treat it as an identity subject with task-scoped privilege and explicit accountability. The implication is that IAM programmes now need one policy model for humans, workloads, and agents, or they will create inconsistent exceptions across the stack.

Unified auditability is the control that turns access into evidence. Temporary credentials help, but without one record that links request, approval, issuance, and command execution, governance still breaks at review time. That is the named failure mode here: audit fragmentation across identity channels. Practitioners should treat disconnected logs as a governance defect, not an evidence gap to fill later.

Ephemeral credential trust debt: Short-lived access reduces duration, but every environment that still depends on manually orchestrated roles, approvals, and expirations accumulates operational debt around trust propagation. The more AWS surfaces, pipelines, and agent workflows you add, the easier it becomes for controls to diverge. Practitioners should standardise issuance and revoke paths before sprawl makes the model inconsistent.

From our research:

• 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.
• For a broader control baseline, see 52 NHI Breaches Analysis for recurring failure patterns across compromised machine identities.

What this signals

Ephemeral access is only half the job. The reader’s programme will not improve if JIT simply replaces one provisioning problem with a faster provisioning problem. The harder work is establishing one governance model for humans, pipelines, and agents so expiry, approval, and attribution do not diverge as AWS usage scales.

Audit fragmentation across identity channels is the concept most likely to surface in mature AWS environments. If console actions, pipeline jobs, and AI-triggered workflows cannot be reconciled into one evidence trail, the organisation has not actually achieved least privilege, only shorter sessions. That is where teams should focus their next control review.

With 72% of organisations reporting or suspecting a breach of non-human identities in the 2024 ESG Report: Managing Non-Human Identities, the forward signal is clear: AWS governance will increasingly be judged by how well it controls ephemeral access, not by how quickly it grants it.

For practitioners

• 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. If any path still relies on long-lived keys or broadly reusable roles, move it into the same TTL and approval model as the others.
• 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. The goal is to leave nothing persistent in variables, configs, or shared secret stores that can be replayed later.
• 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. If logs cannot correlate across AWS and your audit platform, the control is incomplete.
• Review AI-triggered AWS access as a privileged path Treat Bedrock or MCP-triggered workflows as privileged access, not ordinary automation. Scope each agent session to one task, one target resource set, and one approval boundary so the agent cannot carry over access into later actions.

Key takeaways

• AWS just-in-time access reduces risk only when privilege is truly temporary, task-scoped, and tied to one accountable identity record.
• The evidence across NHI compromise shows that standing or reusable credentials still drive a large share of real-world exposure, especially when access is spread across humans, pipelines, and agents.
• IAM teams should standardise request, approval, expiry, and audit across every AWS path before access sprawl makes governance inconsistent.

Key terms

• Just-in-time access: A temporary access model that grants privileges only for a specific task and only for the period required to complete it. In identity governance, it reduces standing privilege and limits how long compromised access can be abused. For non-human and autonomous actors, the control must also bind scope to the exact workflow.
• Ephemeral credential: A short-lived credential that expires automatically after a defined window or task completes. It is used to reduce the value of stolen access and to keep permissions aligned with current intent. For AWS and NHI governance, the credential must be tightly bound to request, scope, and identity context.
• Standing privilege: Persistent access that remains available beyond the immediate need for it. Standing privilege increases audit burden, widens misuse windows, and makes governance depend on later review rather than up-front control. In AWS environments, it is the condition that JIT access is designed to replace.
• Audit correlation: The process of linking access requests, approvals, credential issuance, and resulting activity into one traceable record. It is the difference between having logs and having evidence. For temporary AWS access, correlation is what makes the session reviewable across console, CLI, pipelines, and agents.

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.

👉 Teleport's full post covers the AWS use cases, session mechanics, and audit trail model in more operational detail.

Deepen your knowledge

AWS just-in-time access, ephemeral credentials, and audit correlation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance model for humans, pipelines, and AI agents in AWS, it is worth exploring.