On-behalf-of (OBO) is an OAuth pattern, formalized as token exchange in RFC 8693: a middle-tier service exchanges the original token for a new one that still carries the original caller's identity plus a record of who's now acting on their behalf, so whatever receives it knows both who asked and who's actually calling.
An agent calling a database isn't the one who should be authorized; the person who asked it to run the query is. OBO is how you keep that straight through a hop the database was never designed to see through.
Databases weren't built for agent access
None of the four mainstream engines carry delegated identity the way agents need it.
- Postgres:
application_name, a client-set session parameter, visible inpg_stat_activityand the log.GRANT,REVOKE, and row-level security never look at it. A label, not an input to authorization, and unverified. - MySQL is Postgres's twin: a connection attribute like
app_name(JDBC'sconnectionAttributes, Connector/Python'sconn_attrs), landing inperformance_schema.session_connect_attrs. Visible, but invisible toGRANT/REVOKE, which resolve onuser@hostalone. - SQL Server actually solved this, decades ago, for one shape: Kerberos constrained delegation plus
EXECUTE ASlets a service impersonate the calling Windows principal end-to-end, so permission checks run as the real user. - Oracle did too: proxy authentication (
CLIENT_IDENTIFIER, since 9i) lets a middle tier run statements as the end user, with Virtual Private Database and Fine-Grained Auditing evaluating against that real identity.
Both are binary impersonation, not a scoped grant, and both are capped at one trusted middle tier, not chainable. Neither anticipated an agent calling a sub-agent calling a tool. Databases solved delegation once, for a single trusted tier. None solved the version AI agents need: scoped, short-lived, chainable.
What AI agent access actually needs
Authenticating the agent is the easy half; a service account or a signed workload identity solves that. The harder question is authorization: given that this is really the finance-agent, what is it allowed to do, on whose authority, for what request? OBO carries a scoped, short-lived grant through the chain, tied to the human who asked, not a standing credential the agent holds for every task.
A human's request passes through Agent A and Agent B before reaching the database. At each hop, token exchange issues a new token: sub stays the human, aud changes to the current hop, and act nests the previous actor.
sub stays the human at every hop. aud and act change. Miss that at any single hop, exactly the way application_name gets lost across a pooler, and whoever enforces policy at the database is enforcing it against the wrong principal, or against no one in particular.
Why this has to live in front of the database
Database engines weren't built anticipating any of this, and it's unrealistic to expect any of the four, Postgres, MySQL, SQL Server, or Oracle, to retrofit scoped, chainable delegation. The fix isn't inside the engine. It's a governance layer in front of it, one that terminates the agent's request, resolves who the real human principal is, and makes the authorization decision before a single SQL statement reaches the database.
Bytebase is one control plane between consumers (human, AI agent, application) and databases, enforcing just-in-time access, dynamic data masking, SQL review, risk assessment, approval flow, and audit logging
Bytebase is that governance layer. Humans, AI agents, and applications all go through the same control plane, whichever interface they use, GUI, API, or MCP server, and the same policies apply regardless of who's asking.