Skip to main content
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, 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.
1

Ask Adapt in chat

Describe the rule in plain English, naming the integration:
2

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

Save

Click Save on the card, or tell Adapt to save it. The rule is active immediately.
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.
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.

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

​
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

Access controls

Roles, groups, and how Adapt scopes data access

Integrations overview

Connect and manage your tools