Deciding what each agent is allowed to see

The interesting security question about an email agent is not whether someone can break in. It is what the agent can reach on an ordinary Tuesday, because that is the set an attacker inherits if they ever succeed, and it is the set a confused model can wander into without anyone attacking at all.

2 August 2026 · 5 min read

Two different permission systems#

People and agents are governed separately, and conflating them is where designs go wrong.

Humans have workspace roles. Owner, admin, and member, ranked, so a check reads as "at least admin" rather than a list. The owner is also the billing owner and the subject of account erasure. Roles decide who can create agents, issue keys, add domains, and change what agents may reach.

Agents have identity scope plus grants. An agent is not a member with a role. It is an identity, and a key belongs to exactly one identity. What it can reach is its own mailbox, plus whatever was explicitly granted: other identities, notes, vault secrets.

The practical consequence: promoting a colleague to admin does not widen any agent's reach, and granting an agent a secret does not give anyone new access to the dashboard. Those are the right independent axes.

What an agent gets by default#

Its own mailbox, and nothing else. Not the other agents' mail, not every note, not the vault.

That default matters more than any individual grant, because it means every widening is a decision someone made rather than something that accumulated. When you audit an agent later, the question is never "what does this reach", it is "what did we deliberately give it", which is a much shorter list.

Notes and secrets being per-item rather than per-category is the useful part. An agent that needs one credential gets one credential, and an agent without a grant cannot see that the secret exists at all, which means an injected instruction to "use the production database password" has nothing to name.

Designing the smallest useful agent#

Work backwards from the job rather than forwards from the catalogue.

1. List what this agent must do this week. Not this quarter. Grants are cheap to add later and expensive to notice.
2. For each task, name the resource it needs. A support agent needs its mailbox and the contact book. It probably does not need a vault secret, and it certainly does not need the recruiting inbox.
3. Ask what the worst message it could send is, using only that list. If the answer is uncomfortable, remove something rather than adding a prompt rule.
4. Write down who owns the agent, because grants without an owner drift.

The check in step three is the whole method, and it is the same one a reviewer will apply, per the security review questions an email agent should survive.

Cross-agent access, and when it is worth it#

Identity grants let one agent read another's mail. It is occasionally right: a supervisor agent summarising the week, or a shared inbox two agents genuinely both work.

It is usually not right, and the failure is quiet. An agent that can read another's mail can quote it, which means a customer conversation can surface in a recruiting thread through nothing worse than helpfulness. Where you do grant it, grant it in one direction and write down why.

Contacts are the deliberate exception: they are a workspace resource on purpose, because the point of shared memory is that what one agent learns another can use. The boundary to hold there is what belongs in a contact record at all, per giving an email agent memory.

The vault is where the blast radius lives#

Everything else an agent holds is correspondence. Vault secrets are access to other systems, which makes them the one grant worth being slow about.

Grant per agent and per secret. Prefer a credential scoped to the thing the agent does over a shared admin login, because a leaked agent key exposes whatever that agent could open. And use get_totp_code rather than storing a second factor somewhere convenient, so signing in does not require a human relaying digits into a chat window, per login codes, 2FA, and verification email.

Reviewing grants without it becoming a chore#

Quarterly is often enough, and it takes twenty minutes if you keep the list short.

• Every agent still running, with a named owner.
• Every identity grant, with the direction and the reason.
• Every note and vault grant, traced to a current task.
• Any agent whose job changed since the grants were set.

That last one produces most of the removals. An agent that took on a new category last month usually kept the grants from the old one, and an agent that lost a category almost never had them taken away.

When something is wrong, the remedy is per-agent and immediate: revoke the key, remove the grant, or both, without touching anything else. That property is the reason for one identity per agent in the first place, argued in keys, scope, and what to do the day one leaks.

Questions#

How do permissions work for AI email agents?

Two systems. Humans hold workspace roles (owner, admin, member) that decide who can administer things. Agents hold an identity, and a key belongs to one identity, with access widened only by explicit grants for other identities, notes, and vault secrets.

What can an agent see by default?

Its own mailbox and threads, plus the shared workspace contact book. Not other agents' mail, not notes, not vault secrets.

Can one agent read another agent's inbox?

Only with an identity grant, and it is usually the wrong call. An agent that can read another's mail can quote it into the wrong conversation without anyone attacking anything.

How granular are secret grants?

Per secret, per agent. An agent without a grant cannot see that the secret exists, so an injected instruction naming it has nothing to attach to.

Does making someone an admin change what agents can do?

No. Human roles and agent scope are independent axes, which is what keeps a personnel change from quietly widening an agent's reach.

How often should grants be reviewed?

Quarterly, checking that every agent has an owner and every grant traces to a current task. Most removals come from agents whose job changed after the grants were set.