Least-privilege access is the rule that every person, program and automated agent in a system should hold only the permissions needed to do its current job, and nothing more. A reporting analyst can read campaign data but not change budgets; an AI agent built to summarise performance gets read access, not the ability to launch campaigns. The principle exists because every permission is a liability as well as a capability: when an account, a token or a piece of software is compromised or simply makes a mistake, the damage is bounded by what it was allowed to do.

In advertising, the idea governs user access levels in Google Ads and Meta business portfolios, the OAuth scopes granted to third-party tools, the service accounts behind data pipelines and, since 2025, the permissions handed to AI agents that can edit live campaigns.

Where the principle comes from

The canonical statement appears in "The Protection of Information in Computer Systems" by Jerome Saltzer and Michael Schroeder of the Massachusetts Institute of Technology, published in the Proceedings of the IEEE in September 1975. Drawing on work on the Multics time-sharing system, the paper set out eight design principles. Principle (f) reads: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." The authors argued it limits the damage from accidents and errors, and that "the military security rule of 'need-to-know' is an example of this principle."

Two neighbouring principles still frame the debate. Fail-safe defaults bases access on permission rather than exclusion, so anything not granted is denied. Separation of privilege holds that a mechanism requiring two keys is more robust than one, the logic behind dual approval.

The National Institute of Standards and Technology (NIST) carries the idea into its formal vocabulary. Its glossary, drawing on the Committee on National Security Systems instruction CNSSI 4009-2022, defines least privilege as "a security principle that a system should restrict the access privileges of users (or processes acting on behalf of users) to the minimum necessary to accomplish assigned tasks." The phrase "processes acting on behalf of users" matters: the principle was always meant to cover software, not only people.

How it works in practice

NIST turns the principle into an operational control in Special Publication (SP) 800-53, its catalogue of security controls for federal systems. Control AC-6 requires organisations to "employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks." Ten enhancements spell out what that means, including restricting privileged accounts to designated staff (AC-6(5)), requiring administrators to use non-privileged accounts for ordinary work (AC-6(2)), periodic review of privileges (AC-6(7)) and logging every use of privileged functions (AC-6(9)). Six sit in NIST's moderate baseline.

In identity and access management (IAM), the principle is applied in four recurring steps.

  1. Scope the grant. Permissions are defined as narrowly as the system allows: by action (read, edit, delete), by resource (one campaign, one account, one table) and by duration. Amazon Web Services' IAM guidance states it directly: "grant only the permissions required to perform a task."
  2. Separate duties. Sensitive operations such as adding administrators or moving money are split across roles, so no single account can complete them alone.
  3. Limit time. Just-in-time access grants elevated rights for a task and removes them afterwards, replacing standing privileges. Short-lived tokens do the same for software.
  4. Review and remove. Unused accounts and credentials are revoked on a schedule. AWS's IAM Access Analyzer can generate a policy from the actions a role actually uses.

The arithmetic of exposure is simple. An agency running 50 client accounts where every staff member holds Admin rights has 50 accounts at risk if one login is phished. If a junior planner holds Standard access to three assigned clients, the same attack reaches three accounts and cannot add an administrator to any of them.

Who operates it

Platforms decide how fine-grained permissions can be. Google's API exposes Google Ads behind a single OAuth scope, so a read-only reporting tool and a tool that changes bids receive the same grant; the user's role, not the integration, sets the ceiling. X's ads MCP server, launched on August 24, 2026, offers separate ads.read and ads.write scopes, so dropping the write scope yields a read-only agent; campaigns are created paused.

Advertisers and agencies decide who receives which level and when access is withdrawn, which is where the principle most often fails. In March 2026 a former agency that had retained access to a client's Merchant Center account for about six years closed its own account and took the client's with it.

Why it matters for marketers

Ad accounts hold payment methods, customer lists and spending authority. Session hijacking attacks typically end with intruders adding their own administrators, which works only if the hijacked session carries admin rights. Google's decision to require passkeys for sensitive actions from July 15, 2026, including user access changes, adds a check at exactly that point.

The gap between granted and used permissions is wide. Microsoft's 2023 State of Cloud Permissions Risks report, published March 28, 2023, found that "less than 5% of permissions granted are used by workload identities" and that super identities used less than 2% of theirs. Infosecurity Magazine's summary put use across all identities at 1%, out of more than 40,000 grantable permissions. The figures describe cloud infrastructure, where much marketing measurement now runs.

AI agents and the problem of delegated authority

An agent that reads a web page, an email or a product feed can be steered by text hidden in that content, the attack known as prompt injection. Whatever the agent can do, an attacker who controls its input may make it do.

The Open Worldwide Application Security Project (OWASP) names this risk excessive agency in its 2025 Top 10 for large language model applications, attributing it to "excessive functionality; excessive permissions; excessive autonomy." Its mitigation is to "limit the permissions that LLM extensions are granted to other systems to the minimum necessary in order to limit the scope of undesirable actions." Its example is an email assistant tricked into forwarding mail, fixed by a read-only OAuth scope and manual review before sending. A separate OWASP Top 10 for Agentic Applications followed on December 9, 2025.

A 67-page risk profile from UC Berkeley's Center for Long-Term Cybersecurity calls for "enforcing least privilege for tool access" and role-based permissions for the most autonomous systems. The Digital Regulation Cooperation Forum of four UK regulators warned on March 31, 2026 that agents granted broad permissions over sensitive data create expanded attack surfaces.

Practice trails the advice. In Okta's 2026 Customer Identity Trends Report, only 22.4% of organisations building agents gave each one a unique identity with tightly scoped, time-limited credentials. The figures are vendor-published and unaudited.

Limitations and disputes

The principle is easy to state and hard to apply. Most ad platforms offer five or six fixed roles, which forces a choice between a role that is too narrow to do the job and one that is too broad. Teams under deadline pressure tend to pick the second, and permissions accumulate as people change jobs, a pattern security teams call privilege creep.

Granularity has a cost too. An access request process that takes days pushes staff toward shared logins, which defeat the control entirely; Saltzer and Schroeder listed psychological acceptability among their principles for this reason.

Some controls are imposed by platforms in ways users dispute. Since July 2026, Google Ads users have reported that removing another user's access requires a second administrator's approval, a separation-of-privilege rule that leaves single-admin accounts without a documented route. Least privilege also governs only the paths it covers: platform staff with support access sit outside the account's own roles.

For agents, the hardest open question is delegation. When an agent hands work to a sub-agent, standard OAuth has no settled way to pass on a narrower subset of the original grant.

What least-privilege access is not

Role-based access control (RBAC) is a mechanism, not a principle. It groups permissions into roles; least privilege is the test of whether those roles are drawn narrowly enough. A system can use RBAC and still give everyone the Admin role.

Zero trust is an architecture, set out in NIST SP 800-207 in August 2020, in which no request is trusted because of its network location and every access is authenticated and authorised per session. Least privilege is one of its tenets, but zero trust also covers continuous verification and device posture.

Authentication confirms identity through passwords, passkeys or certificates. Least privilege decides what that confirmed identity may do once inside.

Data minimisation under the General Data Protection Regulation (GDPR) limits what personal data is collected. Least privilege limits who can reach data already held.

Recent developments

Google's MCP server for the Google Ads API launched read-only in October 2025. Meta opened write-capable AI connectors for Claude and ChatGPT on April 29, 2026. On August 31, 2026, Google banned programmatic proxies from Ads API access, including hosted MCP servers with shared credentials, and required per-entity authentication.

PubMatic's agent guardrails, announced on August 5, 2026, restrict agents to pre-approved inventory and audiences and halt them for passcode approval when they exceed their authority. The controls are vendor-asserted.

The UK Information Commissioner's Office opened a call for evidence on October 8, 2026 that asks about agent identification, authentication and scoped permissions, with responses due by November 20, 2026. On October 27, 2026, NIST researchers published ten design tenets for agent identity management, including delegation with attenuated permissions and short-lived, revocable authorisation.

Timeline

  • October 1973 - Saltzer presents protection work on Multics at the Fourth ACM Symposium on Operating System Principles
  • September 1975 - Saltzer and Schroeder publish "The Protection of Information in Computer Systems" in the Proceedings of the IEEE, defining least privilege
  • August 2020 - NIST publishes SP 800-207, Zero Trust Architecture
  • September 2020 - NIST publishes SP 800-53 Revision 5, including control AC-6 and ten enhancements
  • March 28, 2023 - Microsoft publishes its 2023 State of Cloud Permissions Risks report
  • 2025 - OWASP lists excessive agency as LLM06 in its Top 10 for LLM applications
  • October 7, 2025 - Google announces a read-only open-source MCP server for the Google Ads API
  • December 9, 2025 - OWASP publishes its Top 10 for Agentic Applications
  • February 15, 2026 - UC Berkeley's agentic AI risk profile calls for least privilege in tool access
  • March 2026 - Google warns Cloud customers about exposed service account and API keys
  • March 31, 2026 - UK Digital Regulation Cooperation Forum publishes its agentic AI paper
  • April 29, 2026 - Meta opens write-capable AI connectors for its ad system
  • July 15, 2026 - Google Ads requires passkeys for sensitive actions, including access changes
  • August 5, 2026 - PubMatic announces guardrails restricting agent transactions
  • August 24, 2026 - X launches its ads MCP server with separate read and write scopes
  • August 31, 2026 - Google bans programmatic proxies, including shared MCP servers, from Ads API access
  • October 8, 2026 - UK ICO opens its call for evidence on agentic AI
  • October 27, 2026 - NIST researchers publish design tenets for agent identity management
  • November 20, 2026 - ICO call for evidence closes

Summary

Who: Jerome Saltzer and Michael Schroeder formulated the principle; NIST codified it in SP 800-53; cloud providers, ad platforms such as Google, Meta and X, agencies, advertisers and AI agent builders apply it, while OWASP, UK regulators and NIST researchers now extend it to agents.

What: A security principle requiring that every user, program and agent hold only the minimum permissions needed for its assigned task, for no longer than necessary.

When: Published in September 1975, formalised in NIST control AC-6, restated in NIST SP 800-53 Revision 5 in September 2020, and applied to AI agents through 2025 and 2026.

Where: In operating systems, cloud IAM, ad platform user roles, API OAuth scopes, service accounts and the MCP servers that connect AI agents to ad accounts.

Why: Because compromised accounts, stolen tokens, manipulated agents and simple mistakes can do only as much damage as their permissions allow.