# What the Assistant may not do

You can do things the Assistant may not, and that gap is designed rather than unfinished. It cannot set a price and it cannot clear a do-not-contact entry. It cannot widen the autonomy rules it works under, reach another workspace, or read a sealed credential. Every refusal names the limit and is kept in the decision log.

- **Status:** Available
- **Audience:** both
- **In the app:** #/autonomy, #/autonomy-audit, #/billing
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/assistant/assistant-authority/

## The two named limits

**It cannot set a price** — A price is a commitment your business makes to somebody, and somebody has to own it. A model that produces a plausible number under pressure — because a customer asked twice, because the conversation had momentum — is producing the most expensive kind of plausible sentence there is. So there is no tool for it and no argument on any card that reaches one.
**It cannot clear a do-not-contact entry** — A suppression is a promise made to a person who is not in the room. Clearing one is not an administrative tidy-up; it is deciding to contact somebody who asked not to be contacted. That belongs to a person who can be asked why.

Both hold when you ask directly, and both hold when the request arrives wrapped in something reasonable — a draft that would quote a figure, a bulk action that would sweep a suppressed contact back into an audience. The limit is on the capability rather than on the phrasing.

## The limits that come from where it sits

| Limit | Enforced by | What you see |
|---|---|---|
| Another workspace's data | The tenant allowlist, the workspace kernel and row-level security | Nothing at all — outside data is invisible rather than forbidden |
| Wider autonomy than the channel allows | Autonomy modes and scopes, narrowest first | A confirmed action held rather than done |
| Sending past a spent allowance | Metering and the plan's daily ledger | The approval recorded, the send waiting |
| Sealed provider credentials | Credentials sealed on save and never echoed to a screen | Configuration reported, keys never shown |
| Operator-only platform surfaces | Payment verification, JBRH's own pricing and website enquiries sit outside every workspace | Not reachable from a customer workspace by any route |

Those are not Assistant rules. They are the workspace's rules, and the Assistant meets them because every write travels through the service that owns the thing. An assistant that wrote rows directly would have to reproduce each of them, and would eventually miss one.

## Why separate the agent's authority from the person's

Because they fail differently. A person who makes a bad commitment knows they made it, remembers the conversation and can be asked about it. A model that produces the same commitment does so without any of that, from a prompt nobody kept, and the first anyone hears of it is when a customer holds you to it.

Narrowing the agent is therefore not a statement about how good the model is. It is a statement about which decisions should have a person attached to them, and it stays correct as models improve. [Separating the agent's authority from the person's](/research/authority-separation/) sets out the reasoning.

> **Note** The corollary is worth saying: within its rights, the Assistant is not held back. It reads whatever you can read in your workspace and proposes whatever it can carry out. The narrowing is specific, not general caution.

## Reading a refusal

1. Read the reason. Refusals name which limit applied, and the four common ones resolve in four different places.
   - Result: You know whether you are looking at an authority limit, a suppression, an autonomy mode or a spent allowance.
2. If it is an authority limit, do it yourself. A price is set by a person; a suppression is cleared by a person, deliberately.
   - Result: The action carries your name rather than nobody's, which is the point.
3. If it is an autonomy mode or an allowance, change the setting rather than the request.
   - Result: Autonomy resolves at four scopes and the narrowest wins, so one account can be treated differently without changing everything.
4. Check the decision log if you need to show what happened.
   - Result: A refusal is recorded like any other decision, because a refusal is a decision about your business.

## Questions

### Can an administrator grant the Assistant these rights?

No. Pricing and do-not-contact are not permissions with a switch; they are capabilities the Assistant does not have. A person with the right to do either still does it themselves.

### Does this mean the Assistant cannot help with pricing at all?

It can do the reading around a decision — what was quoted before, what the relationship's history holds, what a knowledge source says about your terms — and cite each of them. What it will not do is produce a figure as though it were your business's answer.

### Is a refusal ever a bug?

It can be, in one narrow sense: a customer-only failure where the same request works for an operator is usually a routing or allowlist problem rather than an authority one. If the refusal text names no rule, that is the case to report.

## Related

- [Connect Assistant](https://connectbyjbrh.com/docs/assistant/)
- [Running an action](https://connectbyjbrh.com/docs/assistant/executing-actions/)
- [Separating the agent's authority from the person's](https://connectbyjbrh.com/research/authority-separation/)
- [What Connect may do](https://connectbyjbrh.com/docs/autonomy/)
- [The Assistant refused to do it](https://connectbyjbrh.com/docs/troubleshooting/assistant-refused/)
- [Security and isolation](https://connectbyjbrh.com/docs/security/)
- [The Assistant's tools](https://connectbyjbrh.com/docs/assistant/assistant-tools/)

## What this page is based on

- `docs-source/sources/GENERAL.md` §8 — the Assistant's rights are narrower than a person's
- `docs-source/sources/GENERAL.md` §1 — the two correctly operator-only surfaces
- `docs-source/sources/GENERAL.md` §10 — sealed credentials
- `docs-source/facts.py` — `FORBIDDEN_CLAIMS`, `CAPABILITY_STATUS['suppression_dnc']`
