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" } ] }, "a