API-based JIT access changes the proxy model for cloud permissions

At a glance

What this is: This article compares API-based JIT access with proxy-based gateways and finds that direct API integration better fits cloud-native, ephemeral environments.

Why it matters: It matters because IAM, PAM, and NHI teams need access controls that follow changing resources and short-lived credentials without reintroducing standing privilege or operational drag.

By the numbers:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• Only 5.7% of organisations have full visibility into their service accounts.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Apono's comparison of API-based JIT access and proxy gateways

Context

API-based JIT access is a way to grant permissions directly through cloud provider APIs for a limited time and on a limited scope. The article argues that this model fits modern cloud infrastructure better than proxy-based gateways, because cloud resources are ephemeral, distributed, and changing faster than static roles can keep up.

For IAM and PAM programmes, the real question is whether access control can stay aligned to the resource, the task, and the approval context without creating new standing privilege. The comparison also matters for NHI governance, because many cloud workloads and automation paths depend on short-lived credentials that proxies do not always handle cleanly.

Proxy-based control was built for slower, more centralized environments. API-driven JIT reflects the reality of multi-cloud operations, but it also raises the bar for governance, visibility, and policy quality rather than removing those requirements.

Key questions

Q: How should security teams compare API-based JIT access with proxy-based access control?

A: Security teams should compare them by control point, not by convenience. API-based JIT governs access at the cloud resource or service API, which usually supports narrower scope and cleaner lifecycle handling. Proxy-based access can centralise sessions, but it often adds routing overhead and hides the effective identity behind the gateway.

Q: When does proxy-based access create more risk than it reduces?

A: Proxy-based access creates more risk when it becomes the enforcement layer for environments that are already dynamic, multi-cloud, and ephemeral. In those settings, the proxy can widen the blast radius, obscure audit trails, and force broad roles that outlive the task. That is especially problematic for cloud operations and NHI workflows.

Q: What breaks when JIT access is bolted onto static roles?

A: Least-privilege design breaks down when JIT is layered on top of static roles because the role itself still carries excess scope. The result is temporary access to a permanently broad entitlement. That defeats the point of just-in-time governance and leaves too much room for overexposure, especially in cloud and machine identity use cases.

Q: Who should own JIT governance across cloud and workload identities?

A: Ownership should sit with IAM or identity architecture, with PAM, cloud platform, and workload identity teams contributing policy and lifecycle rules. If the control spans people and machine identities, ownership must include both approval logic and entitlement hygiene. That keeps the programme aligned to access scope, auditability, and offboarding.

Technical breakdown

Why proxy-based JIT adds control friction

Proxy-based access control inserts an intermediary layer between the user and the target resource. That layer can centralize sessions, but it also creates traffic rerouting, extra infrastructure to maintain, and an abstraction that often obscures the real identity behind the request. In cloud-native environments, that abstraction becomes costly because the resource model is already distributed across services, accounts, and regions. When the proxy becomes the enforcement point, policy often shifts from resource-specific permissions to coarse session handling, which limits least-privilege precision.

Practical implication: if your access model depends on proxies, test whether they preserve resource-level identity and auditability, not just connectivity.

How API-based JIT enforces resource-level least privilege

API-based JIT connects directly to the cloud or SaaS control plane, so access can be created, scoped, and removed at the resource layer. That allows policy to evaluate context such as ticket justification, on-call status, or target system, then issue an ephemeral role instead of reusing a broad static entitlement. This is more than convenience. It changes the control point from network routing to authorisation, which is where modern identity governance needs to operate for ephemeral infrastructure and distributed engineering workflows.

Practical implication: map JIT rules to the native control plane so access expires with the task rather than persisting as reusable role baggage.

Why cloud-native integrations matter for NHI and human workflows

Modern environments are not limited to SSH sessions. They include Kubernetes, managed databases, serverless functions, and SaaS platforms, each with its own identity semantics. API-based approaches can integrate with those native systems and with collaboration tools such as Slack, Teams, Jira, or PagerDuty, so approval and request flows stay close to work. That matters because identity controls that sit outside the operational path often get bypassed or duplicated, especially when engineers need short-lived access under time pressure.

Practical implication: validate whether your JIT design covers the full cloud stack, including machine identities and approvals embedded in team workflows.

Threat narrative

Attacker objective: The objective is to obtain broader effective access than the task justified, then use that access to reach resources or data that should have remained out of scope.

1. Entry occurs when a user or workload obtains access through a control path that is too coarse for the target cloud resource, such as a reused role or an over-broad session boundary.
2. Escalation happens when proxy mediation hides the effective identity or forces broader account-level permissions, allowing the session to behave with more privilege than the task requires.
3. Impact follows when standing or over-scoped access increases exposure across ephemeral resources, making misuse, lateral movement, or audit blind spots easier to exploit.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

API-based JIT is not just a deployment preference, it is an identity model choice. Proxy gateways treat access as a routed session problem, while API-based JIT treats it as a control-plane authorisation problem. That matters because modern cloud environments are defined by ephemeral resources and changing entitlements, not by fixed network borders. Practitioners should recognise that the control model must move with the resource model.

Identity blast radius: the effective scope of access should shrink to the task, resource, and approval context, not the account or session. Proxy-based access often preserves a larger blast radius because it binds the user to a mediated session rather than to a narrowly defined cloud entitlement. Resource-level JIT reduces that exposure by creating permission only when needed and removing it when the task ends. The implication is that governance needs to measure how much access can exist at once, not just whether access was requested properly.

Proxy control was designed for environments where the target identity is stable long enough to be mediated centrally. That assumption weakens in cloud-native operations where short-lived resources, distributed teams, and automation paths change faster than proxy workflows can adapt. The issue is not that proxies are unsafe by default, but that they encode an older governance premise. Practitioners should treat them as legacy fit-for-purpose controls, not as a universal access architecture.

API-driven JIT also reshapes how NHI governance and human access governance intersect. Cloud permissions increasingly have to serve both people and workloads, especially in CI/CD, serverless, and Kubernetes workflows. When the same control plane must handle human requests and machine entitlements, the strongest model is the one that keeps scope, duration, and audit trail tied to the native identity object. Security teams should stop separating these programmes too early in design.

The market signal is clear: access governance is moving from network mediation toward contextual authorisation at the cloud control plane. That does not eliminate the need for policy discipline, inventory, or offboarding. It does mean identity teams must think in terms of entitlement precision, workflow integration, and ephemeral access life cycle rather than gateway placement. Practitioners who ignore that shift will keep adding control layers instead of reducing risk.

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.
• Another finding from the Ultimate Guide to NHIs shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• For a broader lifecycle view, the NHI Lifecycle Management Guide helps teams connect access creation, rotation, and offboarding to the same governance model.

What this signals

Identity control is moving toward the cloud control plane, and that change should reshape JIT programmes now. If the permission can be created at the resource itself, then access governance no longer depends on a separate mediation layer to stay precise. Teams should expect tighter coupling between IAM, cloud platform engineering, and workflow tooling, especially where ephemeral infrastructure is the default.

With 70% of organisations already granting AI systems more access than human employees performing the exact same job, per the 2026 Infrastructure Identity Survey, access governance is already being stretched beyond human-centric assumptions. That pressure will push more programmes to treat machine and human access through the same precision lens, not separate control philosophies.

Identity blast radius will become a practical design metric, not just a conceptual one. The programmes that survive cloud scale will be the ones that can prove how much access existed, for how long, and at what scope, across both human and non-human identities.

For practitioners

• Map access decisions to the native control plane Require JIT tooling to create and revoke permissions through AWS, Azure, GCP, Kubernetes, or SaaS APIs instead of only routing sessions through intermediaries. That preserves resource-level scoping and avoids proxy-induced role bloat.
• Measure identity blast radius before and after JIT changes Compare how much access a user or workload can exercise under proxy mediation versus API-issued ephemeral permissions, then track whether the model reduces standing privilege and over-scoped entitlements.
• Review workflow coverage for human and machine access Check whether your approval path supports on-call engineers, service accounts, CI jobs, and ephemeral cloud resources without forcing them into the same coarse session pattern. Use the NHI Lifecycle Management Guide for lifecycle-specific governance.
• Validate auditability of the real identity behind the request Ensure session logs and entitlement records preserve the actual requesting person or workload, not only the proxy account used to reach the resource. The Ultimate Guide to NHIs is useful for reviewing visibility and offboarding gaps.

Key takeaways

• API-based JIT access shifts governance from session mediation to resource-level authorisation, which better matches cloud-native operations.
• Proxy-based models can still centralise control, but they often carry a larger identity blast radius and more audit ambiguity.
• IAM teams should judge JIT architectures by scope precision, lifecycle handling, and support for both human and machine identities.

Key terms

• Just-in-time access: Just-in-time access grants permissions only when they are needed and removes them when the task is complete. In cloud and machine identity programmes, the goal is to minimise standing privilege while keeping approvals, scope, and duration tied to a specific resource or activity.
• Proxy-based access control: Proxy-based access control routes user traffic through an intermediary layer that mediates the session before it reaches the target system. It can centralise enforcement, but it often adds operational overhead and can obscure the real identity and exact resource scope behind the proxy account.
• Identity blast radius: Identity blast radius is the amount of access an identity can effectively exercise before it is constrained, reviewed, or revoked. In JIT design, a smaller blast radius means narrower scope, shorter duration, and less opportunity for overexposure across cloud, workload, and human access paths.
• Cloud control plane: The cloud control plane is the API layer used to create, modify, and revoke resources and permissions in a cloud environment. For identity governance, it is the most precise place to enforce temporary access because it acts on the resource directly rather than on a routed session.

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.

This post draws on content published by Apono: API-based JIT Access vs Proxies: Streamlining Secure Cloud Permissions. Read the original.