Your Database Can't See Who's Really Behind That Query

A database can only ever authenticate the connection in front of it. When that connection is the fourth hop in a chain of AI agents delegating work to each other, the database is enforcing access for an identity it has no way to fully verify — and neither, as it turns out, does OAuth. This is the multi-hop delegation problem, and it’s about to become a database problem whether or not anyone building the agent stack thinks of it that way.

What’s actually happening

Most database access-control conversations about AI agents still assume a single hop: a human authorizes an agent, the agent connects to the database, the database checks that agent’s identity and grant. Every control in this series so far — a SQL firewall, a schema-change approval queue, row-level security keyed to agent identity, and a credential audit registry — was built on that single-hop assumption. It’s a reasonable assumption for a lot of 2026 production systems. It stops holding the moment an orchestrator agent spawns a second agent to handle a sub-task, which spawns a third to actually touch the data.

That pattern — orchestrator agents delegating to sub-agents, which delegate further — is not an edge case anymore. It’s the default shape of agentic workflows built on frameworks like LangGraph, CrewAI, and Google’s Agent2Agent (A2A) protocol, and it’s exactly the scenario the OAuth working group has spent the last year trying, and largely failing, to fully solve. WorkOS’s April 2026 analysis of the problem lays out the mechanics plainly: OAuth’s Token Exchange specification, RFC 8693, handles a single delegation hop well — human authorizes Agent A, Agent A exchanges that authorization for a token to call Service B, and the chain (human → Agent A → Service B) is auditable end to end.{:target=”_blank” rel=”noopener noreferrer”} Add a second and third hop — Agent A spawns Agent B, which calls Agent C, which is the one that actually opens the database connection — and the chain becomes human → Agent A → Agent B → Agent C → database. RFC 8693 does support representing that longer chain, through nested “act” claims embedded in the JWT. But the specification itself is explicit that a token’s consumer must only consider the top-level claims and the current actor — prior actors named in nested act claims are informational only and are not to be used in access-control decisions.

Read that again from the database’s chair: the very standard governing how these tokens are supposed to carry delegation history says the database is not supposed to rely on that history for anything it enforces. Your database can see who’s connecting right now. It cannot see, in any way OAuth guarantees it can trust, who authorized the three hops that got that connection there.

Who this affects

Database architects and DBAs are the ones who inherit this gap operationally — they’re the last enforcement point in the chain, whether or not anyone designed it that way, because the database is where the actual data sits. Security and identity teams own the OAuth and token-exchange infrastructure upstream, but as the Cloud Security Alliance’s May 2026 whitepaper on non-human identity governance documents, most of them don’t have full visibility into agent-to-agent spawning events happening inside application logic, several layers removed from the identity provider. Compliance and audit teams are the ones who discover the gap latest and most painfully — when a regulator or auditor asks them to prove that a specific database write traces back to a specific human’s authorization, and the honest answer is that the chain fragments somewhere around hop two.

And CTOs and engineering leaders are who ultimately owns the business risk, because “we can’t fully reconstruct who authorized this write” is not a sentence anyone wants to say during an incident review or an EU AI Act audit.

When this becomes urgent

This isn’t speculative. Multi-hop delegation architectures are already in production. Four architectures — user-delegated, autonomous standing identity, hybrid orchestrated, and scoped impersonation — already dominate 2026 agent deployments, according to identity-industry analysis of current enterprise patterns. And the accountability gap it creates is already measurable, not projected: only 28% of organizations can currently trace agent actions back to a human sponsor across all their environments, and 51% report no clear ownership for their AI and non-human-identity population at all, per the same research.

The regulatory clock is also already running, not theoretical. The EU AI Act’s broader enforcement phase — with specific audit-trail requirements for high-risk AI systems — begins in August 2026, this month. SOC 2 and GDPR audits are already scrutinizing AI agent access patterns more closely than they were a year ago. The standards meant to close this gap are further out: the IETF drafts addressing multi-hop delegation — permission attenuation, cryptographically verifiable actor chains, cross-domain identity chaining — are active but not finalized, and NIST’s AI Agent Standards Initiative, launched February 2026, is still in the concept-paper stage for agent identity and authorization. Realistic timeline: the exposure is live now; the standards that would fully close it are 12-24 months out at best. That gap is exactly the window database teams need to cover with their own controls.

How this actually plays out in a database environment

Walk through a concrete version. A CFO authorizes an expense-processing workflow each morning with a single OAuth consent. Agent A reviews submitted expense reports. Agent A spawns Agent B to validate receipts against policy. Agent B spawns Agent C to process approved payments and write the results to the general ledger database. Under RFC 8693, each handoff produces a new bearer token — Agent A exchanges its token for one scoped to Agent B, Agent B exchanges again for Agent C. By the time Agent C opens a connection to your database, it’s holding a token several steps removed from the CFO’s original consent, and the nested act claims documenting that path are, by the standard’s own design, informational rather than enforceable.

Now the failure mode: security researchers spent the second half of 2025 demonstrating exactly how this breaks in practice, not in theory. In September 2025, researcher Johann Rehberger demonstrated Cross-Agent Privilege Escalation, showing a compromised agent could write malicious instructions into another agent’s configuration, which the second agent would load and execute on its own next run. Two months later, Palo Alto Networks’ Unit 42 published research on Agent Session Smuggling, showing how a compromised agent mid-chain could inject covert instructions into what looks, from every authentication log’s perspective, like a normal ongoing session — in their proof of concept, a “research assistant” agent progressively manipulated a connected “financial assistant” agent through multi-turn conversation until it triggered unauthorized trades, with no consent violation visible anywhere in the token exchange logs.

Translate that into a database write. Every individual query Agent C runs against your general ledger table can be perfectly well-formed, perfectly within Agent C’s own granted scope, and pass a row-level-security check cleanly — because RLS, like the firewall and approval-queue controls in this series, checks the current connecting identity’s declared scope. None of those controls were built to ask whether that identity’s authority was actually intact three hops back, because from inside the database, there’s no reliable signal that says otherwise. The audit trail shows every token exchange succeeded. The SIEM shows every API call authenticated correctly. The actual manipulation happened in the semantic layer between agents, a layer OAuth was never designed to observe — and the database, sitting at the end of the chain, is the only system that actually executes the consequence.

The credential-sharing shortcut that’s still common today makes this worse, not better. Industry surveys in early 2026 found a significant share of technical teams still use one shared API key across multiple agents for agent-to-agent authentication. When that’s the pattern, attribution collapses entirely — if something goes wrong three hops deep, your database logs show one shared login succeeding, with no way to determine which agent in the chain was actually compromised.

Actions to take now

1. Inventory every place a database credential is issued to an agent identity that isn’t the one initiating the original human-authorized workflow. Start by asking, for each agent with database access, whether it was spawned by another agent at runtime or provisioned as a standing identity. If you can’t answer that today, that’s the finding.
2. Stop accepting shared credentials across agents in any multi-agent workflow that touches the database, even temporarily. This is the single highest-leverage fix available immediately, because it’s the one thing that makes downstream forensics impossible if skipped, and it requires no new standard to implement — just separate, uniquely scoped credentials per agent identity.
3. Log the full delegation context at the database boundary, not just the connecting identity. If your agent framework can pass along the delegation chain (even as an informational claim, per RFC 8693), capture it in your database audit log alongside the query. It won’t be enforceable today, but it will be the difference between a fast forensic answer and a manual reconstruction exercise during an incident or audit.
4. Extend row-level security and statement-shape controls to be delegation-depth-aware where your agent platform supports it. An agent several hops removed from the original human authorization is a materially different risk than the agent the human directly invoked, even if both present the same declared scope. Treat “hop count” as a first-class signal, not an afterthought, in whatever policy engine sits in front of your database.
5. Pilot privilege attenuation at each spawn event, even manually, ahead of the IETF standards finalizing. The principle is simple and doesn’t require waiting for a ratified spec: no agent should be able to spawn a sub-agent with more database privilege than it holds itself. Enforce that as an application-layer rule now; it’s the direction the emerging IETF drafts on attenuating authorization tokens are already heading.
6. Add a runtime policy layer between agents and the database, not just at the token-issuance step, evaluating each connection against the current task context rather than trusting whatever token arrives. This is the architecture several major platforms — including Google’s Gemini Enterprise Agent Platform, announced April 2026 — are converging on, and it’s the pattern that will age well as the IETF and NIST standards mature, because it doesn’t depend on any single specification winning.
7. Build your EU AI Act and SOC 2 audit-trail story around delegation chains explicitly, not just individual access events, before an auditor asks for one you can’t produce. With enforcement already underway this month, this is the action with the shortest fuse on this list.

Key takeaways

• Multi-hop AI agent delegation — one agent spawning another, which spawns a third — is already the default shape of production agentic workflows, not an emerging edge case
• OAuth’s own Token Exchange standard, RFC 8693, explicitly states that nested delegation-chain claims are informational only and must not be relied on for access-control decisions — the database cannot trust what the token claims about hops upstream of the one connecting to it
• Only 28% of organizations can currently trace agent actions back to a human sponsor across all environments, and every control built on a single-hop assumption — firewalls, approval queues, row-level security — is enforcing scope for an identity whose upstream authority it cannot verify
• Documented 2025 attacks (Cross-Agent Privilege Escalation, Agent Session Smuggling) show this isn’t theoretical: manipulation between agents mid-chain can produce database writes that look perfectly authorized at every individual authentication check
• The fix available today isn’t waiting for IETF and NIST standards to finalize — it’s eliminating shared credentials, logging full delegation context at the database boundary, and making privilege attenuation and hop-depth policy first-class controls now

Getting ahead of this doesn’t require a finished standard. It requires treating the database as the last real enforcement point in a chain that OAuth itself admits it can’t fully verify. If your team is running multi-agent workflows against production data and isn’t sure how deep that chain actually goes, that’s worth a direct conversation before an auditor or an incident forces one.

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.