Access control decides who can see and use a given integration, skill, or agent, inside the space it lives in. For an integration, it also decides which of its tools they get.
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.
Start with spaces. Where a resource lives answers most access questions on its own, and the grants described here are the narrowing you reach for when a space is not the right shape.
The one rule that surprises people
A resource with no assignments is visible to everyone in its home space. Adding the first assignment restricts it to the principals you name. Everyone else in that space 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 its space loses it in the same moment.
To go back, remove every assignment: the resource is reachable by its whole home space again.
How the model works
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
Every Access tab is for admins only; members don't see it. A personal skill has no grants to manage: only its creator uses it until it becomes an organization skill.
A shared connection is one credential an admin stores for an integration (Share with your team under Your connection on its Settings tab) so that people can call it without connecting their own account. It works the other way round from the rule above: nobody uses a shared connection until you grant it. With no one chosen under Who can use it, it stays unused. Grant it to specific people, spaces or service accounts, and only they call the integration through it. Turning sharing off keeps the grants but makes them dormant, so they apply again if you turn it back on.
Each of those pages also has a Spaces tab, for administrators (on an integration, a Spaces section at the bottom of its Access tab), which is where the resource's home and the spaces it reaches are managed, and, for a skill or an agent, its lends. An integration is not lent: a space that needs one adds it itself.
You can also work from the other direction, starting from the principal rather than the resource:
- Settings → Spaces: a space's own page lists its members and every capability homed in or lent to it.
- Identities → Users: see and edit what one member 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
An integration's tools can be narrowed in these places, and only these:
- Default tools for everyone. While an integration is open to everyone in its home space, this control on its Access tab narrows which of its tools everyone gets. It disappears once you choose specific people or spaces, who then each get the tools set on their own row.
- Each person, space or service account you choose. Every row on an integration's Access tab has its own tool list, so one space can get the read tools while another gets the write tools, without creating two integrations. A row with no list of its own gets every tool the integration's policies allow.
To keep a tool away from everyone, set its policy to deny or to require approval.
Limiting a connector across the organization
By default each space decides who in it reaches a connector. On the Rules page, under Connectors, an admin can open a connector and set its Access to Custom to name the spaces, people and service accounts that may use it anywhere in the organization.
- A named space covers the connections of that connector homed in it, for whoever the space admits. Being a member of a named space does not reach a connection homed in another space.
- A named person or service account can use the connector in any space that already admits them.
- It only narrows. A caller has to pass both the limit and the space's own access, so naming someone never gives them a space they are not in.
- Admins are limited too when they use the connector in a chat. They still see and manage every connection of it in the Control Room.
- Adding a connection of a limited connector in a space the limit leaves out is refused, unless the person adding it is named.
A connector outside the limit is neither listed nor callable over MCP for that caller. Custom is only saved once somebody is named, and switching back to Everywhere lifts the limit.
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, all without anyone opening the Control Room.
Common setups
A sensitive integration only finance should use. Create a Finance space, add its members, and home the integration there. No member outside the space sees it, and there is no grant to maintain. Service-account grants are separate and additive, so a bot you granted the integration keeps it: revoke that grant too if the point is to close the integration off entirely.
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 have an admin convert it to an organization skill when it's ready (only admins can move a skill to organization ownership). 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 reach only the spaces they are in. An administrator uses a space in their AI chats only after joining it, so an integration missing from an administrator's AI client usually means they are not a member of its space. To reproduce a member's problem, check the member's effective access rather than testing as yourself.
- Space membership is the lever, not the grant. Homing a resource in a space, rather than naming people on it, means onboarding someone is one membership change instead of a sweep across every resource.