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 end to end. No agent ever receives write access — or any access at all — automatically. A grant with zero actions selected isn’t allowed to save.

​
Anatomy of a grant

A grant ties together four things: Because the allow-list and the scope are both enforced, narrowing access is never a one-step operation you can get wrong in a single field — an agent needs both the specific action listed and a scope wide enough to cover it.

​
Managing grants

Atako gives you two equivalent entry points into the same underlying grants — pick whichever pivot fits the question you’re asking:
1

From a connection

Settings → Integrations → Manage access on a connection. You see every agent, and can open each one to adjust its actions and scope on that connection. Good for “who can use our Zendesk?”
2

From an agent

An agent’s page → Manage integrations. You see every connection, and can open each one to adjust that agent’s actions and scope. Good for “what can this agent do?”
Both views use the same action grid: actions are split into a Lecture / Read group (green) and an Écriture / Write group (amber), selectable individually or by group, with a running count of selected read and write actions shown per agent or per connection so you can audit access at a glance without expanding every row.
Only the owner of an agent can change that agent’s grants. Reviewing access from the connection side still requires the right to manage that agent.

​
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, list_ticket_comments; scope = read. The agent can look up and summarize tickets but cannot close one, reassign one, or post a reply — even if a future software update added those actions to the allow-list by mistake, 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.
Grant: connection = a client’s shared Google Drive, actions = read-only file access, scope = read, expiration = end of the project. Access disappears on its own — nobody has to remember to revoke it.

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.

Code capability

How grants extend to a per-repo allow-list for the Code capability.