The organization is the boundary. Everything that matters — members, teams, projects, wallets, API keys, product assignments, usage and audit — belongs to exactly one organization, and nothing crosses into another.
What the boundary separates#
| Scoped to one organization | |
|---|---|
| Members and roles | the roster is per organization; a grant never reaches outside it |
| Projects and teams | structure lives inside the organization |
| Project wallets | each project's balance funds calls made for that project only |
| API keys | a key resolves to one organization and one project — and can read nothing beyond them |
| Product assignments | a published product version is assigned to a project inside the organization |
| Usage and audit | recorded per call, readable inside the boundary |
One login, several organizations#
A single account can hold memberships in any number of organizations — a consultant working for two clients, or an employee who also has a personal workspace.
Roles never carry across. Owning one organization gives you nothing in another, not even visibility. You switch context explicitly, and your authority is whatever your grants say in the organization you are currently in.
The boundary is enforced at the API#
Isolation is not a property of the interface. Every request resolves its organization from the credential presented, and the check runs server-side on every call:
- An API key names its project implicitly; the
X-AIGrid-Projectselector may only restate it. A project id from another organization is not "less access" — it is404 not_found, because the project is resolved inside the key's own organization and simply does not exist there. - An organizational key cannot reach the holder's personal workspace either; that budget answers
404to it as well. - Guessing another project's product or sandbox id inside your own organization gets the same
404a stranger gets.
Personal workspaces#
First sign-in provisions a personal workspace: a personal organization with a managed team, a managed project, and an unfunded project budget. You hold Team Owner and Project Owner grants on it automatically, and its project is bound to every callable product visible to the workspace — there is no assignment step in a personal workspace.
A personal workspace obeys the same rules as any other organization: its keys work only for its project, its wallet funds only its calls, and none of its resources are visible to your other organizations.
What does not cross, ever#
- Money. A project wallet pays for its own project's calls and nothing else; there is no shared balance across organizations.
- Credentials. A key minted in one organization is meaningless everywhere else.
- Consumption rights. A project grant in one organization says nothing anywhere else.
Next#
- Security — how the boundary is enforced, and what is audited
- Roles and permissions — the grants that live inside the boundary
- Organizations, teams and projects — the structure itself