Least privilege for AI agents: five rules from published security guidance and a real CVE

An AI agent that can read files, call APIs or run code is only as safe as the permissions it holds. Two public sources from this spring make the same point from different angles: joint cybersecurity guidance on adopting agentic AI, and Microsoft's write-up of two vulnerabilities in an agent framework.

What the guidance says

"Careful adoption of agentic AI services," published May 1, 2026, was co-authored by CISA and partner cybersecurity agencies ^[1]. A published summary describes it as having more than 100 recommendations ^[3]. The guidance itself groups agentic AI risks into privilege, design and configuration, behaviour, structural and accountability risks, and says strict adherence to least privilege is a key concern ^[1]. Its recommendations include ^[1]:

• Give each agent its own verifiable identity.

• Never grant broad or unrestricted access, especially to sensitive data or critical systems; limit agent permissions to the minimum scope each task needs and replace long-lived secrets with ephemeral credentials.

• Insert human-in-the-loop approval checkpoints for actions where the cost of error is high.

• Monitor all agent operations, including internal processes, not just inputs and outputs.

• Adopt incrementally, beginning with clearly defined low-risk tasks, and use graduated autonomy.

What it looks like when permissions are too wide

Microsoft's Defender team analyzed Semantic Kernel and disclosed two fixed vulnerabilities, CVE-2026-26030 and CVE-2026-25592 ^[2]. In the second, a .NET SDK file-download function was mistakenly marked as a tool the model could call, so its destination path was effectively controlled by the model. Chained with a code-execution tool, this allowed a script to be written to a Windows Startup folder ^[2]. (The first, CVE-2026-26030, involved the in-memory vector store filter.) The post's conclusion: "Any tool parameter the model can influence must be treated as attacker-controlled input," and "your LLM is not a security boundary" ^[2]. The fix removed the model's access to that function; Microsoft also added path canonicalization and directory allowlisting for programmatic callers as defense in depth, while its primary recommendation was to upgrade ^[2].

Five rules to apply now

1. Inventory every tool an agent can call. If a function should not be model-driven, remove it from the tool list ^[2].

2. Scope credentials to the task. One agent, one identity, the narrowest access, short-lived where possible ^[1].

3. Validate parameters in code. Canonicalize file paths and check them against allowlists rather than relying on the model to behave; Microsoft applied this as defense in depth ^[2].

4. Put a human in front of irreversible actions. The guidance calls for approval checkpoints where the cost of error is high; payments, deletions, external messages and permission changes are our examples ^[1].

5. Monitor beyond the agent's own report. Monitor internal processes, not just inputs and outputs ^[1]; comparing what the agent says it did with system logs is our suggested way to apply this.

Implication for businesses: before expanding an agent's autonomy, list what it can touch and remove everything the current task does not need. Add capabilities one at a time, with approval gates on anything hard to undo.