Yesterday’s Authorization Isn’t Tomorrow’s Justification

Yesterday’s Authorization Isn’t Tomorrow’s Justification

By

Kimly Hong

Access Controls Grant Authority. Governance Decides Whether It Remains Justified.

An engineer needs elevated production access. The organization has all the machinery one would expect: a PAM vault, defined roles, an approval workflow, MFA, logging, automatic expiration. The technical system can answer one question efficiently: does this identity currently hold this privilege?

The security program actually needs answers to harder questions: why does this person need it now, is the scope proportional to the task, and does yesterday’s approval remain appropriate today?

PAM looks like a permissions management problem because permissions are what the technology manipulates. What the organization is actually governing is exceptional authority. An authorization is only as sound as the judgment supporting it. A green light granted under one set of conditions should not remain green indefinitely after those conditions change.

That distinction matters beyond identity governance. As organizations extend consequential authority to AI systems, automated enforcement pipelines, and the humans who supervise them, they risk recreating the same mistake. PAM governs when exceptional authority should exist. AI operations increasingly face the same question for reviewers, classifiers, and agents. The technical architecture differs. The governance problem has the same structure.

A Permission Records a Decision. It Does Not Preserve Its Justification.

An entitlement represents the output of an authorization decision: identity X may perform action Y against resource Z. It does not establish whether the facts that made that decision reasonable still hold. It does not record why the access was necessary, what risk was accepted, what evidence supported the approval, or when those conditions would cease to hold.

Every authorization rests on a premise: a set of facts and assumptions that make the authority reasonable at that moment. The entitlement can persist even after that premise becomes false.

This is why periodic access certification so readily becomes mechanical. A reviewer sees an account, an entitlement, a business justification field last updated eighteen months ago. The reviewer clicks retain. Technically, the authorization has been reconsidered. Substantively, very little judgment has occurred.

Authentication establishes who or what is acting. Authorization grants capability. Governance asks whether that capability remains justified. The first two can be expressed technically. The third cannot be reduced to a configuration state.

In one geographically distributed environment where I worked on PAM governance, the same nominal privilege could carry very different risk depending on operational context. The useful governance question was never whether an entitlement mapped correctly to a role. It was whether the conditions that originally justified that entitlement still existed.

When the Evidence Changes, the Authorization Should Too

In October 2023, Okta’s support case management system was compromised. During the incident, one service token and three service account credentials belonging to Cloudflare were exposed. Cloudflare’s security team knew about the breach and rotated the vast majority of exposed credentials. Four were missed, described in Cloudflare’s own post-incident account as mistakenly believed to be unused.

A nation-state threat actor began probing Cloudflare’s systems with those credentials on November 14. Over the following days, the actor accessed Confluence and Jira, established persistence in the Atlassian environment, and reached Bitbucket source-code repositories. The intrusion was possible because credentials whose trust conditions had materially changed remained usable.

What changed was their authorization premise. Once the Okta compromise established that the credentials had been exposed, the evidence supporting continued trust had materially changed. The technical authorization survived after its underlying premise no longer did.

Exceptional access should not merely expire on a schedule. Its justification should be reopened whenever the evidence underlying it materially changes.

Privilege Is Defined by Consequence, Not by Account Classification

Okta’s own investigation illustrates a different failure: consequential privilege does not always reside in accounts conventionally classified as privileged.

An attacker obtained credentials associated with a service account used by Okta’s customer support system. The account could view and update support cases. Some files contained session tokens. The attacker used those tokens to access files associated with 134 customers and hijack five customer sessions.

A customer-support service account does not fit the conventional mental model of a domain administrator. Yet the access it enabled exposed session material capable of producing customer-level consequences. That is consequential authority by any meaningful definition.

For governance purposes, privilege should be defined by the consequences an authority can produce, not by what the identity is called. Any identity granted exceptional authority belongs within the governance perimeter when misuse or error could produce consequential outcomes.

This definition becomes essential when the discussion moves to AI systems. An automation pipeline, a classifier routing decisions, a reviewer authorized to take enforcement actions, a model integrated with downstream tools: none of these look like conventional privileged accounts. All of them possess consequential authority.

When Authority Outlives Its Original Assumptions

The Cyber Safety Review Board’s 2024 report on the Storm-0558 breach illustrates the stakes surrounding long-lived consequential authority. The threat actor forged authentication tokens using a Microsoft-created signing key dating to 2016 and ultimately compromised Exchange Online mailboxes belonging to 22 organizations and more than 500 individuals. The Board concluded the intrusion was preventable.

Viewed through an authorization-governance lens, the lesson extends beyond Microsoft’s specific technical failure. A credential or cryptographic key can remain technically valid while the assumptions surrounding its continued authority become increasingly difficult to defend. The longer consequential authority persists, the greater the opportunity for its original assumptions to diverge from current reality. Longevity should therefore increase the burden of demonstrating that the capability remains necessary, appropriately scoped, and adequately protected.

AI Inherits the Authorization Problem

Across these incidents, the common weakness is the persistence of authority after some part of its original context has changed. Technical validity and continued justification are not the same thing.

That distinction becomes more consequential in AI operations because authorization increasingly governs not only who may access a system, but which humans and machines may make decisions on behalf of it.

Those decisions require judgment infrastructure: mechanisms that test, challenge, and update the basis for consequential authority. That includes evidence standards, decision boundaries, escalation criteria, reassessment triggers, error taxonomies, calibration, and feedback into future decisions.

An automation threshold is an authorization decision. It grants a machine bounded permission to act independently within a defined decision boundary. A reviewer standard does the same for a human. An agent’s tool policy does the same for a model. Each converts prior judgment into bounded authority. The governance problem begins when the encoded boundary survives longer than the evidence that justified it.

The critical governance artifact is therefore not merely the threshold, policy, or permission. It is the evidence and assumptions that justified placing the boundary there.

Attacker behavior evolves. Product capabilities change. Policy ambiguity surfaces in edge cases the threshold was never calibrated against. Reviewers who handle escalations develop tacit knowledge that never makes it back into the criteria governing the next decision. The threshold continues operating as if none of this has changed.

Automation does not remove judgment. It encodes it. Human judgment determines what evidence matters, what confidence is sufficient, which actions may proceed automatically, and which require escalation. Those encoded judgments do not update themselves. They require the same governance infrastructure as any other consequential decision: evidence standards, reassessment triggers, error taxonomies, and calibration. The configuration records an authorization premise at a point in time. Governance must determine whether that premise remains valid.

Reassess Authority When the Evidence Changes

The PAM world has a formal mechanism for revisiting whether authorization remains appropriate: access recertification. AI operations use a different family of mechanisms, including calibration, evaluation, adjudication, and threshold review. Structurally, they serve a similar governance purpose: testing whether previously accepted decision boundaries still hold.

For PAM, reassessment triggers include a role change, a vendor engagement ending, an emergency account surviving its emergency, or a system connecting to more consequential infrastructure than the original authorization contemplated. For AI safety operations, parallel triggers include rising reviewer disagreement rates, appeals revealing a systematic classification error, new attack patterns the existing threshold was never calibrated against, and model updates that change underlying system behavior.

Reviewer disagreement is particularly valuable as a signal because it is not merely a quality metric. Persistent disagreement can indicate that the authorization premise itself is underspecified. The evidence standard may be unclear, the decision boundary unstable, or the escalation rule may be asking reviewers to resolve ambiguity the governance system has never resolved.

In both domains, the governance question is the same: does the evidence still support allowing this actor to exercise this level of authority without additional review? A scheduled certification cycle asks that question on a calendar. Evidence-triggered reassessment asks it when the answer might have changed. That is not necessarily more governance. It is better-timed governance.

Governing Exceptional Authority

The practical output of this argument is a set of questions applicable to every consequential actor in a PAM program or AI safety operation, regardless of classification. Whether the actor is a privileged administrator, a service account, a human reviewer, an automated classifier, or an AI agent with tool access, the governance infrastructure should answer six questions.

Authority: What can this actor actually cause to happen? Evaluate consequence, not labels.

Justification: What is the authorization premise? What evidence currently supports it, and which assumptions would invalidate it?

Boundary: What may this actor do independently? Where does escalation begin?

Escalation: What uncertainty, anomaly, or consequence requires another decision-maker? Define this before the difficult case arrives.

Reassessment: What evidence or event should reopen the authorization decision? Time can be one trigger, but should not be the only one.

Accountability: Can we reconstruct the decision rule, evidence, and governance conditions under which the action was permitted?

These six questions do not begin with a tooling problem. They begin with a different definition of what the governance program is supposed to produce: not merely evidence that an authorization occurred, but defensible confidence in its continued justification.

Permissions Need a Return Path

Microsoft had sophisticated identity and key-management infrastructure. Cloudflare had extensive access controls and credential-rotation procedures. Okta had access controls around its support environment. The lesson is not that technical controls were absent. It is that consequential authority can remain technically valid after the reasoning supporting that authority has changed.

AI safety operations risk making the same design choice at much larger scale. Trust and safety programs that treat automation thresholds as stable configurations and calibration as an onboarding event are building provisioning systems and calling them governance.

The diagnostic question is direct: if the premise supporting a consequential actor’s authority were wrong today, would your governance infrastructure detect it before the consequences did? If the answer is no, the architecture is relying on the persistence of the permission, not continued evidence for the judgment behind it.

Building the return path changes that. Each new decision can then incorporate what happened after the last one. Escalations expose ambiguous criteria. Errors populate taxonomies. Taxonomies inform training and decision rules. Appeals test whether those rules remain defensible. Changed conditions trigger reassessment outside scheduled certification. Reassessment changes the authorization boundary. Without that path, the organization records decisions. With it, the organization improves the judgment system producing them.

Privileged access is a judgment problem disguised as a permissions problem. AI does not change that principle. It expands the number of humans and machines capable of exercising consequential authority and raises the cost of allowing yesterday’s judgment to persist as today’s authorization.

Governing exceptional authority therefore requires a live answer to one question: does the premise that justified this authority still hold?

If your program cannot answer it, you know the state of the permission. You do not know whether the permission is still justified.


About the Author

Kimly Hong is a Principal Cybersecurity and GRC Consultant with more than ten years of experience building enterprise security programs across regulated financial services, hospitality, and technology environments. Her work spans governance, risk, and compliance program design, third-party risk management, access governance, and incident response readiness. She has built these programs from the ground up across complex, multi-region environments and currently consults across financial services, SaaS, and retail organizations. Connect on LinkedIn to continue the conversation.

Kimly Hong

Kimly Hong, MBA,CSM is an accomplished cybersecurity program manager with expertise in the adoption and implementation of cybersecurity frameworks, risk management, and compliance. She has led security initiatives for Fortune 500 companies and global enterprises, overseeing security awareness programs and regulatory compliance strategies. Her leadership and hands-on approach make her a trusted partner in navigating complex cybersecurity challenges. She holds degrees from Bryant University and Husson University. Connect with her on LinkedIn.

Share Post :

Newslater

Get Our Latest Updated

Lorem ipsum dolor sit amet consectetur adipiscing elit.

Scroll to Top