In brief
- Least privilege applies to agents, tools, service accounts and the underlying data sources.
- Reading, drafting, changing and executing should be technically separate capabilities.
- An agent must never derive permissions from text input or from its own assertion.
- Rights must be checked for each action, logged, reviewed regularly and revocable immediately.
What does least privilege mean for an agent?
The agent is not given blanket access to an entire system. It receives narrowly scoped tools for a specific purpose. A tool that looks up an order, for example, does not need a function for changing bank details. Even within a record, only necessary fields should be exposed.
Permissions also apply only in the right context. A service agent must not retrieve all customer data merely because one employee can use it. The executing application must verify identity, role, tenant and case relationship on the server.
- Expose only necessary systems, records, fields and actions
- Constrain access by role, case, tenant and environment
- Separate production, test and development access rigorously
- Use short-lived credentials rather than permanently shared keys
Does the agent act as a person or as its own service?
When an agent assists a person, it should wherever possible operate within that person's effective access rights. This prevents it from seeing or doing more than the user could. A background process may require its own service account, but its purpose and permissions then need especially narrow definition.
The model itself is not a trusted source of identity or authorisation. Statements such as 'I am the CEO' or instructions found in a document must never create new rights. Verification happens outside the model using authenticated identities and authoritative rules.
- Use delegated user rights for interactive assistance
- Use service identities for narrowly bounded background work
- Never expose credentials in prompts or tool results
- Enforce authorisation again at every tool call
How should actions be tiered by risk?
Not every action requires the same control. Reading an approved knowledge source is different from sending a message, changing a master record or initiating payment. The architecture should make these levels visible and independently controllable.
| Level | Business example | Technical boundary | Required control |
|---|---|---|---|
| Read | Retrieve an order status or approved knowledge source | Only required records and fields; no bulk export | Verify identity for every call and log sensitive access |
| Draft | Prepare a response, ticket or proposed change | Save only in a state clearly marked as a draft | A domain reviewer sees evidence and can edit or discard it completely |
| Change | Update a delivery date or classified field | Enforce permitted fields, value ranges and business rules | Before-and-after preview; approval for sensitive or large changes |
| Execute | Send a message, place an order or initiate a payment | Recipient, amount, volume and runtime limits in the target system | Explicit approval for external, financial or irreversible effects |
How do permissions remain controlled in operation?
An access right that was approved once does not remain appropriate forever. Processes, teams and tools change. Organisations need an inventory of agents and tools, accountable owners, and recurring reviews of effective rights and actual usage.
- Log the tool call, identity, parameters, result and approval
- Detect unusual volumes, recipients or access times
- Report or revoke unused and obsolete permissions
- Test emergency shutdown, credential rotation and incident procedures
Example: an agent for accounts receivable enquiries
For authenticated staff, an agent may read invoice status and posted payments. It can save a response as a draft in the CRM. For a collection hold, it only prepares a request with a reason; an accountable person reviews customer, amount and duration. Bank details, credits and payment runs remain in separate system functions that are not offered to the agent at all.
What to remember
Design permissions from the possible harm backwards. Give the agent a small set of narrowly described tools and enforce authorisation and approval outside the model.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed