Subject-Object-Verb Access Model

How the subject-object-verb pattern works

The subject-object-verb pattern is a plain-language way to express access decisions. It names the actor first, the protected thing second, and the permitted action third, which makes the policy easier to read, review and compare across systems.

That structure is especially useful when access is expressed in policy, logs or design documents. It separates who is acting from what is being reached and what operation is allowed, so reviewers can spot overbroad permissions or ambiguous wording faster.

Why this model matters for authorization

At its core, the model describes authorization rather than authentication. It helps practitioners reason about whether a given subject, including a human user or a non-human identity, should be allowed to read, write, execute or perform another operation on a specific object.

Because the three parts are explicit, the model supports least privilege and cleaner policy review. A policy that can be stated clearly in subject-object-verb form is easier to audit than one buried in informal prose or mixed with unrelated business logic.

It also aligns naturally with how many access control systems are evaluated in practice: the decision is not just whether an identity exists, but whether that identity may perform a particular verb on a particular resource under defined conditions.

Where the model is useful in practice

This pattern shows up in access requests, policy engines, permission reviews and incident investigations. It is a helpful shorthand for discussing whether a rule grants the right action to the right actor on the right asset.

It is also useful when different teams describe the same control in different language. Security, platform and application teams can all map their own terminology back to the same three elements, which reduces confusion when reviewing entitlements or designing new controls.

For readers working on authorisation design, the model pairs well with formal access control thinking. NHIMG’s Authorisation Models Guide shows how those policy choices are implemented in RBAC, ABAC, ReBAC and policy-based access control.

Common failure modes and interpretation issues

The biggest weakness is ambiguity when any one of the three terms is vague. If the subject is not clearly identified, the object is overloaded, or the verb is too broad, the policy can hide excessive access or make it difficult to prove what was actually allowed.

Another common problem is assuming that a cleanly written policy is automatically a secure one. A subject-object-verb statement can still describe a dangerous entitlement if the subject is overprivileged, the object is sensitive, or the verb is broader than the business task requires.

In identity-heavy environments, the model also needs careful population handling. The same pattern applies to people, services, workloads and agents, but the review questions differ depending on who or what is acting and how the access is issued and revoked.

Risk and Threat Considerations

Clear wording reduces policy confusion, but it does not prevent excessive access on its own. If the subject, object or verb is mis-specified, an attacker or insider may gain broader reach than intended, and reviewers may miss the exposure during entitlement checks.

Failure mechanism: Ambiguous or overly broad subject-object-verb statements can mask privilege creep, misrouted access grants or unsafe assumptions about who may act on which resource.

Impact: The result can be unauthorized access, unintended writes or execution, harder auditability and a larger blast radius if an account or service credential is compromised.

Practitioner Guidance

Why practitioners should care: Use the subject-object-verb form when you need a fast, durable way to review whether an access rule is specific enough to be safe. It is especially helpful during policy design, peer review and entitlement recertification because it forces each rule to answer the same three questions.

Common misunderstanding: A well-formed statement is not the same thing as a well-governed permission. Practitioners still need to validate scope, context and ownership, especially where the same subject can hold multiple roles or reach multiple objects through indirect paths.

Related resources from NHI Mgmt Group

• Why does recursive subject discovery matter for authorization systems that model access as a relationship graph?
• What is the difference between roles and object tags in a policy-driven access model?
• Non-Human Identity Access Management
• Shared Responsibility Model