Does least privilege apply only to human users?

No. It also applies to software processes, service accounts, and other components acting within the system.

Is a prompt instruction an access control?

It can guide behavior, but it should not be treated as equivalent to a permission boundary enforced by the connected service.

Can least privilege prevent every harmful action?

No. Harm can occur within permitted capabilities. The principle limits unnecessary authority and works alongside other controls and evaluation.

AI Glossary / Governance, ethics and safety / Beginner

Least privilege

Definition

Least privilege is the security principle of giving a person, account, or software component only the access and capabilities needed for its function. For AI systems, this includes limiting what data an assistant can retrieve and what actions its tools can perform. The aim is sufficient authority for the task without unnecessary power.

What it means

An AI assistant that answers questions about stock levels may need to read inventory records. It does not follow that it should also be able to change prices, delete records, or approve purchases. Each additional capability creates possibilities beyond the assigned task.

Least privilege applies to people and to processes acting on their behalf. A service account used by an AI integration can be overpowered even when ordinary employees have carefully limited access.

The principle does not mean denying everything or making useful work impossible. It means identifying the actual function and granting a narrow set of permissions. As responsibilities change, the necessary permissions may change too, so access needs review rather than being treated as permanent.

How it works

Start by mapping the tasks a component must perform to the resources and operations those tasks require. Distinguish reading from creating, editing, deleting, executing, or administering. Also consider which records, projects, or environments are within scope.

Enforce the boundaries through the systems that control access, such as service permissions and application checks. A written instruction telling a model not to use excessive authority is not equivalent to removing that authority from its tools.

Test both allowed and disallowed actions. Keep permissions tied to identifiable roles or services, review them when work changes, and remove capabilities that are no longer needed. Logs and approvals can support oversight, but they complement rather than replace access restrictions. Least privilege limits the possible consequences of mistakes or compromise; it does not guarantee that all permitted actions are appropriate.

Three practical examples

1. A document-answering assistant receives read access to an approved knowledge collection, while the account used for document maintenance holds separate editing permissions.

2. An AI coding assistant in a test environment can modify a designated project but cannot directly change production settings or access unrelated repositories.

3. A purchasing assistant prepares a draft request using product information, while submission or approval requires an authorized action consistent with the business process.

Think of it this way

Think of giving a visitor a key to the meeting room they need rather than a master key to every room in the building. The smaller key still enables the visit while limiting unrelated access.

The analogy is limited. Digital permissions can distinguish individual operations and records, and services may act through several connected accounts. A seemingly narrow permission can also expose sensitive information. The task is to understand effective access across the workflow, not merely count the keys or permission labels.

Worked example

Consider a fictional assistant assigned to summarize open support tickets in Project A. Its original account can read, edit, and delete tickets in Projects A, B, and C. Treating each project-operation pair as one permission gives 3 × 3 = 9 permissions.

The assigned task requires only reading Project A, so this simplified design needs one permission. Removing the other eight reduces the account's project-operation permissions from nine to one, an 88.9% reduction by this counting method.

That percentage is not an 88.9% reduction in security risk. Permissions differ in consequence, and reading Project A can still reveal sensitive information. The calculation describes the access set.

The team then tests that summarizing authorized tickets works and that attempts to edit Project A or read Project B are rejected by the service. It also checks that another connected tool does not restore the removed access indirectly.

Illustrative case study

Fictional case: Briar Merchants connects an AI assistant to its product catalog. During setup, the integration receives an administrator account because it makes initial testing convenient. The assistant's intended role is to answer staff questions about product availability.

A review identifies that catalog editing and user administration are unnecessary for that role. The team creates a limited service identity, tests required lookups, and verifies that write and administrative operations are denied. A separate process remains responsible for authorized catalog changes.

This case is invented. It illustrates how a temporary setup choice can leave unnecessary authority in a production workflow unless someone explicitly reviews the integration's effective permissions.

Common misconceptions and mistakes

Least privilege is not the same as trusting a model to behave. Even a well-performing assistant can receive misleading inputs or make mistakes. Permission boundaries should continue to apply regardless of how convincing its proposed action appears.

Read-only access is not automatically harmless, because disclosure can be consequential. A small number of broad permissions may also provide more authority than many narrowly scoped ones. Finally, an account's direct permissions are only part of the picture if it can call another service that performs privileged actions on its behalf.

Business use

Businesses should include AI service identities and connected tools in their access reviews. Record what each integration does, which resources it can reach, and who owns the decision to grant or remove access.

Use realistic workflows to distinguish necessary capabilities from permissions retained for convenience. Revisit access after role changes, project closure, and integration updates. Where additional authority is occasionally required, define a controlled route for obtaining it rather than leaving every capability permanently available to the assistant.

Check your understanding

An assistant needs to draft a message but holds permission to send messages to every customer. Does its task alone justify that permission?

Answer: No. Drafting and sending are different capabilities. The workflow should grant only the operations and recipient scope required for its function, with any additional action separately authorized.

Related terms

Access Control
Information security
AI agent
authorisation
service account
role-based access control
separation of duties
tool permissions

Learn next

Next, examine effective permissions for one AI integration. List its required operations, compare them with its access, and test one legitimate action and one action that should be denied.

Sources

NIST SP 800-53 Revision 5, AC-6 and security design principle SA-8(14): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf NIST Computer Security Resource Center, Least Privilege: https://csrc.nist.gov/glossary/term/least_privilege Relevant primary control and definition passages were read. The permission-count illustration and business case are original; the entry does not claim that a permission count measures risk.

Previous: Least-constraining-value Next: Least squares