What are access controls?

Physical access controls—such as gates and locked doors—control access to physical locations. Logical access controls—such as intrusion detection and prevention systems—control access to computer systems. This article deals primarily with logical access controls.

In access management terms, the entities that need access are known as “subjects.” These subjects include both human users and nonhuman identities, such as bots, apps, automated workloads and AI agents.  

In fact, as this latter category explodes—driven by proliferating cloud infrastructure, the rise of DevOps and the adoption of advanced artificial intelligence tools—nonhuman users are becoming a key focus of access control.

The things that subjects need to access—application programming interfaces (APIs), operating system settings, sensitive information in a cloud database—are called “objects.” 

Implementing access controls in an enterprise network is typically a matter of creating and enforcing access control policies, which define each subject’s access rights within a system. Access control policies dictate whether a subject can access an object (such as a document) and their permissions with respect to that object (in the case of a document: read only, read and write, full administrative control).

Access controls are a cornerstone of identity security. For example, zero-trust network architectures rely on robust access controls to prevent unauthorized access while streamlining access for authorized users. In cloud-native networks, where identity is the new perimeter, access controls are vital to cybersecurity efforts more broadly. 

At the same time, access controls are a weak point for many systems. Broken access controls are No. 1 on the OWASP Top 10 list of the most critical web application security risks. And according to IBM’s X-Force Threat Intelligence Index, identity-based attacks—in which threat actors hijack valid user accounts to abuse their access privileges—account for almost a third of breaches. 

So, while access management plays a key role in organizational security postures, available data suggests there is room for improvement.  

Access controls are usually policy-based. System administrators—in collaboration with other stakeholders, where appropriate—draft access control policies that detail subjects’ permissions. Access control systems, such as identity and access management (IAM) and privileged access management (PAM) platforms, automatically enforce these security policies.

Access control systems use a two-step process of authentication and authorization to help ensure that only verified subjects can access objects, and that those subjects can act only in approved ways. 

Access policies dictate the objects that a subject can access: the S3 buckets that a developer can see, the APIs an application can call, the datasets a large language model (LLM) can ingest. They also, crucially, dictate what individual users can do with an object. Can the LLM write to the dataset? Can the developer change an S3 bucket’s settings? Access policies determine the answers to these questions.

While policies inevitably vary from system to system—and from resource to resource—most organizations follow an established access control model, such as role-based access control (RBAC) or attribute-based access control (ABAC). (For more information, see “Types of access control.”) 

Regardless of model, many organizations’ access policies follow the principle of least privilege: the idea that users should have only the lowest level of permissions necessary to do their jobs, and permissions should be revoked when a task is over.

Access policies can be “stored” in a system in a number of ways.  

• Policies can be written directly into an application’s code. 
  
  
• Some systems use an access control list (ACL), which lists each user and their permissions. There might be a centralized ACL for the entire system, or each individual object might have its own ACL.
    
• In a capability-based access control system, each subject has an associated capability list that stores their access rights. 
  
  
• More dynamic models, such as RBAC and ABAC, use a policy engine: a dedicated service that evaluates each access request according to a defined logic. Instead of relying on a static list to make authorization decisions, policy engines consider the broader context of the request before granting access.  

When a subject wants to access a resource protected by an access control system, they first verify their identity through an authentication process.

For human users, authentication usually entails presenting a set of credentials, such as a username and password combination. However, passwords are considered some of the weakest credentials because threat actors can easily guess or steal them.

Most systems today rely on more substantial measures, such as biometrics and multifactor authentication (MFA). MFA requires two or more pieces of evidence to prove a user’s identity (such as a fingerprint scan and a one-time password generated by an authentication app).

Devices, workloads, AI agents and other nonhuman identities typically use credentials such as certificates and encryption keys to verify themselves. While nonhuman subjects cannot use MFA, secrets management solutions can help protect their credentials through vaulting, automated rotation and other measures. 

Authorization is the process of granting a verified subject the appropriate level of access.

How authorization occurs depends on the access control system in place. 

For example, if a system uses an ACL, it checks the list and assigns the subject the permissions found there. 

If the system uses a policy engine, the engine will grant the user privileges based on the context of the access request.  

In a system that uses the OAuth protocol—an open-standard authorization framework that gives applications secure access to an end user’s protected resources—authorization is granted through tokens.

While every individual object in a network can have its own access control system, this is generally not considered to be a best practice. Gaps and discrepancies between these systems can create vulnerabilities for attackers to exploit—and prevent authorized users from doing their jobs.

Instead, organizations such as the National Institute of Standards and Technology (NIST) and OWASP recommend implementing a centralized access control system, often as part of a holistic identity fabric. 

These centralized systems rely on technologies and tools such as: 

Say that an organization needs to create and enforce access controls for a confidential database containing customer data. 

First, the system administrator and other relevant stakeholders would determine which subjects—people, apps, AI agents—should have access to the database. Perhaps they decide that anyone with a sales or marketing role should be able to access the data, as should the customer relationship management (CRM) and marketing software. Any AI agents owned by authorized human users can also get access. 

Next, the stakeholders determine which actions each authorized user can take within the database. Perhaps sales reps need read and write access because they build and maintain relationships with these customers over time. Meanwhile, marketing roles can only read the database because they simply use customer demographic data to inform campaigns. Maybe all AI agents—regardless of owner—have read-only access to help ensure that a human is always kept in the loop when updating the database.

To enforce this access policy, the organization uses a centralized policy engine, with a detailed access control logic. In addition to user identity, the engine considers contextual factors when determining whether to grant an access request.  

For example, say that a sales rep wants to access the database to update a customer’s email address. First, the sales rep proves their identity by supplying the right authentication factors. Then, their request is evaluated by the policy engine, which considers:

• The rep’s verified identity 
  
  
• The rep’s permissions, which do allow updating customer records
  
  
• The time of day, which is 3:30 PM and well within standard working hours 
  
  
• The health status of the rep’s device, which is up to date on patches and shows no signs of malware

Based on these factors, the sales rep’s access request is granted. 

Organizations can implement different types of access control models based on their needs. Common types include:

Discretionary access control (DAC) systems enable the owners of resources to set access rules for those resources. Object owners can even pass administrative-level privileges to other users in the DAC model. If the owner of an object grants another user admin privileges, that user can also set access rules for the object. 

Mandatory access control (MAC) systems enforce centrally defined access control policies across all users.

They often operate through clearance levels, as in government or the military. Every subject gets a clearance level, and each object has a corresponding clearance rating or classification level. Subjects can access any objects at or below their clearance level. 

While all access controls are mandatory in the sense that every subject must comply with them, the “mandatory” in MAC refers to the fact that individual users cannot alter or assign permissions. MAC is contrasted with the discretionary DAC model, where object owners have control over the access rules for their objects. 

In role-based access control (RBAC), users’ privileges are based on their roles within the organization.

Roles in an RBAC system are not the same thing as job titles, although they can correspond one-to-one in some implementations. But in this context, “role” refers to what a person does in the organization—and the permissions they need to do those things. RBAC roles are based on several criteria, including job titles, skill levels, responsibilities and more. 

For example, say that system administrators are setting permissions for a network firewall. A sales rep wouldn’t have access at all. A junior-level security analyst might be able to view firewall configurations but not change them, while a senior-level analyst might have administrative access. An API for an integrated security information and event management system (SIEM) might be able to read the firewall’s activity logs. 

RBAC is one of the two access control models recommended by OWASP.

The second access control model recommended by OWASP, attribute-based access control (ABAC) uses a policy engine to analyze the attributes of each access request in real time. Only requests that meet the proper criteria are granted.

Broadly speaking, “attributes” are the characteristics of the subjects, objects and actions involved in a request. Attributes can include things such as a user’s name and role, a resource’s type, the risk level of the requested action and the time of day of the request. 

For example, in an ABAC system, users might be able to access sensitive data only during work hours and only if they hold a certain level of seniority. 

The difference between RBAC and ABAC is that ABAC dynamically determines access permissions at the time of each request based on multiple contextual factors. RBAC, by contrast, grants permissions strictly according to predefined user roles.  

Rule-based access control (RuBAC) is a system where access is based on conditional, contextual rules. For example: If a request comes from subject X at Y time, it is allowed. 

“Rule-based access control” is an imprecise and somewhat obsolete term. Often, it is used as a synonym for ABAC, or as a designation for earlier, less sophisticated forms of ABAC. Sometimes, it’s used to denote RBAC systems that run access requests through an additional layer of logic (role + rules). 

Access controls are at the core of enterprise security in more ways than one. OWASP lists them as both the biggest risk when broken and the top proactive control when they work. 

Effective access controls can help protect organizational assets, unleash the full value of enterprise data and secure and empower emerging AI agent technologies. Defective access controls can undermine all these efforts and throw the doors wide open for hackers.

Access controls are foundational to cybersecurity itself because identity is the core of security efforts today.

The average corporate network hosts a growing number of human and nonhuman users, distributed across various locations, that need secure access to both on-premises and cloud-based apps and resources. 

Perimeter-based security measures are ineffective in these environments. Instead, organizations focus their security controls on individual users and resources—or in access management terms, subjects and objects. 

For example, consider the zero-trust approach to network security. Instead of authenticating a user once, zero trust authenticates every single access request from every single user. In other words: every request passes through the access control plane.

Consider, too, how access controls support the CIA triad of information security:

• Confidentiality: Access controls help keep data confidential by limiting access to authorized users only. 
  
  
• Integrity: Access controls help preserve data integrity by controlling what users can do with their access, supporting data compliance and mitigating data breaches.
  
  
• Availability: Access controls help ensure that users have the access they need to do their jobs, while avoiding overprovisioning and the risks it brings. 

Access controls can also help organizations realize more value from proprietary data while maintaining data security. 

According to the IBM Institute for Business Value’s 2025 CDO Study, 78% of CDOs say that leveraging proprietary data is a strategic business objective to differentiate their organization. Furthermore, 82% of CDOs believe that data is “going to waste” if employees can’t readily use it to make data-driven decisions.  

And secure data access becomes even more important as AI agents join the digital workforce. Agents need enterprise data to function efficiently and effectively. 

Effective access controls help both human users and AI agents securely access enterprise data for approved uses. According to the CDO Study, CDOs from organizations that deliver higher ROI on AI and data investments commonly use security measures such as RBAC to govern user access to enterprise data.  

On an episode of IBM’s Security Intelligence podcast, Dave McGinnis, global partner with IBM’s cyberthreat management offering group, called AI agents “the most helpful insider threats.” McGinnis was referring to agents’ capacity to yield both incredible advantages and incredible harm.

To do meaningful work, agents need highly privileged access to enterprise systems and data. But agents are also nondeterministic, and without proper guardrails, they can use their access in new and not-entirely-sanctioned ways.

As Seth Glasgow, executive advisor at IBM’s Cyber Range, explained on Security Intelligence, the judicious use of access controls is key to enabling AI agents while mitigating the risks of privilege misuse:

The standard deployment of [an AI agent] is that it can see everything, right? It’s one agent to rule them all, for lack of a better term. ... But right there, I’ve created an extremely high-value asset. That app is set up to get to a ton of sensitive data. 

So the first thing we have to do from an IAM perspective is start to segment this. We don’t need one agent that can do all of that. It has to align better with the specific use case, and it needs to have permissions that align directly with what that agent should be doing.

Three core factors contribute to broken access controls: overprivileging, a lack of centralization and design flaws.

It’s common for organizations to grant subjects higher levels of permission than they strictly need to ensure that they don’t run into any obstacles when trying to work. Overprivileging is especially common with nonhuman identities used to automate workflows, as organizations typically need them to require as little intervention as possible.

Effective access controls—such as RBAC and ABAC—can help harmonize user experience, business operations and security needs. Instead of overprivileging, organizations narrowly tailor access to precisely the levels each subject needs—no more, no less. 

In systems that lack centralized access controls, different objects can have different control systems. Gaps between these systems can prevent subjects from accessing the resources they need, and all it takes is one weak system to jeopardize the whole network. 

By implementing a holistic identity fabric and using identity orchestration tools to integrate disparate systems, organizations can close security gaps while streamlining access for authorized users.

Finally, as OWASP notes, applications often have design flaws in their access control systems. These flaws can include problems such as the ability to bypass controls by modifying a page URL, missing API controls and unsecured JSON Web Tokens that are vulnerable to tampering.

Developer education, stricter access control requirements and DevSecOps practices can help organizations build identity security directly into applications.