Permission Primitives: Actions, Resources, and Scope

Permission primitives are the smallest useful building blocks of an authorization model. Before teams debate RBAC, ABAC, or policy engines, they need to answer a simpler question: what exactly is being allowed or denied? A usable authorization decision usually involves at least five pieces:

• a subject, meaning the human or non-human identity trying to act
• an action, meaning what the subject wants to do
• a resource, meaning what the action targets
• a scope, meaning the boundary or extent of the action
• context, meaning the conditions that may influence the result

Without these primitives, access models become vague. A team says a user is an “admin,” but cannot explain whether that means reading dashboards, editing production settings, managing billing, or impersonating other users. Another team says a workload has “API access,” but cannot explain which API, which tenant, or which operations are allowed. That vagueness is where overbroad privilege and brittle policy start.

Why It Matters

Authorization quality depends on clarity. If the system cannot name the action and resource with enough precision, reviewers cannot assess least privilege, logs cannot explain what happened, and policy engineers cannot reason about trade-offs. This is true in cloud control planes, SaaS products, internal admin tools, data platforms, and customer-facing APIs.

Good primitives also make later models easier to compare. RBAC groups primitive permissions into roles. ABAC evaluates primitives through attributes and conditions. Resource-based sharing attaches permissions to the resource itself. But all of those models still rely on a clear underlying statement of what is being done to what.

The diagram below shows the basic shape of an authorization decision.

    flowchart LR
	    A["Subject"] --> B["Action"]
	    B --> C["Resource"]
	    C --> D["Scope and context"]
	    D --> E["Allow, deny, or step-up"]

What to notice:

• the action is separate from the resource because read project and delete project are not the same permission
• scope narrows the action to one tenant, environment, folder, namespace, or object set
• context may change the outcome even when the same subject, action, and resource are involved

Subjects, Actions, and Resources

The subject is the actor. It might be an employee, a customer, a support engineer, a service account, or a workload identity. The action is the verb. Typical actions include read, create, update, delete, approve, deploy, share, or administer. The resource is the target: a document, project, environment, invoice, database, API endpoint, or customer tenant.

These elements sound obvious, but teams often blur them. A role may silently include both read and administrative powers because the action set was never separated. A permission labeled project-access may hide dozens of unrelated capabilities because the resource type was defined loosely.

The stronger design uses verbs and resource types that reflect real operational meaning. That makes policy auditable and easier to decompose.

Scope: Where the Permission Applies

Scope answers “how far does this permission travel?” Common scope boundaries include:

• one customer tenant
• one environment such as development or production
• one project, workspace, or folder
• one region, namespace, or account
• a time-bounded window for temporary access

Scope matters because the same action can be low-risk or high-risk depending on where it applies. read logs for a development app is not the same as read logs across all production systems. share document inside one team workspace is not the same as share document across the whole organization.

Context: Conditions Around the Decision

Context includes conditions that shape the decision without changing the underlying action or resource. Examples include:

• managed device requirement
• time of day or maintenance window
• location or network context
• approval status
• data sensitivity
• recent step-up authentication

Context is useful, but it should not replace clear primitives. “Allowed from the corporate network” is still a weak statement if the action and resource meaning are vague.

Example: A Minimal Permission Schema

The example below shows a small permission model that separates action, resource type, and scope clearly.

 1type Permission = {
 2  action: "read" | "update" | "delete" | "approve";
 3  resourceType: "invoice" | "project" | "dataset";
 4  scope: {
 5    tenantId?: string;
 6    environment?: "dev" | "prod";
 7    resourceId?: string;
 8  };
 9};
10
11type AccessRequest = {
12  subjectId: string;
13  action: Permission["action"];
14  resourceType: Permission["resourceType"];
15  resourceId: string;
16  tenantId?: string;
17  environment?: "dev" | "prod";
18};

Code Walkthrough

This example is small, but it teaches several durable lessons:

• action is explicit rather than buried inside a role name
• resource type is explicit, which helps avoid generic catch-all permissions
• scope is not an afterthought; it is part of the permission shape

That structure makes it easier to build later RBAC or ABAC models without losing precision. It also makes logs and audits more understandable because the system can explain not only that access existed, but what kind of access it was.

Common Modeling Mistakes

• Using labels such as admin or operator without defining the underlying actions.
• Defining resource access without resource boundaries such as tenant, environment, or object.
• Encoding temporary project exceptions into broad permanent permission names.
• Treating context as the whole policy model while leaving verbs and resources underspecified.

Design Review Question

A platform team defines one permission called project-admin that allows reading, editing, sharing, deleting, exporting, and billing changes for every project in every environment. It argues that the name is simple and easy to assign. Is that a strong primitive design?

No. It is a bundle, not a primitive. The stronger design separates the actions and scope so the organization can decide whether a user needs project editing, billing changes, or sharing rights, and whether those rights belong in one environment or across all environments. Simplicity at assignment time should not destroy precision in the model underneath.

Appears on These Certification Paths

SC-900 • cloud IAM fundamentals • application security and authorization design tracks

Continue Learning

This lesson is the base layer for RBAC, ABAC, policy engines, and resource-based access. If actions and scope are still fuzzy, the higher-order models will stay fuzzy too.

Quiz Time