Step 6 — The Permission Layers

Step 6 · Permissions

This is the step people skip because it feels like ceremony. It is the step that decides whether you have an assistant or a liability. Do it before the agent has anything powerful.

Permission is five layers, not one switch

People imagine the agent either has access or does not. There are five independent layers, and I want all five.

Layer	The question it answers	My decision
1 · Who can reach it	Which people may talk to the agent at all	Household members only. Everyone else is ignored
2 · Which identity answers	Which context a message lands in	A family member’s question is handled by a different agent than mine
3 · Which tools that context may use	What it can do here	The family context cannot touch mail or files
4 · Which commands may run	What may execute, and what asks first	A fixed list. Anything outside it asks a person
5 · Which data is in scope	Which calendars, lists and folders	Shared calendars only. Work and personal are out of bounds

Layers 3 and 5 do the heavy lifting. Layer 4 is the one people do not expect, and it is the most valuable.

Do this

1. Decide who may talk to it. An explicit list. Everyone else is refused, not ignored quietly.
2. Decide what each person may reach. Write it as a table. Family members get shared calendars, lists and search. They do not get mail, files, or anything administrative.
3. Write the command allowlist. The small set of things the agent may do freely, and a rule that everything else asks a person first.
4. Set the data scope per context. Which calendars, which lists. Not “all of them by default”.
5. Turn on approval forwarding, so a request reaches your phone rather than sitting on the machine.
6. Test it before you trust it. Details below.

Different people, different permissions

The most useful decision I made was to stop treating the household as one user.

  Me      ──>  full access        mail, files, everything the job needs

  Family  ──>  restricted         shared calendars, lists, reminders, search
                                  no mail  ·  no files  ·  no commands

  Groups  ──>  restricted         the same, and only when addressed by name

Three consequences that matter:

• A child cannot reach the private things, because the agent they are talking to has never had access. Not “is told not to share” — does not have.
• My context stays the powerful one. That is where mail and administrative work happen.
• In a group chat it waits to be addressed. Without this it becomes the participant who replies to everything.

“Is told not to” and “cannot” are very different guarantees. Prefer the second every time. Instructions can be argued with; missing access cannot.

Three tiers, not two

A strict allowlist has an obvious failure: the agent hits something legitimate and simply cannot proceed. The pattern that works is approval rather than refusal.

Tier	Behaviour	Example
Just does it	Everyday, reversible work	Adding to a shared list
Asks first	Outside its usual scope	A change it has not made before
Never	Cannot, at any tier	Anything in The Rules It Cannot Break

Test it, do not assume it

A rule you have never tested is an assumption. On purpose, ask the agent to do each of these and confirm it declines:

• Read mail from a context that should not have mail access
• Do something outside its allowlist without asking
• Take an action on the “never” list

Do this at a convenient moment rather than discovering it during an incident. The first time mine refused something it should have refused, my confidence in it went up sharply.

Revocation is the point

• One credential, one capability. If withdrawing one thing disables three others, they were not separated properly.
• Test the withdrawal deliberately. Once a year, remove something and confirm the failure is graceful — a clear message, not silence.
• Keep the written map. Capability to credential, one table.

The uncomfortable trade-off

Least privilege costs convenience, and you will feel it. The agent will ask permission for something you would have allowed without thinking, and you will be tempted to widen access so it stops asking.

Do not do that during a busy week. That is exactly when judgement is worst.

Widen only when something has been genuinely blocked, for a real reason, in daylight, with the decision written down.

Checkpoint

• A restricted person cannot reach private data — proven, not assumed
• Everything outside the allowlist asks a person first
• You have tested the “never” list and it holds
• Each capability has its own credential
• The capability-to-credential map exists and is current

Next

The Rules It Cannot Break.