Just-In-Time Access

Credentials are created, used, and destroyed within a single operational window. Unlike static API keys or long-lived tokens, JIT credentials have a Time-To-Live (TTL) measured in seconds or minutes.

• Creation: A policy engine generates a scoped credential on-demand when an agent requests access
• Usage: The agent authenticates and performs its authorized action immediately
• Destruction: The credential is automatically revoked upon expiry, task completion, or session termination
• No persistence: Credentials are never stored in environment variables, config files, or secrets managers beyond the active session

Every access request triggers a real-time authorization decision evaluated against current context. The Policy Enforcement Point (PEP) intercepts the request and queries a Policy Decision Point (PDP) before granting access.

• Context-aware: Decisions incorporate agent identity, target resource, requested action, time of day, and current threat level
• Attribute-based: Policies evaluate user attributes, resource tags, and environmental signals simultaneously
• Continuous enforcement: Authorization is not a one-time gate; it can be re-evaluated mid-session if context changes
• Integration with OPA: Open Policy Agent enables policy-as-code for consistent, auditable decisions across heterogeneous systems

JIT access enforces the principle of least privilege by granting only the minimum permissions required for a specific task. This limits the blast radius of a compromised agent.

• Resource-level granularity: Access is scoped to a specific database table, S3 bucket prefix, or API endpoint—not the entire service
• Action-level restriction: An agent authorized to read logs cannot also write to storage unless explicitly granted
• Attribute-based conditions: Policies can restrict access based on tags, IP ranges, or VPC boundaries
• Tool Access Control Lists: Integrates with Tool ACLs to define exactly which functions an agent may invoke

Every credential issuance, access attempt, and revocation event is logged with cryptographic integrity. This creates an immutable audit trail essential for compliance and incident response.

• Non-repudiation: Each request includes a unique nonce to prevent replay attacks and ensure log integrity
• Session correlation: All actions performed under a JIT credential are linked to a specific session ID for forensic reconstruction
• Compliance mapping: Audit logs map directly to SOC 2, ISO 27001, and FedRAMP access control requirements
• Anomaly detection: Unusual patterns—such as repeated access requests or off-hours activity—trigger automated alerts

JIT access systems include emergency override protocols for incident response. A break-glass procedure allows a human operator to bypass standard JIT workflows when immediate action is required.

• Dual authorization: Emergency access may require approval from a second operator
• Automatic escalation: Break-glass events trigger immediate notifications to security teams
• Post-incident review: All emergency access is subject to mandatory forensic review within 24 hours
• Dead man's switch integration: If the human operator's heartbeat signal is lost, the system can automatically revoke all emergency credentials

JIT access is the operational mechanism that enables a Zero Standing Privileges (ZSP) security posture. Agents have no permanently assigned permissions; all rights are dynamically provisioned and immediately revoked.

• No static IAM roles: Agents do not run with long-lived service accounts or role assumptions
• Just-in-time elevation: Even highly privileged operations are granted only for the duration of a single task
• Continuous deprovisioning: A background process actively scans for and revokes any lingering credentials
• Synergy with ephemeral environments: Combined with ephemeral execution contexts, ZSP ensures no residual access survives beyond the agent's lifecycle

The foundational security posture where an agent has no permanently assigned permissions. All access rights are dynamically granted, scoped to the specific task, and immediately revoked upon completion. This eliminates the attack vector of long-lived, always-on credentials that can be stolen or misused. In practice, this requires a real-time authorization engine that brokers every access request against a policy.

The practice of writing security and compliance rules in a high-level, machine-readable language (like Rego for OPA). This allows the JIT access system to make automated, deterministic authorization decisions at the exact moment an agent requests a resource. Policy-as-Code ensures that the logic for granting ephemeral credentials is version-controlled, auditable, and consistently enforced across all environments.

A general-purpose policy engine that decouples policy decision-making from the application logic of the agent. When an agent requests JIT access, the Policy Enforcement Point intercepts the call and queries OPA. OPA evaluates the request against the current Policy-as-Code rules and the real-time context (e.g., time of day, resource sensitivity) to return a simple allow or deny decision, enabling unified authorization across the entire agentic stack.

The architectural component that intercepts an agent's request to access a tool, API, or resource and enforces the authorization decision. In a JIT workflow, the PEP acts as the gatekeeper. It calls the policy engine (the Policy Decision Point), receives the verdict, and either brokers the ephemeral credential issuance or blocks the request. This is the technical handshake that makes JIT access a reality.

A unique, single-use cryptographic number incorporated into a JIT access request to ensure its freshness and prevent replay attacks. An attacker who intercepts a valid JIT request cannot simply resend it to gain access, because the authorization server will reject any request containing a previously used nonce. This is a critical component of securing the credential issuance protocol itself.

The overarching security principle that JIT access helps enforce. It dictates that an agent should be granted only the minimum set of permissions necessary to perform its designated function. JIT access adds a temporal dimension to this principle: not only are the permissions minimal in scope, but they are also minimal in duration, existing only for the seconds or minutes required to complete a single atomic task.