Standing access is the default state of most agent setups, and it is the one to design out first. An agent whose Okta identity maps to a permanent grant into your systems holds that reach whether a task needs it or not, which means the worst day is whatever day the agent is wrong. Just-in-time access flips that: the grant exists only while a task runs, then it is gone.
This is a step-by-step guide to configuring just-in-time access for an agent whose identity is governed by Okta. Okta says who the agent is; the gateway in front of your infrastructure decides, per task, what that identity may reach. The setup is concrete and you can follow it in order.
What just-in-time access means for an agent
Just-in-time access means the agent has no entitlement to infrastructure at rest. When a task needs to act against a system, the agent presents its Okta identity, a policy decides, a scoped and short-lived connection is granted, and that grant expires on its own. The agent never accumulates reach between tasks. The difference from a rotated credential is that rotation shortens one window while just-in-time access removes the standing window entirely.
Step by step
- Inventory what the agent actually does against your systems. List the real operations: read a database, exec into a pod, call an internal API. These become the scopes a grant can carry. Anything not on the list should never be grantable.
- Put hoop.dev in front of those systems. Configure it as the OIDC/SAML relying party for your Okta org so it verifies the agent's Okta identity on every request. The agent's destination is the infrastructure, reached through the gateway, never Okta's admin API.
- Write policy against the agent's Okta identity. The agent authenticates through Okta and hoop.dev reads the identity and group membership. That identity is what policy is written against, so there is no separate credential for the agent to hoard.
- Write the just-in-time access policy. Map the agent's Okta group to specific connections, set a short time-to-live measured in minutes, and limit the scope to the operation the task requires. Add an approval step for higher-risk scopes if a human should be in the loop.
- Route all agent traffic to infrastructure through hoop.dev. Close direct paths so the only way the agent reaches a system is by requesting a grant first.
- Record each grant. Every request, approval, and expiry is logged at the gateway, outside the agent, so the trail survives even if the agent is compromised.
The reason the grant has to be issued by something the agent cannot reconfigure is the whole point. If the agent mints its own just-in-time access, it can also extend it, and you are back to standing access wearing a timer. The issuing and recording layer has to sit outside the agent process. hoop.dev is built to that model as a Layer 7 access gateway in front of your infrastructure, consuming Okta as the identity provider. The getting-started docs show the connection and policy setup, and there is more on the access model in the learn pages.