Governance v7

By default, an agent's tool calls run as whichever Postgres role called agent_converse. Governance gives you a way to confine that instead: register a purpose — a named policy scope that resolves to exactly one Postgres role — and assign that purpose to an agent. Every tool the agent calls then executes under that role, enforced by Postgres's own privilege system, not by anything the model decides.

Three roles

Governance splits authority across three roles, each answering a different question.

aidb_users and aidb_governance are independent — neither is granted to the other. A governor doesn't need aidb_users to administer purposes, and an ordinary aidb_users member can't touch the registry no matter what else they hold.

GRANT SELECT ON aidb.purpose_registry TO your_admin;

Authoring policy is a coarser question than a per-call membership check, so create_purpose doesn't require the governor to hold the role they're mapping a purpose to. A purpose naming a role nobody can invoke is harmless — the check that matters happens later, when an agent using that purpose is actually invoked. See Enforcement for what happens at that point.

Example

A governor registers a read-only purpose and a read-write purpose over two roles, then a user creates two agents against them. The agents use two custom SQL tools, read_tickets and update_tickets, so the roles need privileges only on the tables those tools query.

CREATE ROLE sales_tickets_ro;
CREATE ROLE sales_tickets_rw;
GRANT SELECT ON sales_tickets TO sales_tickets_ro;
GRANT SELECT, INSERT, UPDATE ON sales_tickets TO sales_tickets_rw;
-- The tools in this example are custom SQL tools, so the roles only need privileges on the tables the tools query.

SET ROLE sales_governor;  -- a member of aidb_governance
SELECT aidb.create_purpose('sales_support', 'sales_tickets_ro', 'Sales support agent');
SELECT aidb.create_purpose('sales_admin', 'sales_tickets_rw', 'Sales administrator');
RESET ROLE;

SET ROLE sales_user_1;  -- a member of aidb_users only
SELECT aidb.create_agent('ticket_reader', 'Answer questions about sales tickets.', 'my_gpt',
    tools => ARRAY['read_tickets'], purpose => 'sales_support');
SELECT aidb.create_agent('ticket_handler', 'Answer questions and update tickets.', 'my_gpt',
    tools => ARRAY['read_tickets', 'update_tickets'], purpose => 'sales_admin');
RESET ROLE;

ticket_reader's calls to read_tickets run as sales_tickets_ro regardless of who invokes it. ticket_handler's calls run as sales_tickets_rw. Neither agent's tool calls run as sales_user_1, the role that created them.

If an agent calls native tools instead, the resolved role also needs USAGE on schema aidb and EXECUTE on each tool's function. See Grants the resolved role needs.