Four questions, four control responsibilities
As AI systems gain tools and autonomy, familiar security vocabulary is often stretched to cover new concerns. Words such as identity, access, authorization, policy, safety, and governance can begin to sound interchangeable. They are not. Blurring them makes architecture harder to evaluate because a control built for one question is credited with answering another.
A useful formulation is: Identity asks, “Who or what is acting?” Access asks, “What can it reach?” Security asks, “Is the behavior dangerous or prohibited?” Authority asks, “Was this particular action actually authorized under the enterprise mandate?” The questions overlap in evidence, but each produces a distinct answer.
Identity: Who or what is acting?
Identity systems establish and authenticate principals: employees, services, workloads, applications, agents, devices, or other actors. They may provide lifecycle management, federation, strong authentication, workload identity, and attributes used by downstream controls. Without dependable identity, actions cannot be reliably attributed and delegated authority cannot be traced.
Identity does not normally establish the business purpose of every action. The same authenticated agent can participate in several assignments. Knowing its principal, owner, or service account is necessary, but it does not tell the enterprise whether a specific database update or repository change belongs to the current mandate.
Access: What can it reach?
IAM roles, application permissions, API scopes, repository rules, and resource policies determine which operations are technically available to an identity. They implement least privilege, separation of duties, environmental boundaries, and other essential controls. If access is denied, the action should not execute regardless of its business purpose.
Yet access is commonly reusable across tasks, while authority is action-specific. A service needs enough permission to perform its range of functions; a mandate may support only a subset for one objective. Permission is not authority because technical reach does not independently prove enterprise intent at a particular moment.
Security: Is the behavior dangerous or prohibited?
Cybersecurity controls assess threats, vulnerabilities, unsafe configurations, malicious behavior, data exposure, compromised identities, anomalies, and explicit prohibitions. They may block known-dangerous actions, detect abuse, inspect content, enforce network boundaries, or alert responders. These functions remain necessary whether the actor is human or automated.
A safe-looking action can still lack authority. An agent might propose syntactically valid, non-malicious code that changes a business rule outside its assignment. Conversely, an authorized objective does not make an insecure implementation acceptable. Security and authority should both be satisfied; neither is a criticism or replacement of the other.
Authority: Was this action actually authorized?
Authority connects the proposed action to enterprise mandate. It asks who is acting, on whose behalf, toward what objective, against which target, within what scope and time, through which delegation, under which constraints, with what evidence. The answer applies to the specific effect rather than the actor in the abstract.
Suppose an agent can merge a pull request. Identity authenticates the agent. Access permits the merge. Security checks find no malicious content. Authority still asks whether this change, branch, repository, release, and moment are supported by an accountable mandate. A complete control model preserves all four questions.
Authorization in IAM and enterprise authority
IAM practitioners correctly use “authorization” for access decisions. Enterprise authority over AI is not an attempt to redefine or diminish that work. It identifies an additional layer of business authorization whose inputs may not fit inside a role or resource policy: accountable intent, action-level purpose, delegation lineage, current mandate, and contextual constraints.
The layers can integrate cleanly. Identity and access facts become evidence for an authority decision. The authority outcome can then be enforced at a supported application or workflow control point, while IAM continues to prevent execution outside technical permissions. Precise interfaces are more useful than asking one system to absorb every responsibility.
Use the distinctions to design better controls
For each consequential AI action path, teams can write down the four answers. Which identity is accountable for the request and execution? Which permission enables the operation? Which security controls test danger or prohibition? Which enterprise source establishes that this action serves an approved objective within current bounds? Missing answers reveal different engineering or governance work.
This approach avoids declaring mature controls defective simply because they solve a different problem. Strong identity, least privilege, and cybersecurity are foundations. Explicit enterprise authority adds the evidence-backed decision about the action itself. Together they allow organizations to use capable AI without treating capability as consent.
A layered decision avoids false confidence
When teams receive an AI action request, a layered decision can fail for several independent reasons. The identity may be unknown, the permission may be absent, security may identify a prohibited pattern, or the mandate may not support the effect. Preserving the reason matters because remediation is different in each case. Granting a role cannot repair missing enterprise intent, and supplying a mandate cannot cure a compromised identity.
The same structure improves assurance reporting. Instead of stating that an action was generically authorized, the record can show authentication, technical access, security checks, and enterprise authority as separate facts. Reviewers can see which controls participated and where evidence was unavailable. Precision prevents one green signal from being stretched into confidence about the entire action.
NEXT STEP