> ## 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. 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](#the-default-projects-grant).
</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`. You never enter it: the interface derives it from the actions you check — `read_write` as soon as one write action is checked, `read` otherwise (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, API only. A grant created through the API with an expiration date stops working once that date has passed; the interface doesn't set one. |

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.*

<Steps>
  <Step title="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](/guides/creating-agents#agent-settings).
  </Step>

  <Step title="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.*
  </Step>

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

Unchecking every action on a connection removes the grant: the agent can no longer call anything on it.

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

A coding agent on the [opencode engine](/concepts/engines) 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:

```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 --> K{Connection is<br/>active?}
    K -- No --> D
    K -- Yes --> C{Action is on<br/>the grant's allow-list?}
    C -- No --> D
    C -- Yes --> X{Grant has not<br/>expired?}
    X -- No --> D
    X -- 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`, `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.
  </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>
</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>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.