Access control
In security architecture, access control is the set of policies and mechanisms that decide who can read, modify or invoke a given resource. It is the control that most reports come back to, because almost every serious finding is ultimately a decision that was made in the wrong place or by the wrong component.
How it works
Every access decision has the same three parts: a subject asking, an object being asked about, and an operation. Two components implement it. A decision point evaluates the policy and answers yes or no; an enforcement point sits in the request path and refuses to act without that answer. Separating them is what allows one policy to be applied consistently by many services.
The models differ in where the rule lives. Discretionary control lets the owner of an object grant access to it. Mandatory control applies a system-wide rule that owners cannot override. Role-based control attaches permissions to roles and roles to identities. Attribute-based control evaluates attributes of subject, object, action and context at request time. Real estates mix all four, which is why nobody can answer who has access to what without querying several systems.
What goes wrong
The failure that produces most of our findings is enforcement in the wrong place. A control implemented in the interface that generates the request is a usability feature. If the server acts on any request it receives, the enforcement point is missing, and hiding a button changes nothing. Every menu item removed for a role has an endpoint behind it that still exists.
The second is defaulting to allow. A system that permits anything not explicitly denied is one forgotten rule away from exposure, and the forgotten rule is always the new endpoint, the new bucket, the new queue. Deny by default fails closed and is noticed immediately.
The third is drift. Permissions accumulate: people change teams and keep the old access, projects end and the group survives, an emergency grant is never revoked. Nobody removes access because nobody is certain what will break, so the estate ratchets in one direction, which is what makes least privilege an operational discipline rather than a configuration.
Where this shows up in an audit
We test it by holding a real identity and asking for what it should not have, at every layer we can reach: the interface, the API behind it, the storage behind that, and the management plane behind all of them. The finding names the subject, the object, the operation and the layer where the check should have been and was not. Broken access control is consistently the largest category in our application reports, and it is almost never a missing feature: it is a check placed one layer too high.