An access authorization gap — not a stolen credential, not a bypassed firewall — is what let two seconded employees look up the Australian Prime Minister's personal banking records. Two staff seconded from EY to Commonwealth Bank of Australia used live, correctly in-scope secondment access to look up Anthony Albanese's personal banking details. The access was real. What was never independently established was whether looking up those particular records was something they were authorized to do.
The Access Authorization Gap
Reporting on the incident indicates that the control standing between "has access" and "used access for an authorized purpose" included a self-attestation step: before the system granted access to customer data, the requester confirmed their own authorization. That confirmation fired. It was answered. And it verified nothing, because the entity being asked to attest to its own authorization was the same entity whose authorization was in question.
This is worth sitting with precisely because nothing exotic happened. No privilege escalation. No lateral movement. No credential theft to investigate. The interesting failure isn't a technical control that stopped working. It's a control that was designed to answer the wrong question. The access grant was correct. The secondment was real. The system logged the lookup accurately. The access authorization gap sits one layer above all of that, in the place where the architecture assumed a fact instead of establishing it.
Access Existing Is Not Purpose Authorized
Enterprise access models are very good at answering one question: does this identity hold a grant that technically covers this resource? They're built to answer it fast, at scale, across thousands of identities and millions of resources, and they answer it correctly almost all the time. What they're frequently not built to answer is a second, entirely different question: is this specific use of that grant, right now, for this purpose, something the organization actually authorized?
Those two questions get treated as one question constantly, and they are not the same question. A secondment arrangement authorizes a person to operate inside a defined technical boundary — it does not pre-authorize every possible action available inside that boundary for every possible reason. Access answers "can this identity reach this resource." Purpose authorization answers "should this identity be doing this, right now, for this reason." A control that only asks the first question and treats the answer as covering the second has an access authorization gap in it, whether or not anyone ever walks through it.
Self-attestation is where that gap gets papered over rather than closed. Asking someone to confirm they're authorized produces an answer with the shape of verification — a checkbox, a logged confirmation, an audit entry that says "authorization confirmed" — without the substance of it. A control cannot independently verify a fact by asking the subject of that fact to supply it. That's not a lesser form of verification. It's not verification at all, dressed as one.
The Same Failure, One Layer Down
This exact shape showed up here recently at a different layer. GhostApproval — the symlink-based flaw that turned AI coding-assistant approval prompts into a rubber stamp — is a human-in-the-loop control failing for the identical structural reason: the approval step fired, was answered, and the answer was worthless because it wasn't independently verifying the thing it claimed to verify. There, an agent showed a developer a harmless filename while writing to a sensitive one, and the approval dialog confirmed the filename shown rather than the write actually happening. Here, a system asked a person whether they were authorized and accepted their own answer as the check.
Different layer — AI tooling in one case, human workforce access in the other — same architecture problem underneath: a control that produces an answer without independently establishing the condition it exists to verify. GhostApproval broke that assumption at the point where a machine's internal state diverged from what a human was shown. This incident breaks it at the point where a person's stated authorization stood in for actual authorization. Neither is an authentication failure. In both cases, the control produced an answer without independently establishing the condition it was supposed to verify.
Architect's Verdict
Somewhere in your access architecture, a control is doing one of two things: independently establishing that a given use of access was authorized, or accepting the requester's own assertion of that fact and calling it settled. Those look identical in a dashboard. They are not identical in what they protect against.
The audit worth running isn't "who has access to what" — that inventory is usually in reasonably good shape. It's narrower and less comfortable: which of your purpose-verification steps are actually independent checks, and which are self-attestation wearing an audit trail? Self-attestation can establish that a person made a claim. It cannot independently establish that the claim was true. The distinction matters because a control designed to prevent unauthorized use cannot rely on the requester to independently prove the authorization that the requester is asking the control to accept. That's the actual failure mode here — not the secondment, and not the two employees who misused it.
Test it directly: pick one control in your environment that gates access to a sensitive resource by asking the requester to confirm their own authorization. Ask what happens if the requester is wrong, or lying, about that confirmation. If the honest answer is "nothing, until someone reviews the log after the fact," that control has the same access authorization gap this incident exposed — it just hasn't been used against you yet.
Independent verification does not necessarily mean adding another person to an approval chain. It means the authorization decision has to draw on a fact the requester does not control. That might be the engagement, case, transaction, ticket, customer relationship, data classification, or other context that establishes why the access is being used. The important architectural property is separation: the system deciding whether the use is authorized needs evidence from somewhere other than the identity making the request. Otherwise, the control is not validating purpose — it is recording the requester's confidence that their purpose is valid.
That separation looks different depending on what's available. Requester-controlled evidence — a checkbox, a typed justification, a self-selected reason code — is exactly what failed here, because the requester is also the party with an incentive to describe their own access favorably. System-derived context is stronger: does an open ticket, an active engagement record, or a logged customer interaction already establish why this identity would plausibly need this resource, independent of anything the requester says today? Independently assigned business context is stronger still: a case manager, an engagement lead, or a data owner — someone other than the requester — attaches the authorized purpose to the access grant before the request is ever made, so there's nothing left for the requester to assert. None of these require adding a person to an approval chain in the way a second sign-off would. They require the decision to reach for a fact the requester didn't produce.
The architecture trusted an assertion at the exact point it needed independent verification. That's the gap. It doesn't show up in an access review, and it won't show up in the next one either unless someone goes looking for it specifically.
📄 Download: Access Authorization Gap — Architect's Review Questions — six questions to run against any control that gates access by asking the requester to confirm their own authorization.
Originally published at rack2cloud.com
