---
title: "Roles and permissions, down to the table: the while.sh docs"
url: https://while.sh/en/docs/building-blocks/roles/
updated: 2026-11-09
---

# 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.

> 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.

## Guides

- [Restrict an internal tool to Google Workspace or Microsoft 365 accounts, from your AI agent](/en/guides/internal-tool-company-sign-in/)