Configuring AI agents access to Entra with non-human identity

An AI agent that runs a nightly reconciliation job needs to read three databases and an internal billing service. The way most teams ship that on day one is a long-lived service principal secret pasted into an environment variable, copied into a second pipeline, and forgotten. That secret is a non-human identity with no expiry, no session boundary, and no record of which query it ran at 3am. When the agent misbehaves, you cannot tell what it touched.

This guide shows how to give an AI agent access to your infrastructure where the non-human identity is governed by Microsoft Entra and every connection runs through hoop.dev. The important framing up front: Entra is the identity provider. hoop.dev is the relying party that verifies the Entra-issued token and reads group membership to decide what the agent may reach. hoop.dev does not sit in front of Entra and does not manage your Entra tenant. It governs the database, cluster, and service connections that the Entra identity is allowed to open.

What non-human identity means for an agent on Entra

A non-human identity is a service principal, managed identity, or workload identity that authenticates without a person at the keyboard. In Entra that is usually an app registration with a client credential or a workload identity federation trust. The risk is not the identity itself. The risk is that the identity carries standing access to infrastructure and authenticates with a secret that never rotates.

The architectural requirement is this: the agent should present an Entra identity to a gateway, and the gateway should be the thing that holds the connection to the database. The agent never holds the database password. The boundary that decides what the agent can run has to live outside the agent process, because an agent that holds its own credential can be prompted into using it in ways nobody approved.

How the connection is structured

hoop.dev runs a gateway and an agent that sits inside your network next to the resource. The network agent opens an outbound connection to the gateway, so nothing is exposed inbound. The credential for the target database lives on the connection inside hoop.dev, not in the AI agent. The AI agent authenticates as its Entra identity, hoop.dev verifies that token, maps the Entra group to a policy, and only then proxies the query to Postgres or the internal service.

1. Register the agent as an application in Entra and assign it to a group such as agents-reporting.
2. Configure hoop.dev to trust Entra as the OIDC provider, so tokens are verified against your tenant.
3. Create a hoop.dev connection to the target, for example a read-only Postgres role, with the database credential stored on the connection.
4. Write a policy that maps the agents-reporting group to that connection, read only, with session recording on.
5. Point the agent at the hoop.dev endpoint instead of the raw database host.

A minimal connection definition looks like this:

connection: reporting-db
  type: postgres
  host: reporting.internal
  access: group:agents-reporting
  mode: read-only
  record: true

Verify the boundary holds

Test it by having the agent run a write. The query should be refused, because the policy bound to its Entra group is read only, and the refusal should appear in the session log tied to the non-human identity. Then revoke the agent from the Entra group and confirm the next connection attempt fails at the gateway. That is the proof that authorization follows Entra group membership and that the agent never held a credential it could reuse.

Pitfalls to avoid

• Do not let the agent keep a fallback database secret. If it has one, the gateway is optional and the boundary is gone.
• Do not grant the Entra group broad access and rely on the agent to behave. Scope the connection, not the agent.
• Do not treat the Entra app secret as permanent. Rotate it, and prefer workload identity federation where it fits.

Because hoop.dev is open source and MIT licensed, you can read exactly how token verification and policy mapping work rather than trusting a black box. See how identity-aware access works in the hoop.dev docs and the guides on non-human identity patterns for deeper setup.

FAQ

Does hoop.dev manage my Entra tenant?

No. Entra issues the token and owns the identity. hoop.dev verifies that token and uses the group membership to authorize the infrastructure connection.

Where does the database credential live?

On the hoop.dev connection, injected at runtime. The agent presents its non-human identity and never sees the database password.

How do I start?

Clone the open-source gateway from the hoop.dev GitHub repository and connect your first read-only database before you wire in the agent.