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.
