What is least privilege for an AI agent?

The first guardrail is access. Give the agent only what the current task requires, scoped per tool, and prefer short-lived credentials over standing ones. Okta’s guidance on least privilege for agents frames it as narrowing each grant so that a mistake, or a hijack, cannot reach beyond a small blast radius.^[1] This matters most once an agent holds real tokens through tool use and MCP.

Scoping “per tool” is the part that is easy to skip and expensive to skip. An agent that reads support tickets and one that can also issue refunds are, from a permissions standpoint, two different agents — even if the same model handles both in the same conversation. Bundling read access and write access into one standing grant because it is convenient to set up once means a bug or a successful prompt injection in the read path can reach the write path too. Splitting them so the refund capability is a separate, narrower grant, requested only when actually needed, is what keeps the blast radius of a failure roughly the size of the task that failed, rather than the size of everything the agent could theoretically touch.

Time is the other axis, and it does not substitute for per-tool scoping, it compounds with it. A standing API key that never expires is exposed for as long as it sits in a log, an environment variable, or a config file someone forgot to gitignore — potentially years. A credential minted for one task and set to expire in fifteen minutes limits that same leak to a fifteen-minute window, whether or not anyone notices in time to react. Neither property covers the other’s gap: a narrowly scoped key that never expires is still a standing liability, and a broadly scoped key that expires fast just resets the same wide blast radius on a timer.