# On-Behalf-Of Database Access for AI Agents

> On-behalf-of (OBO) is the pattern for AI agents to act with a caller's delegated identity instead of a shared credential. No mainstream database engine carries it the way agents need, and here is why a governance layer in front of the database is where it has to live.

Tianzhou | 2026-07-29 | Source: https://www.bytebase.com/blog/on-behalf-of-database-access-for-ai-agents/

---

On-behalf-of (OBO) is an OAuth pattern, formalized as token exchange in [RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693): 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 in `pg_stat_activity` and 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's `connectionAttributes`, Connector/Python's `conn_attrs`), landing in `performance_schema.session_connect_attrs`. Visible, but invisible to `GRANT`/`REVOKE`, which resolve on `user@host` alone.
- **SQL Server** actually solved this, decades ago, for one shape: Kerberos constrained delegation plus `EXECUTE AS` lets 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.](/content/blog/on-behalf-of-database-access-for-ai-agents/delegation-chain.svg)

`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](/content/blog/_shared/middleware.svg)

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.

## References

- [RFC 8693: OAuth 2.0 Token Exchange](https://datatracker.ietf.org/doc/html/rfc8693)

## Related reading

- [How to Govern AI Agent Database Access](https://www.bytebase.com/blog/how-to-govern-ai-agent-access-to-enterprise-data/)
- [Zero Trust for Databases: From Access Control to SQL Control](https://www.bytebase.com/blog/zero-trust-for-databases-access-control-sql-control/)