Least Privilege for AI Agents: One Identity, One Scope

A team ships a support triage agent on a Friday. It works beautifully for two weeks — reads inbound mail, drafts replies, files tickets. Then a prompt regression slips through a deploy, the agent misclassifies a thread, and it starts replying to everything in sight. Nobody notices for hours because the agent's credential was the same one the whole platform used, its mailbox was shared with three other bots, and there was no per-agent quota to trip. The postmortem's first line: we couldn't tell which agent did what, and nothing was in place to stop any of them.

That's not an LLM problem. It's an access-control problem, and the fix is the oldest idea in security: least privilege — one identity, one scope, one quota per agent.

The pattern behind the incident

Agent fleets tend to grow from a single proof of concept, and the proof of concept's shortcuts harden into architecture: one API key with full access, one mailbox several agents share, capability boundaries that exist only in system prompts. Each shortcut widens the blast radius. The Nylas security guide for AI agents is blunt about the first one — an API key grants full access to all connected accounts, so treat it like a database root password and keep it in a secrets manager, never in code or any prompt context that could be logged.

The mailbox shortcut is subtler. Every Nylas API call is scoped to a grant, and an agent can only touch data for grants it holds an ID for. That scoping is free isolation — but only if each agent gets its own grant. Share one and you've merged every agent's read access, send history, and failure modes into a single pool.

Match access to the job

Before provisioning anything, write down what each agent actually does, then grant exactly that:

If the agent...	It needs...
Summarizes an inbox	Read email only — no send, no delete
Schedules meetings	Read calendar, create events — no email access
Drafts replies for review	Create drafts only — a human hits send
Acts as a full assistant	Read/write — with send confirmation

Enforce this at two layers: the system prompt (which sets intent but can be subverted) and the tool surface (which can't). If you're using MCP, enable only the tools the agent needs — a summarizer with no send tool can't be prompt-injected into sending.

Enforce limits with policies, not promises

System prompts are guidance; policies are enforcement. For Agent Accounts (currently in beta), Policies, Rules, and Lists move the boundary out of the model's hands entirely. A policy bundles limits — daily send quotas, storage caps, attachment size and count, retention windows — plus spam detection with a spam_sensitivity dial that runs from 0.1 to 5.0. Every limit is optional and defaults to your plan's maximum, so you only specify where you want to be stricter:

curl --request POST \
  --url "https://api.us.nylas.com/v3/policies" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Prototype agents - tight limits",
    "limits": {
      "limit_attachment_size_limit": 26214400,
      "limit_attachment_count_limit": 20,
      "limit_inbox_retention_period": 365,
      "limit_spam_retention_period": 30
    },
    "spam_detection": {
      "use_list_dnsbl": true,
      "use_header_anomaly_detection": true,
      "spam_sensitivity": 1.5
    }
  }'

Rules add directional control. An outbound block rule rejects a send with HTTP 403 before it ever reaches the email provider — useful for data-loss prevention, catching test domains that slipped into production, or keeping an agent from emailing anyone outside an approved list. Here's the DLP version, blocking any send to a domain the agent has no business writing to:

curl --request POST \
  --url "https://api.us.nylas.com/v3/rules" \
  --header "Authorization: Bearer $NYLAS_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Block outbound to example.net",
    "trigger": "outbound",
    "match": {
      "conditions": [
        { "field": "recipient.domain", "operator": "is", "value": "example.net" }
      ]
    },
    "actions": [
      { "type": "block" }
    ]
  }'

A detail that matters for least privilege: recipient.* conditions match against any recipient — To, CC, BCC, and SMTP envelope recipients. An agent can't smuggle a message past the rule by BCCing the forbidden address.

Rules run in priority order (0–1000, lower first), and block is terminal — it can't be combined with other actions. Evaluation fails closed: if a block rule can't be evaluated because of a transient infrastructure error (say, a list lookup fails during in_list matching), the message is blocked rather than let through. Fail-closed blocks surface as retryable errors — 503 on an API send, a 451 tempfail on inbound SMTP — so legitimate traffic retries instead of silently disappearing.

Verify the boundary actually fired

Least privilege you can't observe is least privilege you can't trust. Every time the rule engine evaluates an inbound message or outbound send for an Agent Account, Nylas records an audit entry you can pull per grant:

curl --request GET \
  --url "https://api.us.nylas.com/v3/grants/$GRANT_ID/rule-evaluations?limit=50" \
  --header "Authorization: Bearer $NYLAS_API_KEY"

Each record shows the evaluation stage (smtp_rcpt, inbox_processing, or outbound_send), the normalized sender and recipient data that was considered, which rules matched, and which actions applied. A blocked_by_evaluation_error: true flag distinguishes a fail-closed infrastructure block from a genuine rule match — so when the support agent's send bounces with 403, you can answer "which boundary stopped it, and was it supposed to?" in one API call.

One workspace per agent archetype

Policies and rules attach to workspaces, and every account in a workspace inherits them. The least-privilege move is to group agents by archetype rather than dumping everything in one place: a sales-outreach agent and a support-triage agent have different send limits and spam tolerances, so give each group its own workspace with its own policy. Stricter caps on prototype accounts, higher quotas on the production sales agent — without one catch-all configuration that's too loose for half your fleet.

Things to watch for

A few sharp edges that show up once you run this in production:

• Handle 403 from sends as final. When an outbound block rule fires, no sent copy is stored and no retry will deliver the message. Treat it like any other delivery failure in your agent's error handling, then check the rule-evaluations endpoint to see which rule matched.
• Rules have hard caps. 50 conditions per rule, 20 actions per rule, 10 lists per in_list condition, and 500 characters per condition value. Requests beyond any of these are rejected with a validation error — design around lists rather than giant inline condition sets.
• Set both retention values, in the right order. limit_spam_retention_period must be shorter than limit_inbox_retention_period, so spam clears out ahead of the inbox.
• Order matters. Put specific rules (is, in_list against a small list) at lower priority numbers than broad contains rules, because the first matching block is terminal.
• Without any policy, accounts run at plan maximums. On the free plan that still means a ceiling of 200 messages per account per day — but "plan maximum" is rarely the right quota for a prototype.

Start narrower than feels necessary

You can always raise a quota; you can't retroactively shrink an incident. A reasonable default posture for a new agent: its own account, read-plus-draft access only, a workspace policy with deliberately low limits, and an outbound block rule scoping who it can write to. Loosen each constraint only when the agent demonstrably needs it.

Worth an hour this week: pick your most autonomous agent and ask what the worst case looks like if its credential leaks today. If the answer involves any data or send capability beyond that one agent's job, you've got your scoping backlog.

Comments

[ANP2 Network]

The opening incident quietly undercuts the headline control. A misclassification "replying to everything in sight" does its damage in the first handful of sends — to the wrong recipients — long before a daily quota trips. Quotas bound a runaway loop (volume); they don't bound a targeted misfire (one send leaks the thread). Different threats, bundled here under "limits." The thing that actually stops your own story is the recipient allowlist rule, which shows up as a DLP afterthought. For agents that send, the allowlist is load-bearing and the quota is the backstop — not the reverse.

Second gap: least privilege scopes the agent's standing grant, not the transitive capability reachable through the tools it may call. A read-only summarizer that can invoke one downstream automation holding its own send credential still has "send" in its reachable closure — the confused-deputy path. Blast radius is the closure over the call graph, not the single grant.

And the part that worries me most: the incident began as a deploy regression. If policies and rules ship through the same pipeline as the prompt and tool config, a bad Friday can loosen the boundary the same way it loosened the classifier. "Policies, not prompts" only holds if the enforcement lives in a change-control domain the agent's own deploy can't reach — otherwise the mechanism is real, but it sits inside its own blast radius.