Role-based access control (RBAC) is a method of deciding what people can do inside a software system by attaching permissions to roles, such as administrator, analyst or billing contact, and then assigning people to those roles. Nobody receives permissions directly. A user inherits whatever the role allows, and loses it when removed from the role. The model exists because managing permissions person by person becomes unworkable once an organisation has hundreds of staff, contractors and agencies touching the same systems. Grouping rights around job functions makes them easier to grant, review and revoke.

In advertising, RBAC is the logic behind the access levels in a Google Ads account, the roles in a Google Analytics property and the user types in a demand-side platform (DSP). It governs who can change a budget, who can see cost data and who can add or remove other users.

How the model works

The formal model, standardised by the American National Standards Institute (ANSI) in 2004, rests on four elements: users, roles, permissions and sessions. A permission is an approved operation on an object, such as "edit" on a campaign or "view" on a revenue report. Permissions are assigned to roles, users are assigned to roles, and a session is the period during which a user activates one or more of those roles.

According to the National Institute of Standards and Technology (NIST), the standard is split into four components. Core RBAC covers the minimum: user-role and permission-role assignments and role activation within a session. Hierarchical RBAC adds inheritance, so a senior role automatically includes the rights of junior ones. Static separation of duty prevents one person from being assigned two conflicting roles, while dynamic separation of duty prevents conflicting roles from being active in the same session.

A worked example shows the effect. An agency with 40 staff and 120 client accounts could, in theory, manage 4,800 individual permission settings. With five roles, the administrator assigns each person a role per account group and maintains five definitions. When a planner leaves, one removal ends every right that person held.

Where it sits in advertising platforms

Ad platforms rarely use the term, but their access systems follow the pattern, usually with a fixed set of hierarchical roles.

Google Ads uses five access levels. According to Google's help centre, Email-only users receive notifications and reports; Read-only users can view campaigns and run reports; Billing users manage payments; Standard users can edit campaigns; and Admin users can do all of that plus give account access, change access levels, accept or reject manager account link requests and unlink managers. Google recommends that each account has more than one Admin.

Google Analytics 4 defines six roles at account and property level: Administrator, Editor, Marketer, Analyst, Viewer and None. According to Google's documentation, roles pass down from account to property, the most permissive role applies when a user holds several, and two data restrictions, No Cost Metrics and No Revenue Metrics, can be layered on top. Restricted values appear as zero in reports and API responses. An inherited restriction cannot be removed at property level.

Display & Video 360 (DV360) organises roles into families. According to Google's help centre, the standard family includes Admin (partner level only), Standard, Read only, Reporting only and Planner, while separate families cover creative staff and clients. A user's roles must come from one family, and only Admin, Standard and Read only users can call the Display & Video API. The Partner client role hides billable cost and platform fees, a design aimed at agencies that give clients a view of the platform without exposing their margins.

Google's Merchant Center for Agencies, documented in June 2026, adds a cap: an agency user's access to a client account can never exceed the agency's own access to it. Amazon Ads introduced custom access controls in April 2021, with admin and editor levels alongside narrower options for billing, Stores building and Posts.

Origin and evolution

Before RBAC, two models dominated. The US Department of Defense's Trusted Computer System Evaluation Criteria, the "Orange Book" issued in December 1985, defined discretionary access control (DAC), where owners grant access to their own resources, and mandatory access control (MAC), where a central authority enforces clearance levels. Neither fitted commercial organisations, where access followed job functions rather than ownership or classification.

In 1992 David Ferraiolo and Richard Kuhn of NIST proposed a general-purpose RBAC model as an alternative to both. In 1996 Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman published a modular family of models, RBAC0 to RBAC3, separating the base model from hierarchies and constraints. NIST proposed unifying the two strands in 2000, and ANSI and the International Committee for Information Technology Standards (INCITS) adopted the result as INCITS 359-2004 on February 11, 2004. The standard was revised in 2012.

An economic study by RTI International, published in December 2010, estimated that RBAC had generated $6.1 billion in net benefits to industry in 2009 dollars, of which $1.1 billion was attributed to NIST's work, according to NIST. By the end of 2010, more than half of IT users at organisations with over 500 employees had at least some permissions managed through roles.

Why it matters for marketers

Ad accounts hold payment methods, customer lists and spending histories, which makes the role structure a commercial control as well as a security one. The agency model depends on it. An agency typically holds Admin or Standard rights through a manager account, while the client retains ownership and can revoke access. Since November 2024, Google has been able to penalise or suspend agencies whose handling of client accounts breaches its third-party policy.

When those structures are not maintained, the consequences are concrete. In March 2026, a former agency that had kept access to a client's Merchant Center account for about six years closed its own account and took the client's with it, deleting feeds, rules and links to Google Ads and Analytics. Google restored it within 24 hours. Ad account theft follows similar lines: session hijacking attacks typically end with intruders adding their own administrators and demoting the owner, and fake client leads have targeted agencies seeking manager account links.

Limitations and disputes

The most common criticism is role explosion. Fixed roles rarely map cleanly onto real jobs, so organisations either create many custom roles or grant broader roles than needed. Most ad platforms offer only five or six predefined roles, which pushes users toward the second outcome. The Open Worldwide Application Security Project (OWASP) ranks broken access control first in its 2025 Top 10, saying every application it tested showed some form of the weakness.

Roles are also only as strong as the paths around them. Google's API exposes Google Ads behind a single OAuth scope, so a read-only reporting tool receives the same permission as one that changes budgets; the user's role, not the integration, sets the limit. In 2024 agencies reported Google representatives making changes to client accounts without authorisation, and in February 2026 a clause in Google's support form was found authorising specialists to make changes directly. Neither depends on the account's own user roles.

AI agents add a further question. Meta has not said whether role-based controls apply when its Muse agent connects to ad accounts, and Adform's statement that assistants can reach more than 800 platform capabilities did not describe what permissions they inherit.

What role-based access control is not

Attribute-based access control (ABAC), defined by NIST in Special Publication 800-162 in January 2014, decides each request by evaluating attributes of the user, the resource, the action and sometimes the environment, such as time or location, against policies. RBAC asks which role a user holds; ABAC can ask whether a user in the UK may edit a German campaign during office hours. Many systems combine the two.

Discretionary access control lets the owner of a resource decide who else may use it, as when a person shares a spreadsheet. Ad platforms mix this in when one business grants access to another, though the rights granted remain roles.

Least-privilege access is a principle rather than a mechanism. It says each user, program or agent should hold only the permissions a task needs. RBAC is one way of applying it, and one way of breaking it: an agency that gives every employee Admin on every client account is using roles while ignoring least privilege.

Authentication is separate. Passwords, passkeys and two-step verification confirm identity. RBAC decides what that confirmed identity may do.

Recent developments

Google has tightened access management in Google Ads through 2026. From July 15, passkeys became mandatory for sensitive actions, including user access changes and account linking. Around the same time, users reported that removing another user's access now requires a second administrator's approval, a form of separation of duty, with no documented route for accounts that have only one admin. Pending requests expire after 20 days.

On August 14, 2026, Google stated that one Merchant Center agency account can link up to 1,000 client accounts. On September 10, Google moved Google Ads API access levels from developer tokens to Google Cloud projects, placing API permissions inside Cloud's own role system, where owner and editor roles now receive mandatory service announcements. On September 18, the Marketing Platform Admin API, first introduced in March 2024, gained 14 methods for user groups and access bindings, allowing roles to be granted to groups rather than individuals. The API remains in alpha.

For agents, the pattern is converging on narrow scopes. X's ads server, launched August 24, 2026, limits each application and user pair to one OAuth grant, while Meta's AI connectors support writes. A February 2026 UC Berkeley profile on agentic AI called for role-based permission management and least privilege for the most autonomous systems.

Timeline

  • December 26, 1985 - US Department of Defense publishes the Trusted Computer System Evaluation Criteria, defining DAC and MAC
  • October 1992 - David Ferraiolo and Richard Kuhn of NIST propose a general RBAC model
  • February 1996 - Sandhu, Coyne, Feinstein and Youman publish the RBAC0 to RBAC3 model family
  • 2000 - NIST proposes a unified RBAC standard
  • February 11, 2004 - ANSI/INCITS adopts the NIST model as INCITS 359-2004
  • December 2010 - RTI International estimates $6.1 billion in net economic benefits from RBAC
  • 2012 - Standard revised as INCITS 359-2012
  • January 2014 - NIST publishes SP 800-162 on attribute-based access control
  • April 22, 2021 - Amazon Ads introduces custom access controls in its console
  • March 2024 - Google releases the Marketing Platform Admin API in alpha
  • October 2024 - Google tightens third-party policy for agencies managing client accounts
  • February 15, 2026 - UC Berkeley publishes its agentic AI risk profile
  • March 6, 2026 - A former agency's account closure wipes a client's Merchant Center account
  • March 11, 2026 - Merchant Center for Agencies launches in the US and Canada
  • June 26, 2026 - Google publishes the Merchant Center for Agencies user access guide
  • July 14, 2026 - Second-admin approval for Google Ads access removals is reported
  • July 15, 2026 - Google Ads requires passkeys for sensitive actions
  • August 14, 2026 - Google documents the 1,000-account limit for agency Merchant Center accounts
  • August 24, 2026 - X launches an ads server limiting one OAuth grant per application and user
  • September 10, 2026 - Google Ads API access levels move from developer tokens to Google Cloud projects
  • September 18, 2026 - Google adds 14 user group and access binding methods to its admin API
  • September 29, 2026 - Meta extends its Muse agent to small business ad accounts

Summary

Who: NIST researchers David Ferraiolo and Richard Kuhn proposed the model, ANSI/INCITS standardised it, and platforms including Google, Amazon and Meta apply it to advertisers, agencies and, increasingly, AI agents.

What: An access control model in which permissions are attached to roles and users gain rights only by being assigned to those roles.

When: Proposed in 1992, standardised as INCITS 359-2004 in February 2004, revised in 2012, and tightened across ad platforms through 2026 with passkeys and second-admin approvals.

Where: In enterprise software generally, and in advertising in Google Ads access levels, Google Analytics roles, DV360 user roles, Merchant Center for Agencies and Amazon Ads console permissions.

Why: To make permissions manageable at scale by tying them to job functions, so access can be granted, audited and revoked without configuring each person individually.