Just-in-time access for AI agents on Okta

An agent presents an Okta token that says it belongs to the platform group, and that single fact opens every database, cluster, and host the group can reach, for as long as the token lives. That is the over-scoped default, and just-in-time access is what replaces it with a grant sized to one task. The token still proves who the agent is. It should not also decide, by itself, everything the agent may touch.

The way to get just-in-time access right here is to treat the Okta token as the input to an authorization decision, not the authorization itself, and to scope every grant down to a single connection. Okta is the identity provider. The agent authenticates against Okta, Okta issues the token, and the access gateway verifies that token and reads the group membership to decide whether one specific connection to infrastructure is allowed right now.

Configuring just-in-time access for least scope

Least scope is the whole game. A grant that maps an Okta group to broad standing reach is just-in-time in name only. Configure it the other way around, from the connection up:

1. Authenticate the agent against Okta. The agent signs in as a distinct identity, and Okta issues a token carrying that identity and its group claims. No infrastructure credential is involved at this step.
2. Verify the token at the gateway. The access gateway acts as the OIDC relying party. It validates the token's signature and issuer, then reads identity and group membership. The gateway does not call Okta's admin API or stand in front of it. It consumes the token Okta already issued.
3. Map groups to connections, not to estates. Bind an Okta group to a named connection, for example a single read replica or one Kubernetes namespace, rather than to a whole environment. The narrower the mapping, the smaller the grant a valid token can produce.
4. Issue a short-lived grant for the requested connection. When the agent asks for that connection, the gateway issues a grant scoped to it that expires in minutes. The agent never holds the database password, the SSH key, or the kubeconfig.
5. Record the request, the decision, and the expiry on the gateway side, where the agent has no write path.

The result is that an Okta token, even one with a generous group, can only ever be exchanged for the single expiring connection the policy allows. Group membership decides eligibility. The grant decides reach, and the grant is small.

Why the boundary has to sit outside the agent

The reason this needs an external layer is the same reason just-in-time access exists at all. If the agent verifies its own token and grants itself the connection, a compromised agent can widen the scope and edit the record of what it did. The token verification and the grant have to be issued by something the agent cannot reconfigure.

That is the architecture hoop.dev is built around. hoop.dev is a Layer 7 access gateway that sits between identities and infrastructure. It verifies the Okta token as the relying party, reads the group membership, and brokers one scoped, expiring connection to the database, host, or cluster the agent asked for. The agent becomes an Okta-authenticated identity, never a holder of standing infrastructure credentials. The getting-started docs cover wiring Okta as the identity provider, and the learn pages explain how groups map to scoped connections.

A worked example

An agent needs to run one read query against a reporting database. It authenticates to Okta and receives a token showing membership in analytics-agents. It asks hoop.dev for the reporting-replica connection. hoop.dev verifies the token, confirms analytics-agents is mapped to that one connection, and issues a grant good for ten minutes. The agent runs the query through the gateway, the session is recorded, and the grant expires. The agent never saw the database credential, and the same token cannot open the primary, the cluster, or a host.

Pitfalls

• Mapping a broad Okta group to broad reach. A valid token then reaches everything the group covers. Map groups to single connections instead.
• Treating the token's lifetime as the grant's lifetime. The Okta session may last hours. The connection grant should last minutes.
• Sharing one Okta identity across agents. Then the token cannot tell two agents apart, and least scope per agent becomes impossible.

FAQ

Does hoop.dev manage anything inside Okta?

No. Okta is the identity provider. hoop.dev is the relying party that verifies the token Okta issues and reads group membership to authorize a connection to infrastructure. It does not front or administer Okta.

How small should a just-in-time access grant be?

As small as the task. One connection, the least scope on it, and an expiry measured in minutes. Group membership says who is eligible, the grant says exactly what they reach this time.

hoop.dev is open source. To configure just-in-time access with Okta as the identity provider in front of your infrastructure, start from the repository on GitHub.