Skip to main content
Connecting a tool under Integrations makes it available to your company — it does not give any agent access to it. Access is a separate, explicit step called a grant. Until a grant exists, an agent can call nothing on that connection.
Atako is deny-by-default. No agent ever receives access to a tool you connect — read or write — automatically; the only exception is the built-in Projects integration, described below.

​
Anatomy of a grant

A grant ties together four things: Because the allow-list and the scope are both enforced, an agent needs both the specific action listed and a scope wide enough to cover it.

​
Managing grants

Grants are set agent by agent, never from the connection itself — the Integrations cube on the Context storey only connects tools, and says so: What each agent is allowed to do with them is set agent by agent.
1

Open the agent's settings

On the Floor, click the agent, then Agent settings in the agent panel. You can also set the same access when you create the agent. See Agent settings.
2

Go to the Integrations section

It lists every active company connection. If no tool is connected yet, it says No company connection to grant yet.
3

Choose the actions

Each connection row has a Read and a Write toggle that check or uncheck a whole group at once — write implies read, so turning Read off turns Write off too. Expand the row to pick individual endpoints, with All / None per group; the collapsed row shows how many read and write actions are checked. Each change is saved on its own and applies immediately.
Unchecking every action on a connection removes the grant: the agent can no longer call anything on it.
Only the agent’s creator or a company admin can change its grants. A teammate who can see and use a company agent can’t hand it new powers.
A coding agent on the opencode engine doesn’t get this section: its settings show its Allowed repositories instead.

​
The default Projects grant

The built-in Projects integration is company-wide and granted by default: until you change it, every agent can use all of its actions, and its row in Agent settings carries a Default tag. Unchecking its actions removes that access for the agent, and the choice is kept.

​
Decision path

Every call an agent makes through a connection is checked in order, before any request reaches the provider: Every outcome on this path — allowed or denied — is written to the audit trail described in Security.

​
Examples

Grant: connection = company Zendesk, actions = get_ticket, list_tickets, search_tickets, get_ticket_comments; scope = read. The agent can look up and summarize tickets but cannot close one, reassign one, or post a reply — even if write actions were somehow added to the allow-list, the read scope alone would still block them.
Grant: connection = company GitHub, actions = the full read set (get_file_contents, list_issues, get_pull_request, …) plus create_pull_request; scope = read_write. The agent can explore the codebase freely but can only ever open a pull request — it has no merge_pull_request or delete_file action on its allow-list, so those stay unreachable regardless of scope.

Integrations overview

How connections are set up in the first place.

Security

How credentials stay protected once a grant allows their use.

Activity

Where allowed and denied calls show up per agent.