Give every team exactly the access it needs.
Groups organise your workspace by team, so who can reach which agents, apps and data tables is decided by membership rather than by memory. Grant explicitly, revoke in the same click, and keep the record behind every change.
Access shouldn't live in a spreadsheet.
Before a workspace has structure, who-can-use-what is tribal knowledge, and every change is a ticket.
Access by spreadsheet
Who can reach which agent lives in a doc somebody updates when they remember. Every new joiner starts with a request and a wait.
A group makes access a structure, not a habit.
All-or-nothing sharing
Without scopes, an agent is either private to its maker or open to the whole company. Nothing in between for a team, nothing at all for people off your payroll.
Grant a team exactly the agents and data it needs.
Offboarding is guesswork
When someone leaves, nobody can list what they could reach. Access that was granted ad hoc has to be revoked ad hoc, or forgotten.
Remove one membership and everything goes with it.
Access belongs to the group, not to the person.
Grants are held by the group. People arrive and leave through membership, and what they can reach follows in the same moment.
One membership, every grant.
Add someone to a group and they hold exactly what the group holds, nothing more. Remove them and it all goes at once, with nothing left behind for somebody to find later.
Grant access explicitly.
Private agents, apps, and data stay locked until you grant a group in.
Movers, not only leavers.
A change of team is a change of membership. The old team's grants stay with the group. None follow the person.
Owners, Admins, and Members.
Every group names who can change it. Owners hold the group, Admins run it, Members work inside it.
People who are not on your payroll.
Partners, contractors and auditors get a group of their own, with its own grants and nothing borrowed from anybody else's. When the engagement ends, the membership ends with it.
Audited and isolated.
Every change is logged, and each workspace stays strictly isolated per tenant.
What a grant actually decides.
A group grant reaches further than a door. It bounds what an agent reads on behalf of a member, it composes with the policies attached to their role, and it leaves a record either way.
An agent runs inside the group's grants.
A member can run any agent the group holds. When they do, it reads the apps and tables the group was given and nothing else, whatever it is asked for.
- Granted per agent, never inherited by convenience
- It cannot open a table the group was not given
- The same boundary whoever in the group is asking
A group grant and a policy are one decision, seen from two sides.
What someone can open resolves the same way wherever you look at it from: the union of what their groups were granted, with a deny attached to their role overriding an allow.
- Per-app access, granted to the group
- Union of every group they belong to
- Deny overrides allow, every time
The record writes itself.
Bases and data tables follow the same grant model as everything else, and each grant, revocation and membership change writes its own log entry as it lands.
- Per-table access, scoped to the group
- Actor, resource and timestamp on every change
- An access review reads the log, not memories
Ask the question an auditor asks.
Pick a person and see everything they can reach across agents, apps and data tables, with the granting group named beside each one. Take a membership away and every grant behind it goes in the same moment. Nothing else moves.
- Reconciliation agentvia Finance Analysts
- Analytics appvia Finance Analysts
- Reports tablevia Finance Analysts
- Close checklistvia Quarter close
Every row here arrived through a membership. Turn one off.
Two memberships, and every row names which one it came from.
Security stops being the queue.
When access is a structure rather than a favour, a team does not raise a ticket to try an agent. Draw the boundary once, hand the group its agents, apps and tables, and let it work inside it at its own speed. The review happens per group, once, not per request, where it never ends.
A new joiner starts inside the boundary their team already has, rather than at the back of a queue.
Trying a second agent is one grant on a group that already exists, not a second security review.
The access review becomes a short list of groups, not a hunt for everyone who was ever given something.
An access review should be a query.
Every grant, revocation and membership change lands in the same audit trail, on infrastructure you run. When an auditor asks who could reach the finance tables in March, that is a lookup rather than an archaeology project.
Groups, by the spec.
- Access model
- Role-based access control
- Roles
- Owners · Admins · Members
- Scopes
- Agents · apps · data tables
- Effective access
- Resolved per person, across every group
- Agents
- Run inside the group's grants
- Membership
- Active · pending · seat capacity
- Access changes
- Granted & revoked explicitly
- Audit
- Actor, resource and time on every change
- Isolation
- Strictly isolated per tenant
- Deployment
- On-prem · private cloud · air-gapped
- Compliance
- SOC 2 Type II · HIPAA · GDPR · ISO 27001
The grants, revocations and memberships above run under the controls these audits cover.
See Exemplary AI in action
Book a demo and we'll show you purpose-built agents grounded in your own knowledge — deployed on your infrastructure.