How can you give developers just-in-time access, temporary precise permissions, when they run code on shared servers?
Most organizations still let engineers log into a build box or CI runner with a long‑lived SSH key or a static service account. The key is copied to the host, stored in a vault, and then reused for weeks or months. When a developer runs a script, the process inherits that credential and can reach any database, internal API, or storage bucket the key was originally granted for. There is no record of who executed which command, no way to hide passwords that appear in logs, and no checkpoint to stop a dangerous operation before it runs.
That state satisfies the immediate need to get code running, but it creates a blind spot for security teams. A compromised key can be used to pivot across services, and auditors have no evidence of the exact commands that were issued. The blast radius of a single breach can expand dramatically because the same credential is trusted everywhere.
Why just-in-time access matters for code execution
Just-in-time access means granting a permission only for the moment it is needed, and revoking it automatically afterward. In a code‑execution context, the developer asks for a specific capability, read a secret, write to a table, or deploy a container, and receives a short‑lived token that expires as soon as the job finishes. This limits the window an attacker can abuse a credential and reduces the risk of lateral movement.
Beyond limiting time, just-in-time access also scopes the permission to the exact resource and operation. Instead of a blanket "read‑all‑databases" role, the request might be "read the customers table for the reporting job". The tighter the scope, the smaller the impact of a mistake.
The missing control: a data‑path gateway
Even with identity providers that can issue short‑lived tokens, the request still travels directly from the runner to the target service. That direct path gives the runner full control over the network connection, meaning it can bypass any policy checks, hide commands, or replay traffic. Without an enforcement point that sits between the identity and the resource, you cannot guarantee that every request is evaluated, recorded, or masked.
What you need is a Layer 7 gateway that intercepts the protocol, evaluates the request against policy, and only then forwards it. The gateway must be able to:
- Validate the just-in-time token against the identity provider.
- Enforce fine‑grained rules before the command reaches the service.
- Record the full session for later replay.
- Mask sensitive fields in responses so they never appear in logs.
Only a gateway placed in the data path can provide these guarantees.