Roles and permissions
Who can do what in your organization, down to a table and its columns, for a reason and a limited time. An agent only ever has its person’s permissions.
Updated November 9, 2026.
You, to your agent: Give Camille read access to the sales database until the end of December.
When to use it
Use it to say who can do what, down to a table: a role, on a scope, for a duration.
How it works
Each grant gives a person or a group a role on a scope, from the organization down to a table and its columns, for a reason and until a date. A token or an agent only ever has its person’s permissions, bounded to its project, to reading or to environments.
What to know
A person’s permissions are the union of their current grants, direct and through their groups, and a group can follow an SSO group. A grant can also cover a connection. You only give what you have, never to yourself, and everything goes to the log. Giving permission to administer access, or changing the policy, waits for another person’s approval.
A token or an agent is bounded to its project, to reading, or to environments (production, previews, names); reading, for its part, is never bounded by environment. An organization can require an approval for any production deployment, a rollback or a task in production, never the reverse.
Permissions on data, down to the table, are enforced by PostgreSQL, with one SQL role per identity, for query and the CSV export; the app keeps the owner of its database. The explain_access tool says who has access, what a person can do and why, and its grant and revoke actions give and remove permissions.
Your agent’s MCP tools
Your agent handles it with the explain_access, list_tokens and get_organization tools.