> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cogniagent.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Permission rules
> Say once what your AI coworker may always do, must always ask about, and may never do — instead of approving the same thing every day.
Approving the same action every day is a waste of your attention. Permission rules let you decide once.
## The three answers
Every rule gives one action one of three answers.
| | What it means |
| ---------------- | --------------------------------- |
| **Always allow** | Go ahead, don't ask me |
| **Always ask** | Stop and check with me every time |
| **Never** | Don't do this, at all |
Anything you haven't written a rule for keeps the default:
> Actions no rule matches keep the default: sends, changes, and deletions pause for your approval.
So you're not starting from nothing. Rules are adjustments to a sensible baseline, in either direction.
## When you'd write one
**To stop being asked** about something routine that's obviously fine. Your coworker posting to the team channel it always posts to.
**To be asked** about something the default lets through. A coworker allowed to update records, where you'd rather see the ones touching pricing.
**To rule something out entirely.** Deleting. Emailing outside the company. A specific app you attached for reading only.
**Start with the "never" rules.** They're the ones with real consequences and they take two minutes. Loosening things to reduce prompts can wait until you know what you're actually being asked about.
## Where they live
On the coworker's **Files** tab, in the file labelled **Permissions**.
Rules take effect from your coworker's next step — you don't need to restart the task.
A rule can take power away, and it can remove a prompt for something your coworker was already allowed to do. It cannot grant a capability that's switched off. If [Talking to people](/cowork/capabilities/talking-to-people) is off, no rule makes it possible.
If the permissions file can't be understood, the whole thing is rejected rather than partly applied. Your coworker falls back to the default — asking before sends, changes and deletions — instead of running on a half-read rule set.
## The strictest rule always wins
When more than one rule matches the same action, the **strictest** of them applies:
Two consequences worth knowing:
* **Order doesn't matter.** Moving rules around can never weaken your policy, so you can't accidentally undo a "never" by adding something below it.
* **A narrow rule can't loosen a broad one.** If you've said never delete anything, adding "always allow deleting drafts" does *not* create an exception — the never still wins. To carve out an exception, narrow the original rule instead of layering another on top.
## A sensible starting set
For a coworker with real access to your systems:
* **Never** delete anything
* **Never** email outside the company
* **Always ask** before anything touching pricing or contracts
* **Always allow** posting to its own team channel
* **Always allow** reading from any connected app
That takes a few minutes and removes most of the anxiety about giving a coworker real access.
## Rules, connections, or capabilities?
Three levels of control, from broadest to finest.
| | Controls | Use when |
| ---------------------------------------------------------------- | ----------------------- | ------------------------------------------------ |
| **[Capabilities](/cowork/capabilities/overview)** | Whole abilities | The coworker never needs this at all |
| **[App connections](/cowork/capabilities/connecting-your-apps)** | Which actions in an app | Read yes, write no |
| **Permission rules** | What needs asking about | The action is fine, the *asking* is the question |
Reach for the finest one that solves your problem. Switching a capability off to avoid a prompt is a blunt fix that costs you the capability.
## Common questions
No. The default already pauses for sends, changes and deletions. Rules are for tuning, not for basic safety.
It can propose a change, and it lands on the Improvements tab for your approval like anything else. It can't quietly widen its own permissions.
Yes — they belong to the coworker, so every task it runs uses them.
The **strictest** one wins — never, and never asks, both beat allow. Being more specific doesn't override it, and neither does being further down the list. See "The strictest rule always wins" above.
Yes, and they should. A research coworker and one with access to your CRM warrant very different rules.
## Next steps
What asking looks like.
Control at the action level.
The broadest control.
Rules that act rather than ask.