Your human engineers each have an identity in the IdP, a lifecycle, an owner, and a clean offboarding path. Your AI agents have a password in a secret store and a vague sense that "the platform team owns it." That asymmetry is the whole problem. Non-human identity for AI agents on Postgres is about giving agents the same first-class treatment as people: a named principal, scoped access, and a record of what it did.
This post defines non-human identity for agents on Postgres and shows where hoop.dev anchors it.
Agents are identities, and they are multiplying
An organization that ran a handful of service accounts now runs dozens of agents, each able to reach data. If they all authenticate as anonymous shared credentials, identity sprawl turns into an unaccountable mass. Non-human identity treats each agent as a principal you can name, scope, audit, and retire.
What non-human identity means for Postgres
It means the agent reaching Postgres is a distinct identity, not a shared role. Its access is scoped to what its job needs. Its actions are attributed to it specifically. And it can be revoked without disturbing any other agent, because it was never sharing a credential to begin with.
The identity lifecycle
- Create the identity in your identity provider as a non-human principal for a specific agent role.
- Scope it to the Postgres connections and operations the role requires, nothing more.
- Attribute its activity, so every statement traces back to this principal.
- Rotate and revoke it independently when the agent changes or is retired.
Where hoop.dev anchors the identity
hoop.dev is an open-source Layer 7 access gateway. It consumes your identity provider over OIDC, so the non-human identity you define there is the identity hoop.dev authorizes against. Its network-resident agent proxies the Postgres connection at the wire level and reaches the database with the credential configured on the connection, while attributing the named identity at the gateway. The agent presents itself; it never holds the database password.
One model lets every agent share an anonymous role. The other gives each agent a name the database trail can speak.
Putting it in place
The setup is the same shape as any hoop.dev connection. Deploy the gateway, run the network-resident agent beside Postgres, and register the connection with its host, port, database, and credentials. Connect your identity provider so the agent principals you defined there become the ones hoop.dev authorizes against. Then point each agent at the hoop.dev endpoint. The getting started guide covers the install and the first connection.
From that point, the database trail stops being a wall of one repeated role and starts naming the actor behind each statement. That single change, attribution at the access layer, is what turns a fleet of anonymous agents into a set of principals you can reason about. It is also what makes the rest of your controls, scoping and timing and review, possible, because every one of them needs an identity to attach to.
Pitfalls
- One identity per agent role. Sharing a principal recreates the shared-password problem.
- Scope at the gateway, not only at the database. The connection credential is a floor; tighten the rest in policy.
- Plan offboarding. A principal you cannot cleanly revoke is a standing risk the day its agent is retired.
FAQ
Is a non-human identity just a service account?
It is the disciplined version of one: named per agent, scoped, attributed, and revocable independently, rather than a shared password.
Does Postgres need to know about the identity?
No. Postgres authenticates the connection credential. hoop.dev resolves and attributes the non-human identity in front of the database.
How are an agent's actions tied to its identity?
hoop.dev records each session against the resolved identity, so statements attribute to the specific agent.
What happens when an agent is retired?
You revoke its principal in the identity provider, and its access through hoop.dev ends. Because no other agent shared that identity or its credential, nothing else breaks, which is the offboarding story a shared role can never offer.
Does each agent need its own Postgres role?
Not necessarily. The connection credential can stay simple while distinct principals are scoped differently at the gateway, so you avoid managing a database role per agent.
hoop.dev is open source. See how a named agent principal binds to a Postgres connection in the hoop.dev repository on GitHub, and read the model at hoop.dev/learn.
