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

# Policies

> Control who can use each integration through Adapt with natural-language access rules.

Policies are access rules for your connected integrations, written in plain English. Instead of managing a permissions matrix, you tell Adapt who can do what — "only Engineering can write to our GitHub repos" — and Adapt enforces it on every action the agent takes.

## What policies are

A policy is a natural-language rule scoped to one integration provider. Each rule names an audience (a person, a [group](/security/access-controls#groups), or everyone), an operation (read, write, push, delete), and optionally a specific resource (a repo, branch, channel, dataset, table, or column).

* **Per provider.** A rule set is keyed to the provider, not a single connection. One rule covers every connection of that integration — organization and personal alike — and survives connections being removed and re-added.
* **Enforced at runtime.** Adapt checks the active policies before running any tool call. A rule that forbids an action for a given user stops that action from happening.
* **Authored in chat.** You write rules by asking Adapt in plain English. Adapt compiles the rule, resolves the people and groups you named, and asks you to confirm before it takes effect.

## Writing a policy

Only org owners and admins can create policies.

<Steps>
  <Step title="Ask Adapt in chat">
    Describe the rule in plain English, naming the integration:

    ```
    Only members of the Engineering group can write to our GitHub repos;
    everyone else has read-only access.
    ```
  </Step>

  <Step title="Review the compiled rule">
    Adapt resolves the people and groups you named, restates the rule faithfully (it never generalizes — "push to the `adapt-testing` repo" stays exactly that), and shows a confirmation card with a **Save** button. In Slack the card arrives as a message in the thread.
  </Step>

  <Step title="Save">
    Click **Save** on the card, or tell Adapt to save it. The rule is active immediately.
  </Step>
</Steps>

If a rule can't be resolved — an unknown name, the wrong integration, or a conflict with an existing rule — Adapt explains the problem instead of saving, so you can reword and try again.

<Note>
  Adapt compiles the rule against your organization's real people and groups. Name them the way they appear in your workspace so they resolve cleanly. Say "me" or "I" and Adapt resolves it to you.
</Note>

## What a rule can control

**Audiences.** Name an individual, a group, "everyone", or a relative audience like "everyone else". Groups are resolved to their members, so a rule about the Engineering group automatically covers whoever is in it.

**Operations.** Read, write, push, delete, "read-only", "no access", "full access", and similar phrases are all understood.

**Resources.** Rules can be as broad as a whole integration or as narrow as a single field:

* Repositories and branches (GitHub)
* Channels (Slack)
* Projects, datasets, schemas, tables, and individual columns (databases and warehouses)

For example, a rule can restrict reads of `project.dataset.customers.ssn` to the Finance group while leaving the rest of the table open to everyone.

<Note>
  These are Adapt's own runtime guardrails on what the agent does — not native cloud ACLs or source-system policy tags. They apply to actions taken through Adapt.
</Note>

## Managing policies

Every provider's rules live under the **Policies** tab on its page in **Settings** > **Integrations** > **\[provider]**. From there you can:

* **Disable or enable** a rule without deleting it. Disabled rules stop being enforced and sink to the bottom of the list.
* **Edit** a rule by rewording it. Adapt recompiles the new wording and shows any issues before saving.
* **Delete** a rule. The agent stops enforcing it immediately.

You can also make any of these changes by asking Adapt in chat. Each rule shows who added it and when.

## How enforcement works

Before the agent runs a tool that touches an integration, a guardrail evaluates the action against your active policies:

1. **The action is tokenized.** Adapt extracts the literal operations and resources the tool call performs — including tables and columns named inside a query string — without interpreting intent.
2. **The rule is applied to your verified identity.** Authorization is decided from your trusted identity and group membership, matched by ID (a renamed or duplicated display name never grants access).
3. **The most specific rule wins.** When several rules could apply, the one with the narrowest matching resource scope governs. A rule about a specific repo, branch, schema, table, or column overrides a broader rule about the whole integration. If no rule covers the action, it's allowed.

With no policies configured, nothing is restricted and Adapt behaves exactly as before.

## When an action is blocked

If a policy forbids an action, the agent stops and tells you why rather than working around it. When appropriate, Adapt can send a one-click approval request to an admin — in Slack or by email — who can allow that specific action. If they approve, Adapt retries the action automatically.

## Examples

```
Only the Finance group can read the salary column in our HR database.
```

```
Contractors have no access to GitHub.
```

```
Everyone can read Slack, but only the Support team can post messages.
```

```
Only I can query our production database; everyone else is read-only.
```

## Related

<CardGroup cols={2}>
  <Card title="Access controls" icon="lock" href="/security/access-controls">
    Roles, groups, and how Adapt scopes data access
  </Card>

  <Card title="Integrations overview" icon="plug" href="/integrations/overview">
    Connect and manage your tools
  </Card>
</CardGroup>