Ask a developer where “rights” live in their system and they will point at code. checkPermission(). A role table. An OAuth scope comparison. An approval workflow with a threshold. A sudoers file parsed at runtime.
The observation that starts this
All of those are functions. Designed, specified, tested, shipped functionality — no different in kind from transferFunds() or exportReport(). There is no separate ontological layer hovering above the software where entitlements are kept. Authorization is implemented, and what implements it is functionality.
This is worth stating plainly, because most risk frameworks quietly assume the opposite. They treat “access rights” as a governance object and “functions” as a technical object, and then wonder why insider cases keep landing on the wrong desk.
So the observation is correct, and it has a sharp consequence: if rights are functions, then abusing a right is a species of abusing a function, and the distinction between #1 Abuse of Functions and Abuse of Rights looks like it should collapse.
It does not collapse. Understanding exactly why is the point of this article.
Superset, not sum
The tempting formulation is that the functionality of software is the sum of its access-right mechanisms. It is not. Functionality is a superset of rights, and rights are a very particular subset of it:
Rights are the subset of functions whose job is to partition the invocation of all the other functions.
transferFunds() is a function and is not a right. mayTransfer(user, amount) is a function and a right, because its output governs whether the first one runs. Every right is a function; almost no function is a right.
If you take “sum of” literally, the containment becomes an identity, the two abuse concepts merge, and cyber risk swallows the whole of operational risk — every fraud, every mandate breach, every act of internal misconduct performed through a keyboard becomes a cyber event. That is precisely the strategic error the framework exists to prevent, and it is the error taken apart case by case in The Adoboli Paradox.
The asymmetry, not the containment, is what does the work.
The grid that places both
TLCTC does not decide this by looking at mechanisms at all. The cause side of any risk event is partitioned by three questions, asked strictly in that order:
| Actor | Intent | Entitlement | Row | Register |
|---|---|---|---|---|
| No | — | — | Failure (software, hardware) or external event | OpRisk |
| Yes | No | — | Error in Use | OpRisk |
| Yes | Yes | Yes | Abuse of Rights | OpRisk |
| Yes | Yes | No | Attack — the ten TLCTC clusters | Cyber |
Two things about this grid are load-bearing.
First, entitlement is only asked once intent is present. An unentitled actor who did not intend the outcome is Error in Use, not an attack — a visitor who trips a breaker is not #8. Authorization becomes a classifying question only after intent is established, and that is what closes the grid instead of leaving a residue.
Second, “authorized” here means entitled, not permitted. Permission is what the access-control system happens to return; entitlement is what a grantor actually conferred. The two are supposed to coincide and frequently do not — that gap is where most of the interesting cases live.
Abuse of Rights is therefore the insider row at every altitude: a badge holder propping open a door, an administrator using genuine root to exfiltrate, a clerk posting a false entry inside their role, an officer approving a payment inside their mandate. The entitlement was real, held genuinely, and used within its grant but against its purpose.
This is not an actor test
The obvious objection is Axiom IV:
Axiom IV — Threats Are Not Threat Actors. Actor identity (attribution, motivation, capability) is not a structuring element for threat categorization; TLCTC classifies actions and exploited generic vulnerabilities, not “who.”
If the taxonomy refuses to structure itself by actor, how can the discriminator be whether the actor was entitled?
Because the entitlement test is not a test on the actor. It never asks who someone is, where they sit on an org chart, whether they are staff or contractor or nation-state, or what they were trying to achieve. It asks one relational question about the action:
Did this action fall inside the envelope some accountable grantor actually conferred for it?
That is a property of the action-versus-envelope relation, not a property of a person. The proof is that it cuts straight across the insider/outsider line an actor test would respect:
- An outsider with no entitlement whatsoever → Attack row → a cluster.
- An insider acting outside the envelope they were granted → the same Attack row → the same cluster.
Those two land in the identical place. No actor test produces that result. “Insider threat” is not a category in TLCTC and never was — it is a mixture of two rows that answer to two different control regimes, which is exactly why it performs so badly as a management concept.
The framework already makes this move elsewhere. R-CRED resolves credential cases by asking whether the system was deceived about who is authenticating — the truth of the identity claim, not the identity of the claimant. A credential the target system itself issued to the presenter through a designed enrolment function makes that presenter its authentic holder, and using it is not #4. The entitlement test is the same instrument pointed at authorization rather than authentication.
The two abuses, side by side
| #1 Abuse of Functions | Abuse of Rights | |
|---|---|---|
| Property of | the object — the designed scope of functionality | the subject — an entitlement genuinely held |
| Envelope | crossed, using designed features, no code flaw | honoured — the actor stays inside it |
| Generic vulnerability | “The inherent trust, scope, and complexity designed into software functionality and configuration” | none — the system behaved as designed and as authorized |
| Grantor | none. A designer left a path open; nobody vouched for the actor | a named, accountable party issued the entitlement |
| Central event | SRE — Loss of Control / System Compromise | no SRE. The chain begins at the DRE |
| Register | Cyber | Operational Risk |
| Accountable | CISO | CRO, business line, HR |
| Controls | least privilege, function-level authorization, scope reduction, anomaly detection | segregation of duties, four-eyes, mandate limits, supervision, vetting, purpose auditing |
The row that settles the question is generic vulnerability. Axiom VI requires every cluster to be defined by exactly one generic vulnerability. So: what would Abuse of Rights’ generic vulnerability be? “The fact that entitlements are granted”?
That is not a weakness of an asset. It is the precondition of the asset being useful. And here is the asymmetry that decides everything:
#1’s generic vulnerability is reducible by design. Narrow an API, remove a configuration surface, tighten a function’s scope, and the exposure genuinely shrinks. A granted entitlement is irreducible by design. A trader must be able to book trades. A DBA must be able to read the database. Remove the entitlement and you have not secured the system — you have removed the business.
Two exposures, two different levers, two different owners, two registers. That is the entire argument, and it is why Abuse of Rights is not cluster #11. It is not a cluster that was left out; it sits on the other side of the framework’s scope boundary. Cyber risk addresses unauthorized or unknown entities, and an entitled actor inside their grant is neither.
The decision procedure
1. Is there an actor? No → Failure / external event. OpRisk. No cluster. 2. Did the actor intend the outcome? No → Error in Use. OpRisk. No cluster. 3. Did an accountable grantor confer an entitlement covering THIS action? Yes → Abuse of Rights. OpRisk. No SRE. Chain starts at the DRE. No → continue. 4. Was an implementation flaw required? Yes → #2 / #3 per R-ROLE. No → #1 Abuse of Functions. Cyber. SRE recorded.
Step 3 is the one that is routinely skipped, and skipping it is what produces a cyber register full of events no security control could ever have prevented.
Note the order of steps 3 and 4. Entitlement is asked before the code-flaw test, because an entitled actor exploiting a code flaw is a different and rarer case than the grid’s third row — and it is an attack. Exploiting a bug is never inside anyone’s grant.
Worked cases
The support agent
A support agent opens a customer record belonging to a celebrity, out of curiosity.
They hold the entitlement to open customer records; that is the job. Purpose corrupted, envelope honoured. Abuse of Rights. OpRisk. No cluster, no SRE. The DRE is a loss of confidentiality, and it arrived without any system compromise at all.
Now the same agent edits a region parameter in the URL to reach a record outside their assigned territory. Same verb, same endpoint, same session, one changed integer — and the entitlement covered their region only. #1 Abuse of Functions. The IDOR is a designed function reached outside its intended scope; the cause side is now populated and an SRE is recorded.
The two events are almost indistinguishable in the access log. They are not remotely the same risk, they are not owned by the same executive, and no amount of log analysis separates them — because the discriminator is not in the log. It is in the entitlement register.
The administrator
A DBA runs a bulk export of the customer table.
If the grant reads “administer the database” and the export falls within it, this is the third row — genuine root, used against its purpose. If the grant reads “administer schema and performance, no bulk data extraction,” the same command is past the envelope and it is #1.
Which means the classification of a technical act depends on a governance document. That is not a defect of the framework; it is the framework refusing to pretend that a question about authorization can be answered without consulting the authority.
Enrolment
Someone uses a designed self-registration function to obtain an account with permissions outside the population it was meant for, then authenticates as that account.
The enrolment step is #1 — a designed function used outside its intended scope. The authentication that follows is not #4, because the target system itself issued the credential and is not deceived about who is authenticating. R-CRED states this directly.
And it is not Abuse of Rights either: nobody with authority conferred anything. The grant was manufactured by the function, not issued by a grantor.
Stolen credentials
An attacker phishes an employee’s credentials and performs only actions that the employee’s own account was entitled to perform.
Every keystroke sits inside the permissions the system will return. Yet this is not the third row, and the reason is the sharpest statement of the whole principle:
The entitlement attaches to the person, not to the token.
The grant was conferred on the employee. The attacker holds the artifact but was never a grantee, so no action they take is inside any envelope anyone conferred. The system is deceived about who is authenticating, which is #4 by R-CRED, and the subsequent use of those permissions is #1 — designed functions reached by an actor with no grant over them.
#9 →[Δt=hours] #4 →[Δt=5m] #1 + [DRE: C]
VC-2 VC-3
The two transitions sit in different velocity classes. The phish-to-credential hop is VC-2 Tactical (Δt in hours), where SIEM alerting and analyst triage can still realistically operate. The credential-to-abuse hop is VC-3 Operational (Δt in minutes), and VC-3 is the threshold below which human response stops being credible at that edge — against a 15-minute MTTD the Detection Coverage Score is DCS = 15m / 5m = 3.0, so the step completes three times over before anyone sees it. That edge is closed by automation or architecture, or it is not closed.
A stolen entitlement is never Abuse of Rights. It is an attack wearing one.
Adoboli
Kweku Adoboli booked fictitious deferred-settlement hedges to conceal his exposure. He used his own credentials, valid input fields, and a back-office rule that behaved exactly as specified.
The cause side is empty. There is no cluster to record, and consequently no System Risk Event — the system was never compromised, it was obeyed. What exists is a Data Risk Event, a loss of integrity in the trading records, and a cascade of Business Risk Events after it: $2.3 billion, a £29.7 million regulatory penalty, a criminal conviction — and none of it downstream of a compromise.
The full case, and what would have had to be different to move it into the cyber register, is in The Adoboli Paradox.
What actually changes downstream
Getting this cut wrong is not a taxonomy quibble. It changes four concrete things.
What was open, and how v2.5 settled it
Two things in this area were open when this article went up on 3 September 2026. Both were settled two days later, in the v2.5 core paper and the framework dictionary, and the settlement went the way the argument above pointed.
v2.5 §3.4 now defines the System Risk Event as any risk event at the system altitude, with two types: System Compromise — loss of control, an actor holds capability, reached only through cluster steps, the pivot of the Cyber Bow-Tie — and System Failure — loss of function, no actor holds anything, operational risk, no cluster. The failure branch is inside the model rather than implicit, and the figures and the text agree. Abuse of Rights produces neither type: the system was obeyed, not compromised, and did not fail. Its chain begins at the DRE, exactly as argued above.
The dictionary, the core paper and the glossary use Abuse of Rights and gloss it as abuse of an entitlement — an access right, a role, or a mandate, genuinely conferred by an accountable grantor and used against its purpose. “Abuse of Access Rights” is retired: an access right is only one kind of entitlement.
The decision procedure above is normative in v2.5 as R-SCOPE, the nineteenth rule in the registry and the admission rule for all the others: a step is classified under a cluster only where the action fell outside the entitlement envelope an accountable grantor actually conferred for it. The four rows — failure or external event, Error in Use, Abuse of Rights, Attack — are recorded in the dictionary as the cause-side partition, with the entitlement definitions (entitled, not permitted; attached to the person, not the token) and the worked cases from this article. Core paper §3.5 and §6.1; glossary entries Abuse of Rights, Entitlement, Error in Use, Cause-Side Partition, R-SCOPE.
Neither settlement changed the cut. Both concerned where the row is drawn, not what it is — and it is now drawn.
The rule, in one line
Rights are functions. That is true, and it is why the two look alike. But rights are the subset of functions that draws the line, and the taxonomy turns on which side of that line the action fell — not on which function was called, and never on who called it.
The Adoboli Paradox — the same boundary applied to a $2.3 billion case, and why the largest unauthorized-trading loss in British banking history never belonged on the CISO’s risk register.