Diagram showing three AI agents each authenticating with a unique cryptographic identity at the identity provider, then all three connections merging into one shared service-account login at the database connection pooler

Microsoft’s Entra Agent ID and Google’s Gemini Enterprise Agent Platform both went generally available in the first half of 2026, giving every AI agent in an enterprise a unique, auditable, cryptographically verifiable identity for the first time. It’s a genuine advance over the shared API keys and generic service accounts agents used before. But that identity dies the moment the agent’s query reaches the database, because the connection pooler sitting in front of nearly every production database — PgBouncer, RDS Proxy, most managed Postgres and MySQL offerings — collapses every pooled connection back down to one shared login. The audit trail you just built at the identity layer stops exactly where it matters most.

What’s happening

Non-human identities — service accounts, API keys, OAuth tokens, and now AI agents — already outnumber human identities in most enterprises by more than 90 to 1, and governance has not kept pace with that growth (Akeyless, 2026). In April 2026, Microsoft made Entra Agent ID generally available, extending Zero Trust identity and specialized OAuth flows to non-human principals, and Google launched Gemini Enterprise Agent Platform the same month with Agent Identity, an Agent Registry, and an Agent Gateway that assigns every agent a unique cryptographic ID mapped to its own authorization policy (Lovex, 2026; Infisign, 2026). For the first time, an enterprise can say with confidence which specific agent instance requested which specific action at the identity-provider layer.

That confidence evaporates at the database tier. PostgreSQL added native OAuth 2.0 client support, but the built-in PgBouncer pooler doesn’t support OAuth authentication at all — pooled connections have to fall back to native password roles (PostgreSQL documentation). Managed cloud offerings that support workload identity for direct connections — Azure Database for PostgreSQL’s managed-identity auth is one example — routinely can’t carry that same token-based identity through the connection pooler layer they also offer for scale (Microsoft Learn). The practical result: a fleet of agents each holding a distinct, revocable, auditable identity at the IdP funnels through a pool of a handful of shared database credentials the moment connection pooling — which almost every production database needs at agent-driven query volumes — enters the picture.

There’s a parallel effort underway to solve a related problem at the infrastructure layer: SPIFFE/SPIRE, the CNCF-graduated standard for workload identity, issues short-lived cryptographic identities to services and workloads rather than relying on static secrets. It’s a natural complement to agent-identity platforms because it addresses machine-to-machine authentication generically, not just agent-to-application-server authentication. But SPIFFE identities still have to be translated into something a database’s authentication layer understands, and that translation runs into the same pooler bottleneck — a SPIFFE-issued short-lived certificate doesn’t help if the connection it authenticates gets pooled and reused by a different workload’s next query. The identity fabric keeps getting stronger at every layer except the one closest to the data.

Who this affects

Database platform teams and DBAs own the pooler configuration and are the ones who will be asked, after an incident, “which agent ran this query” and will not have an answer better than “one of the twelve using that pool.” Identity and access teams who just finished standing up Entra Agent ID or an equivalent platform need to know their investment stops at the database’s front door unless someone closes this specific gap — this isn’t a general awareness problem, it’s a specific architectural seam between two systems that were built by different teams on different timelines. CISOs and compliance leads who are relying on the new agent-identity platforms to satisfy audit or regulatory requirements around AI system accountability need to verify that the audit trail those platforms promise actually survives contact with the data layer, not just the application layer. And application/agent-framework engineers building on LangChain, CrewAI, AutoGen, or similar need to understand that the identity their framework hands off to the IdP is not the identity that ends up in the database’s own logs.

When this becomes a real problem

This is already live, not hypothetical. Both major agent-identity platforms are GA as of this writing, and adoption is accelerating through the back half of 2026 as enterprises operationalize agent fleets that were piloted earlier in the year. The gap between IdP-layer identity and database-layer identity has existed since connection pooling was invented decades ago — it was tolerable when the “agent” behind a pooled connection was a monolithic application server with predictable, low-cardinality behavior. It stops being tolerable now, because AI agents produce exactly the failure mode connection pooling was designed to survive: bursty, high-cardinality, many-short-lived-connections traffic — and that’s precisely the traffic pattern that forces pooling in the first place. The two forces are colliding in real time: more agents, each needing distinct auditability, hitting databases through more aggressive pooling, which erases the distinction pooling was never designed to preserve. Expect this to surface as a named finding in AI governance audits within the next 12-18 months, once enterprises try to reconcile their new agent-identity dashboards against their actual database audit logs and find the two don’t line up.

How it actually plays out

Picture a database with a connection pool of 20 backend connections serving 200 AI agent instances, a completely normal ratio at agent-driven query volumes. Each agent authenticates to Entra Agent ID or Gemini’s Agent Gateway with its own credential, gets its own token, and that token-issuance event is logged with full fidelity — agent name, task context, timestamp, scope. The agent’s query then goes through an application layer that, to get connection reuse and avoid the overhead of a fresh TLS handshake and auth round-trip per query, checks a connection out of the pool. That pooled connection authenticated to the database once, as a single service principal, when the pool was created or last recycled. The database’s own query log — the one a DBA actually pulls during an incident, and the one most compliance frameworks accept as the system of record for “who touched this data” — shows that service principal’s name on every single query, regardless of which of the 200 agents actually issued it.

If application-layer logging is solid, you can sometimes reconstruct the mapping after the fact by correlating timestamps between the IdP’s token log and the database’s query log. But that correlation is probabilistic, breaks down under concurrent load, is not admissible as a clean audit trail, and does nothing at query time — it can’t be used to enforce different row-level permissions, different query cost limits, or different DDL approval requirements per agent, because the database genuinely does not know which agent it’s talking to. Every access control this blog’s earlier posts on agent guardrails, row-level security, and credential auditing described has to be re-derived at the application layer instead of enforced at the data layer, which is exactly the pattern that makes those controls bypassable by a compromised or buggy application tier.

Play this forward to an actual incident. An agent with legitimate access to a customer support database starts issuing an unusual pattern of bulk export queries — the kind of thing that should trigger a per-agent rate limit or an anomaly alert tied to that specific agent’s baseline behavior. If the query hits the database through a shared pooled connection, the anomaly-detection system watching the database’s own query log sees the aggregate behavior of every agent sharing that connection, not the one agent actually responsible. The alert either fires too broadly (flagging 200 agents’ combined traffic as anomalous) or not at all (because the one bad actor’s queries are diluted into a large pool’s normal-looking aggregate). Either way, the response team’s first move — figure out which agent to suspend — has to happen through log correlation and guesswork instead of a single query against the database’s own access history.

Actions to take now

  1. Pull your current connection pooler’s auth log and see what identity actually lands in it. Before evaluating any fix, confirm the gap exists in your own stack: if your pooler shows one service account name for a fleet of agents, you have this problem today, independent of whether you’ve adopted Entra Agent ID or Gemini’s platform yet.

  2. Inventory every place agent traffic crosses a pooler, proxy, or connection multiplexer between the application and the database. This includes PgBouncer, RDS Proxy, Azure’s built-in Flexible Server pooling, ORMs with internal connection pools, and any service mesh sidecar doing connection reuse. Each one is a potential identity-collapse point, not just the obvious ones.

  3. Check whether your database and pooler combination supports per-session identity tagging even without full OAuth passthrough. PostgreSQL’s SET ROLE after connection checkout, application_name tagging, and session-level custom GUC variables set per-query are workarounds that preserve some per-agent attribution inside a shared connection, at the cost of extra round-trips — evaluate the performance tradeoff for your actual query volume rather than assuming it’s prohibitive.

  4. For net-new agent workloads, evaluate direct (non-pooled) connections with native workload identity for the highest-privilege or highest-audit-requirement agents specifically, accepting the connection overhead for the subset of agents where per-agent database-level auditability is a hard requirement, while leaving lower-risk, high-volume agents on pooled shared connections.

  5. Push your cloud provider and pooler maintainers directly for OAuth/workload-identity passthrough in pooled connections — this is a solvable engineering problem (some proxies already do partial token validation before falling back to a shared backend credential), but it isn’t solved yet in the mainstream open-source poolers, and vendor prioritization responds to demand signal.

  6. Update your incident response runbook now, before you need it, to explicitly document the current limits of “which agent did this” attribution given your pooling architecture, so a real incident doesn’t surprise the response team with a gap they assumed didn’t exist.

  7. Reconcile your agent-identity platform’s audit log against your database’s query log on a recurring basis — even a manual quarterly spot-check will surface whether the correlation is holding up as agent volume grows, before a regulator or auditor does that reconciliation for you.

Key takeaways

  • Entra Agent ID and Gemini Enterprise Agent Platform, both GA since April 2026, give every AI agent a unique cryptographic identity — but that identity is verified at the application/IdP layer, not necessarily preserved at the database layer.
  • Connection poolers like PgBouncer don’t support OAuth authentication for pooled connections, forcing a fallback to shared, static database credentials regardless of how granular the identity is upstream.
  • The result is an audit trail that looks complete in your identity platform’s dashboard but goes blank at exactly the point — the database — where most compliance and incident-response questions actually get asked.
  • This gap is architectural, not a configuration mistake: it exists because pooling and per-identity authentication were designed to solve different problems, and nobody has fully reconciled them yet for agent-scale traffic.
  • Auditing your own pooler’s connection log today, before an incident forces the question, is the single highest-leverage first step.

Closing this gap requires rethinking how identity, pooling, and database access controls fit together for agent-scale traffic — not just picking a product off a vendor list. Get in touch if you want a second set of eyes on where your database’s audit trail actually breaks down.

Ivan Lima is a data engineer specializing in database modernization for AI systems. Get in touch if your database needs to be ready for what’s next.