Subjects

Subjects are the entities that request or hold access rights in an access control matrix. They can be users, roles, groups, devices, or processes. In practice, subjects form the rows or columns of the matrix and provide the identity side of each permission decision.

Expanded Definition

Subjects are the access-bearing entities in an access control model: the things that are authenticated, recognised, and then authorised against a resource. In identity and access management, the term is broader than “user” and can include service accounts, workloads, devices, roles, or processes when they are the decision point for access.

The boundary that matters is whether the entity can present an identity and be granted or denied rights. A role can act as a subject in some models, while in others it is simply a label attached to a user; that distinction is one reason access-control terminology often varies across products and standards. Guidance vs consensus: practitioners generally agree on the access-control meaning, but product documentation sometimes blurs whether a subject is a person, an account, or a non-human identity.

For machine-facing environments, the subject concept becomes especially important because access is no longer tied only to a human employee. The OWASP Non-Human Identity Top 10 is useful here because it frames the machine identity side of access decisions more explicitly than many general access-control references.

Examples and Use Cases

• A human employee signs in through a directory-backed account and becomes the subject evaluated by RBAC rules for an internal application.
• A service account used by a CI/CD pipeline is the subject that receives narrowly scoped API permissions to deploy code.
• A device identity in a zero trust architecture is treated as the subject when policy checks whether it can reach a protected service.
• A group membership rule uses the group as the subject-like access holder in one system, while another system evaluates the individual user as the subject beneath it.
• A background process or workload identity requests access to a secrets store, making the non-human subject the focus of authentication and authorization.

One practical trade-off is abstraction: roles and groups simplify administration, but they can hide which underlying subject actually has effective access. That makes review and offboarding more difficult when the subject is not a single person.

Security Implications

When subjects are poorly modelled, access decisions become ambiguous and control failures are easy to miss. The most common consequences are excessive privilege, orphaned access, weak revocation, and audit records that do not clearly show who or what actually used the permission.

In human-centric environments, this often shows up as stale accounts or overbroad group membership. In machine-centric environments, the same problem appears as long-lived service credentials, undocumented workloads, or shared automation identities that cannot be cleanly attributed to an owner.

Misunderstanding the subject layer also weakens incident response. If logs record only a role or process name without a stable underlying identity, investigators may struggle to determine whether access was legitimate, inherited, delegated, or abused. The result is slower containment and more uncertainty about blast radius.

A useful practitioner observation is that subject clarity is usually lost first at the integration boundary, where application teams, IAM teams, and platform teams each describe the same entity differently. That naming mismatch can turn a routine access review into a governance gap.

Domain and Governance Relevance

In identity governance, the subject is the anchor for entitlement decisions, certification, and accountability. If the subject is not clearly defined, then ownership, approval paths, and offboarding decisions become inconsistent across systems even when policy language looks sound.

This matters even more for non-human identities because machine subjects often outlive the application release, environment, or team that created them. In NHI-heavy environments, the governance question is not just “who approved access?” but also “what exact entity is holding it, who owns it, and when should it be revoked?”

For access-control design, subjects are the starting point for least privilege and separation of duties. If the subject can be a process, device, or workload, then lifecycle governance has to cover creation, binding, delegation, rotation, and decommissioning with the same seriousness as human joiner-mover-leaver workflows.

That is why subject hygiene is not a terminology issue alone. It is a control foundation that determines whether identity governance can actually keep pace with modern systems.