# Least Privilege for AI Agents: One Identity, One Scope > Source: > Published: 2026-06-15 01:20:36+00:00 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. 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](https://developer.nylas.com/docs/v3/getting-started/agent-security/) 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. 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. System prompts are guidance; policies are enforcement. For Agent Accounts (currently in beta), [Policies, Rules, and Lists](https://developer.nylas.com/docs/v3/agent-accounts/policies-rules-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. 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. 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. A few sharp edges that show up once you run this in production: `403` from sends as final.`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.`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.`limit_spam_retention_period` must be shorter than `limit_inbox_retention_period` , so spam clears out ahead of the inbox.`is` , `in_list` against a small list) at lower priority numbers than broad `contains` rules, because the first matching `block` is terminal.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.