A service account you created for an agent in Okta last quarter still resolves to the same group memberships and app assignments today, and the agent still uses that identity to reach production systems on every run. Nobody widened it. Nobody needed to. The non-human identity behind that agent was over-scoped on day one, and the agent reaches infrastructure in a loop without anything checking whether the access is still appropriate for the task in front of it.
That is the failure mode this post starts with, because configuring AI agents access to Okta with non-human identity goes wrong in the same three ways every time. Okta issues the identity. The risk is the standing access that identity quietly carries across your infrastructure. Name the failures first, then fix the architecture underneath them.
Where non-human identity for agents breaks
Okta models a non-human identity as a service app, an OAuth 2.0 client doing the client-credentials flow, or an API token. Each is a legitimate way to give software an identity. The trouble is not the Okta identity itself, it is what that identity grants downstream when an autonomous agent carries it.
- The access is standing. The agent's identity maps to broad reach into databases, clusters, and internal services, and that reach does not end on task completion. It stays live until someone manually trims a group or an assignment.
- The scope is coarse. Teams put the agent in an existing group because trimming membership per task is tedious. The non-human identity then resolves to access across many systems for a job that touched one.
- The agent controls its own credential. If the agent holds the client secret or token that proves its Okta identity, a prompt-injected or confused agent can present it anywhere, and it can hand it to the next call in its chain.
The common thread is that the identity out-scopes and outlives the task, and nothing between the agent and the infrastructure re-checks it.
What a correct non-human identity setup requires
The fix is not a smaller group on the same identity. The architectural requirement is that the agent's Okta identity is verified at a boundary in front of the infrastructure, so access is issued per session, scoped to the task, and recorded outside the agent's process. Okta stays the identity provider. What changes is that the Okta identity no longer translates directly into standing access to systems.
hoop.dev is built to that requirement. It sits in front of your infrastructure, databases, Kubernetes, SSH, and internal services, as a Layer 7 access gateway, and it is the OIDC/SAML relying party for your Okta org. The agent presents its Okta identity, hoop.dev verifies the token and reads group membership, and grants a scoped, time-bound connection to the specific system the task needs. Okta still authenticates the non-human identity. hoop.dev decides what that identity may reach and for how long. You can read the model in the getting-started docs, and go deeper on scoped, per-session access on the learn pages.
Configuring it step by step
- In Okta, create the service app or OAuth client that represents the agent's work, and put it in a group that maps to the least access the real tasks need. Resist reusing a broad existing group.
- Put hoop.dev in front of the infrastructure the agent reaches, and configure it as the OIDC/SAML relying party for your Okta org so it can verify the agent's Okta identity on every connection.
- Map the Okta group to a hoop.dev policy that grants only the specific connections the agent's tasks require, not blanket access to everything behind the gateway.
- Write the policy so each grant is time-bound, with an expiry in minutes, and scoped to the operation, for example read one database rather than every database.
- Route the agent's connections to infrastructure through hoop.dev and close direct network paths so the gateway is the only way in.
Verify the boundary holds
Confirm two things. First, that the Okta identity on its own does not open a standing door: presented straight to a system without going through the gateway, it should reach nothing. Second, that a grant expires on its own. Start a task, let it finish, and confirm a follow-up connection after the time-to-live is rejected without a fresh grant. If a stale session still works, the access is standing and the non-human identity is back to where you started.
Pitfalls
- Rotating instead of removing. Rotating the credential that proves the agent's identity shrinks one window but keeps the standing infrastructure access behind it. Scoped, per-session access through the gateway removes that access.
- Scoping the human, not the machine. A non-human identity needs its own group and scope tied to its tasks, not a copy of an engineer's access.
- Logging at the agent. If the only record of what the agent did lives in the agent, a compromised agent can rewrite it. The record has to sit at the boundary. hoop.dev records each session so the audit trail is outside the agent's reach.
FAQ
Does this replace Okta as the identity provider?
No. Okta stays the source of identity for the non-human identity. hoop.dev is the relying party that verifies the Okta token and turns it into scoped, time-bound access to infrastructure, rather than standing access.
Can the agent still reach the systems it needs?
Yes, when a task needs it and a policy allows it, for the life of a scoped session. The difference is the access is per-session and recorded, instead of living permanently behind the agent's identity.
hoop.dev is open source. To see how the gateway verifies an Okta identity and scopes a non-human identity's access to infrastructure, start with the repository on GitHub.
