What are contact rules for AI workers?
Contact rules decide which people an AI worker may read about or contact, applied above app permissions so inbox access does not mean reaching everyone in it.
The app firewall answers "which apps, at what level". Contact rules answer the question underneath it: which people.
Why app-level access is not enough
Grant a worker Write on email and you have said it may send mail. You have not said who to, and for most jobs those are very different permissions.
| The worker | Should be able to email | Should not |
|---|---|---|
| Support Inbox Triager | Customers who wrote in | The exec team a customer mentioned |
| Appointment Reminder Texter | Clients with a booking tomorrow | Anyone else in the address book |
| Invoice Follow-up Assistant | The billing contact on an overdue invoice | That contact's whole company |
Access levels cannot express any row in that table, because both sides are just "send an email". Contact rules can.
What the rules do, in both directions
Reads are filtered. Results exclude restricted contacts, so a worker summarising a mailbox simply does not see the threads it has no business seeing. It is not asked to ignore them; they are not in what it receives.
Sends are refused. A blocked recipient is rejected rather than quietly dropped, and the refusal lands on the run receipt so you can see it happened.
Filtering reads rather than instructing the model to skip them is the important half, and it is worth being precise about why.
| An instruction | A filter | |
|---|---|---|
| Where it lives | In the prompt | In the platform |
| Enforced by | The model's judgement | Code the model cannot reach |
| Under a confusing input | May be talked past | Unaffected |
| If the model is prompt-injected | Compromised | Still holds |
| Evidence it worked | The output looks right | Data never arrived |
A model asked to ignore a thread has, by definition, read the thread. If that thread contains text engineered to redirect it, the instruction is now competing with the attack. Data that never arrives cannot be reasoned around, which is why the filter sits before the model rather than inside its prompt.
The worked case: a reminder texter
Appointment Reminder Texter reaches calendar and messaging to text clients a day-before reminder. It is the sharpest example because every run sends an outbound message to a real person.
The access grant says: calendar Read, messaging Write. Contact rules say: the attendees on tomorrow's bookings, and nobody else. Without the second, a calendar event with a stray attendee, an internal colleague, a vendor, an ex-client whose record was never cleaned up, is a person who receives a text they did not expect.
The failure is not dramatic. It is one confused recipient, repeated quietly at scale, and it is the kind of thing you discover from a complaint rather than from a dashboard.
Where they fit in the safety layer
Three layers, each doing a job the others cannot:
| Layer | Question it answers |
|---|---|
| App firewall | Which apps, and Off, Read or Write? |
| Contact rules | Which people may it see and reach? |
| Redaction | What must never leave, whoever it goes to? |
They compose rather than overlap. A worker can hold Write on email, be barred from the finance team's threads, and still have an account number stripped from the one reply it does send.
The reasonable objection
"An allowlist of contacts is unmaintainable. People join, leave and change roles every week."
True where the rule is a hand-kept list of individuals, which is why that is the wrong shape for most jobs. The rules that survive are ones expressed against something already maintained: the attendees on this booking, the sender of this thread, the billing contact on this record. Those track reality because somebody else is already keeping them current.
Reach for an explicit list when the set is small, stable and high-stakes, which in practice means the block side rather than the allow side: the handful of people a worker must never contact is short and changes rarely.
When contact rules are not the right tool
- The worker sends nothing and reads nothing about people. Engineering Pulse reads repository activity; there is no contact policy to write.
- The concern is content, not audience. If the worry is an account number leaking, that is redaction, and it applies whoever the recipient is.
- The concern is the app, not the people. If a worker should not touch the CRM at all, set that app to Off rather than writing rules about who is in it.
On every plan
Contact rules ship on every plan, Free included, as part of the complete safety layer, and are never tier-gated.
They also apply when a worker is driven from outside over MCP: the tools an external client can see reflect exactly that worker's permissions, and restricted contacts stay excluded there too. The restraint lives with the worker rather than with the caller, which is what stops "drive it over MCP" from being a way around the policy.
FAQ
What are contact rules on an AI worker?
Contact rules are the policy layer deciding which people a worker may read about and contact. Reads are filtered so restricted contacts never reach the model, and sends to blocked recipients are refused outright, with the refusal recorded on the run receipt.
Why not just tell the AI not to email certain people?
Because an instruction is a request the model evaluates against everything else in its context, and a model that has read a thread in order to ignore it is a model that can be redirected by what the thread says. A filter applied before the model cannot be argued with.
Can a worker email anyone in my address book?
Not unless your rules allow it. Write access on email says a worker may send mail; contact rules say who to. Both have to permit a recipient before anything is sent.
Do contact rules apply if I drive a worker over MCP?
Yes. The tools an external client can see reflect that worker's permissions, and restricted contacts remain excluded, because the restraint belongs to the worker rather than to whatever is calling it.
Are contact rules a paid feature?
No. They ship on every plan including Free alongside the app firewall and redaction. The complete safety layer is never tier-gated. See /pricing.