Access control decides who in your organization can see and use a given integration, skill, or agent — and, for an integration, which of its tools.
It sits above policies: a policy decides whether a particular call is allowed, approved, or denied; access control decides whether the tool is visible to that person at all.
The one rule that surprises people
A resource with no assignments is visible to every member of your organization. Adding the first assignment restricts it — everyone not named, directly or through a group, immediately loses access.
There is no "make private" switch. Scoping is the act of granting the first person access. If you add one user to an integration that previously had none, everyone else in the organization loses it in the same moment.
To go back to organization-wide visibility, remove every assignment.
How the model works
| Principal | Rule |
|---|---|
| Members | Open until assigned. A resource with zero user/group assignments is visible to all members; once it has at least one, only the assigned users and the members of assigned groups can reach it. |
| Service accounts | Explicit only. A service account sees nothing it has not been directly granted — it never inherits the open default. Its grants are additive: granting a service account never restricts a resource for members. |
| Admins | Bypass scoping entirely. |
Integration and agent grants take effect on the very next request. Skills are the exception: the skill catalogue an agent sees is cached briefly, so a skill grant or revocation can take up to a minute to show up in tools/list — activation authorization itself changes immediately.
What can be scoped
| Resource | Where to manage it |
|---|---|
| Integrations | The Access tab on the integration's detail page (admins only) |
| Skills | The Access section under a skill's Settings tab |
| Agents | The Access section on the agent's detail page |
You can also work from the other direction — from the principal rather than the resource:
- Settings → Users & Groups — see and edit what one member or one group can reach.
- A service account's detail page — the Access section grants that bot its integrations, skills, and agents.
Narrowing an integration to specific tools
A grant on an integration can cover all of its tools or a selected subset. That is how you give one team the read tools on a service while a different team gets the write tools, without creating two integrations.
While an integration is still open to the whole organization, a Default tools for everyone control lets you narrow which of its tools everyone gets by default. It disappears once you assign a user or group, because the integration is then restricted to those principals and their own tool scopes take over.
Managing access from an agent
The same grants are available to an admin over the organization's MCP endpoint, through the management tools. An agent connected with an admin's credentials can grant, list, and revoke access to skills, agents, and integrations — and set an integration's tool scope — without anyone opening the Control Room.
Common setups
A sensitive integration only finance should use. Create a finance group, add its members, then assign that group to the integration. Everyone else loses access the moment the assignment lands.
A bot that should only touch one integration. Create a service account, grant it exactly that integration (optionally scoped to specific tools), and grant it nothing else. It starts with no access, so there is nothing to take away.
A skill you're still drafting. Keep it a personal skill while you iterate, then convert it to an organization skill when it's ready — that is simpler than assigning and un-assigning an organization skill.
Gotchas
- The first assignment is a restriction. If a resource stops working for most of your team, check whether someone added a single access grant.
- Service accounts start blind. A new service account still sees airlock's meta-tools, but
list_servicesandsearch_toolscome back empty until you grant it something. That is by design, not a bug. - Admins won't reproduce a member's problem. Because admins bypass scoping, an admin testing an integration will always see it work. Check the member's effective access instead.
- Group membership is the lever, not the grant. Assigning groups rather than individuals means onboarding someone is one membership change, not a sweep across every resource.