Who is accountable when JIT access is used across cloud services, pipelines, and admins?

Why This Matters for Security Teams

JIT access shifts accountability from permanent entitlements to runtime control, so the real question is not who can ask for access, but who owns the policy that grants, monitors, and revokes it across cloud services, CI/CD pipelines, and administrator workflows. When that ownership is unclear, teams often end up with duplicated approvals, broken audit trails, and inconsistent expiry behavior. The result is a control gap that looks temporary on paper but persists operationally.

This is especially important for NHIs because machine access is often distributed across PAM, cloud security, and platform engineering. NHIMG research shows that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM, which helps explain why JIT governance is still treated as an exception rather than a core control plane. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that credentials without clear lifecycle ownership become a repeatable exposure, not a one-time event. In practice, many security teams discover accountability gaps only after a just-in-time grant has already outlived the task it was supposed to protect.

How It Works in Practice

Accountability for JIT access should be assigned by control domain, not by who happens to click approve. The owner of the entitlement policy defines who may request access, under what conditions, and for how long. The owner of logging defines what evidence is retained, how it is correlated, and who reviews anomalies. The owner of expiry behavior ensures access is revoked automatically when the task ends or the TTL is reached. For NHIs, that usually means a shared operating model between PAM, cloud platform, and application teams, with a named control owner above them.

In practice, good JIT design uses workload identity and policy-as-code so access is issued at runtime and tied to the specific workload, request, or session. For example, an agent or pipeline job should receive short-lived credentials only after policy checks confirm the target environment, action, and risk context. That approach aligns with emerging guidance in NIST AI Risk Management Framework-style governance, even though there is no universal standard for JIT accountability across all identity types yet. The practical control stack is usually:

• Policy owner sets eligibility, conditions, and TTL.
• PAM or cloud control plane issues ephemeral access.
• Platform or pipeline owner verifies task completion and revocation.
• Security operations reviews logs, exceptions, and failed revocations.

For incident review, accountability should follow the control that failed, not the asset that was touched. If a secret remained valid after a pipeline completed, the issue sits with expiry enforcement. If approval records are missing, the issue sits with entitlement governance. If access was granted correctly but abused, the issue shifts to monitoring and anomaly detection. NHIMG’s Ultimate Guide to NHIs is useful here because it frames machine identity as a lifecycle problem rather than a static permissions problem. These controls tend to break down when a single cross-functional platform team owns the tooling but no one owns the policy exceptions or audit evidence.

Common Variations and Edge Cases

Tighter JIT controls often increase operational overhead, requiring organisations to balance faster delivery against stronger expiry discipline. That tradeoff becomes visible in environments with high deployment frequency, shared admin consoles, or many short-lived service accounts. In those settings, teams may be tempted to extend TTLs, reuse tokens, or create broad emergency roles, but that weakens accountability and blurs who is responsible when access lingers.

There is also a practical difference between humans and NHIs. A human admin can usually accept a prompt, complete the task, and log out. A CI/CD job, cloud function, or autonomous agent may chain multiple tool calls, request nested access, and continue executing after the original approval context is gone. That makes runtime accountability more important than role assignment. Best practice is evolving toward explicit ownership of policy, issuance, and revocation, but there is no universal standard for how that ownership should be split across platform, cloud, and security teams. NHIMG case material such as the CI/CD pipeline exploitation case study shows why pipeline-owned access can become a lateral movement path when expiry and audit responsibilities are unclear.

For cloud services and administrator access, the cleanest model is to name one accountable control owner, then delegate execution to operational teams. That keeps the question of “who approved it” separate from “who owns the control when it fails,” which is the distinction auditors and responders need most.

Related resources from NHI Mgmt Group

• Who is accountable when multi-cloud access reviews miss excessive permissions?
• When does JIT access create more risk than it reduces?
• How should security teams govern API keys used for generative AI access?
• What should organisations do when agents need access across APIs and cloud services?