Most breaches that involve an AI agent do not start with a clever exploit. They start with a non-human identity that outlived its purpose: an app registration created for a one-week project, still active two quarters later, still holding the database secret it was given on day one. Nobody owns it, nobody rotates it, and it is exactly the kind of identity an attacker loves.
This post is about governing non-human identity for AI agents whose identity is issued by Microsoft Entra, with access to infrastructure enforced by hoop.dev. The roles matter, so state them plainly. Entra is the identity provider. It owns the agent's identity, its lifecycle, and its group membership. hoop.dev is the relying party that verifies the Entra-issued token and uses it to authorize a connection to a database, cluster, or service. hoop.dev consumes the Entra identity. It does not manage your Entra directory and does not proxy Entra's admin surface.
The non-human identity lifecycle problem
A human identity has a natural end: someone leaves, HR triggers an offboard, access is pulled. A non-human identity has no such signal. It persists until a human notices it. The way to make non-human identity safe is to bind every grant to the live Entra identity and to hold no separate credential anywhere else. When the Entra identity is disabled, access stops, because the only path to infrastructure ran through the identity Entra just turned off.
The architectural requirement: the agent must not carry its own database credential. If it does, disabling the Entra identity changes nothing, because the agent still holds a key. The credential has to sit on the gateway connection, so identity and access share a single point of control.
Mapping an agent identity to access
Take an agent that syncs records into an internal API.
- In Entra, register the agent as an application and place it in a group such as
sync-agents. - Configure hoop.dev to verify Entra tokens against your tenant.
- Create the hoop.dev connection to the internal API with the credential on the connection.
- Bind the
sync-agents group to that connection with the minimum scope the job needs and recording on.
identity-map:
entra-group: sync-agents
connection: records-api
scope: write:records
record: true
Verify the binding
Disable the agent's identity in Entra, then have it try to connect. The attempt should fail at the gateway, immediately, because the token no longer verifies. Re-enable it and confirm access returns. That round trip proves the non-human identity is the single lever for the agent's infrastructure access, which is what you want.
Pitfalls
- Do not issue the agent a standalone secret as a convenience. That breaks the single point of control.
- Do not reuse one Entra identity across many agents. You lose the ability to attribute actions to a specific agent.
- Do not leave the group scope wider than the task. Scope the connection to the operations the agent truly performs.
One agent, one identity, one scope
The cleanest pattern is one Entra app registration per agent, one group per task, and one scoped connection per group. It is more setup than dropping every agent into a shared identity, and it pays for itself the first time you need to answer what a single agent could reach. Shared identities collapse that answer into a guess.
It also makes revocation precise. When you retire one agent, you disable one Entra identity, and exactly that agent's access to infrastructure stops. Nothing else moves. The other agents keep running on their own identities and their own scoped connections. That precision is the practical payoff of treating a non-human identity as a first-class thing rather than a shared secret.
hoop.dev is open source and MIT licensed, so you can audit exactly how the Entra identity drives authorization rather than trusting a closed system. See the getting started guide for connecting an identity provider and the learn material on non-human identity for patterns specific to agents.
FAQ
Does hoop.dev create the non-human identity?
No. You create and manage it in Entra. hoop.dev verifies the Entra token and authorizes the infrastructure connection from it.
What happens when I disable the identity in Entra?
The agent's next connection fails at the gateway, because the token no longer verifies and the agent holds no separate credential.
How do I begin?
Clone the hoop.dev GitHub repository, connect Entra as your provider, and map one agent group to one scoped connection.
