Access Control | airlock docs

Access control decides who in your organization can see and use a given integration, skill, or agent. 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.

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 or 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, and it never inherits the open default. Its grants are additive: granting a service account never restricts a resource for members.
Agents	Explicit only, like a service account. An agent is reachable by its author, by whoever holds a grant (a user, or a member of a granted group), and by administrators.
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 tab on the skill's detail page
Agents	The Access tab on the agent's detail page

You can also work from the other direction, starting from the principal rather than the resource:

Settings → Groups: create groups and manage who is in them. A grant to a group follows its membership, so adding someone to the group gives them everything the group can reach.

Settings → 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 your organization, this control on its Access tab narrows which of its tools everyone gets. It disappears once you choose specific people or groups, who then each get the tools set on their own row.
Each person, group or service account you choose. Every row on an integration's Access tab has its own tool list, so one group 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.

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.

To grant a group, call grant_access with targetType GROUP and the group's id as targetId. The group tools (create_group, list_groups, update_group, delete_group, add_group_member, remove_group_member) manage the groups themselves; adding and removing members is denied by the default management policy until an admin enables it.

Common setups

A sensitive integration only finance should use. Create a Finance group under Settings → Groups, add its members, then assign that group on the integration's Access tab. Everyone else loses access the moment the assignment lands. 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 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_services and search_tools come 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.