Least privilege, for a loop
Least privilege, for a loop is the practice of giving an agent only the permissions needed for its current observe, decide, tool-call cycle, rather than broad standing access. It turns each possible action into a constrained capability, so a bad prompt, mistaken plan, or injected instruction has limited reach.
Agent permissions are risky because an agent does not make a single isolated request. It keeps reading state, choosing actions, invoking tools, and reacting to tool outputs. If that loop runs with broad credentials, any compromised step can become an access-control failure. A prompt injection in a ticket, a hallucinated command, or an unexpected tool result can steer the agent into using powers unrelated to the task.
In practice, you scope each tool call as if it were a small service account request. Define the resource, allowed action, duration, and acceptable inputs. A ticket summariser might get read-only access to selected tickets. A code-editing agent might get one branch, not organisation administration. A refund workflow might let the agent prepare a request, while a separate approval path performs the irreversible operation.
The common misunderstanding is that least privilege means weakening the agent or merely hiding dangerous tools in the prompt. The real boundary is enforcement. If the runtime still gives the model a powerful token, wording is not a security control. Use scoped credentials, separate identities, allowlisted operations, narrow database grants, sandboxes, expiry, rate limits, and approval gates for actions that are costly to undo.
The trade-off is design and operational overhead. Narrow permissions require more roles, more token flows, clearer task boundaries, and better error handling when an agent lacks access. The honest answer to how narrow they should be is: it depends on impact, reversibility, data sensitivity, and how predictable the task is. High-risk writes deserve stronger isolation than routine reads.
Engineers meet this when connecting agents to MCP servers, internal APIs, databases, file systems, repositories, email, deployment systems, and payment tools. Before wiring a tool, define the permission profile: split read from write, prefer temporary credentials, isolate environments, constrain inputs, log tool use, and add human approval where mistakes matter. The goal is smaller, observable, recoverable failure.
Common questions
- Is hiding a tool from the agent prompt enough?
- No. Prompt text can guide behaviour, but it is not an enforcement boundary. If the agent runtime can still call a tool with broad credentials, a prompt injection, bad plan, or confusing tool result may reach it. Least privilege must be implemented in tokens, service accounts, policy checks, sandboxes, and tool-side authorisation.
- How do I decide the right scope for an agent credential?
- Start from the task, not from the system the agent connects to. List the exact resources it must touch, the actions it must perform, whether writes are necessary, how long access is needed, and what inputs are valid. Then remove anything not required for that loop, especially broad writes and long-lived authority.
- Does least privilege make agents less capable?
- It can make some workflows more explicit, but that is usually the point. The agent can still complete the task if permissions match the task. What changes is that unrelated or irreversible actions require a different credential, a narrower tool, or an approval step. Capability becomes deliberate rather than accidental.