> ## Documentation Index
> Fetch the complete documentation index at: https://docs.atako.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Permissions

> Deny-by-default grants: exactly which actions each agent can call on each connection.

Connecting a tool under [Integrations](/integrations/overview) 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.

<Warning>
  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.
</Warning>

## Anatomy of a grant

A grant ties together four things:

| Component                 | Meaning                                                                                                                                                                                                                                                                  |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Agent × connection**    | Which agent, and which connected account, this grant applies to.                                                                                                                                                                                                         |
| **Allow-list of actions** | The exact set of individual actions the agent may call — e.g. `list_issues` and `create_issue` on GitHub, not "GitHub access" in general.                                                                                                                                |
| **Scope**                 | `read` or `read_write` — the two values the interface sets (the API also accepts a write-only scope). This is a second layer of defense on top of the allow-list: a `read` grant blocks every write action outright, even if one were somehow present in the allow-list. |
| **Expiration**            | Optional. A grant can be set to lapse automatically at a future date.                                                                                                                                                                                                    |

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:

<Steps>
  <Step title="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?"
  </Step>

  <Step title="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?"
  </Step>
</Steps>

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.

<Note>
  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.
</Note>

## Decision path

Every call an agent makes through a connection is checked in order, before any request reaches the provider:

```mermaid theme={null}
flowchart TD
    A[Agent sends an intent:<br/>connection + action + arguments] --> B{Grant exists for<br/>this agent × connection?}
    B -- No --> D[Denied — logged]
    B -- Yes --> C{Action is on<br/>the grant's allow-list?}
    C -- No --> D
    C -- Yes --> E{Grant's scope covers<br/>this action's read/write?}
    E -- No --> D
    E -- Yes --> F[Arguments validated]
    F -- Invalid --> D
    F -- Valid --> G[Executed against the provider]
    G --> H[Result returned to the agent]
```

Every outcome on this path — allowed or denied — is written to the audit trail described in [Security](/integrations/security#audit-trail).

## Examples

<AccordionGroup>
  <Accordion title="Support agent: read-only Zendesk">
    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.
  </Accordion>

  <Accordion title="Dev agent: GitHub read plus PR creation">
    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.
  </Accordion>

  <Accordion title="Time-boxed access for a one-off project">
    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.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Integrations overview" icon="plug" href="/integrations/overview">
    How connections are set up in the first place.
  </Card>

  <Card title="Security" icon="lock" href="/integrations/security">
    How credentials stay protected once a grant allows their use.
  </Card>

  <Card title="Activity" icon="list-check" href="/guides/activity">
    Where allowed and denied calls show up per agent.
  </Card>

  <Card title="Code capability" icon="code" href="/integrations/code">
    How grants extend to a per-repo allow-list for the Code capability.
  </Card>
</CardGroup>