Manav.id
Definitional · 4 min read

The bribed rep problem: a taxonomy of insider-completable operations

The bribed rep problem: a taxonomy of insider-completable operations

Classify every high-consequence operation in your account management stack by one question: can a single employee complete it alone? The answer produces a list, and the list is your actual insider exposure.

Which operations can a single support representative complete alone?

More than most organisations have ever enumerated. Retail and care staff need broad account authority to do their jobs, and that authority includes exactly the operations an attacker wants: SIM changes, address updates, recovery contact changes and plan modifications. Monitoring finds the pattern after the fact.

Key takeaways
  • Every control implemented inside carrier systems can be exercised by someone with the role. Only a factor held outside the carrier is beyond an insider's reach.
  • The taxonomy has three classes: single-employee completable, two-employee completable, and not completable without the subscriber.
  • The goal is not to eliminate class one but to move a small, named set of operations into class three.

Prerequisites

Representative needs broad authorityto do the jobAuthority includes high-consequence operationsunenumeratedSingle representative completes one aloneno second partyMonitoring detects the patternafter several
The exercise is listing them. Most organisations have never done it.

Step 1 — Enumerate operations, not permissions

Start from what a rep can do, not from what a role grants. Permissions are abstractions; operations are what appears in a fraud.

Typical high-consequence set: SIM or eSIM profile change, port-out authorisation, account PIN reset, authorised-user addition, device upgrade with financing, plan change affecting billing, address change, payment method change, port freeze removal, account transfer of responsibility.

Step 2 — Assign each to a class

Classification. Test by attempting the operation in a non-production environment with a single account rather than by reading documentation.
ClassDefinitionInsider exposure
1One employee can complete it aloneFull. Monitoring is the only control.
2Requires two employeesReduced. Collusion required.
3Cannot be completed without a subscriber-held factorEliminated for the insider path.

Be rigorous about class 2. If the second approval can be obtained by asking a colleague who approves without looking, the operation is functionally class 1. Test it.

Step 3 — Rank by downstream consequence

Not all class 1 operations matter equally. Rank by what an attacker gains.

  1. eSIM profile change — grants control of the number, which grants recovery on downstream accounts. Highest.
  2. Port-out authorisation — same outcome, different mechanism.
  3. Account PIN reset — enables the two above through the front door.
  4. Payment method change — direct financial fraud, lower downstream leverage.
  5. Address change — enables device shipment fraud and mail interception.
  6. Authorised user addition — persistent access, often the longest-lived.

Step 4 — Move the top three to class 3

This is the entire recommendation. Not every operation, not most operations — three.

Moving an operation to class 3 means it requires a fresh assertion from a credential the subscriber holds. No role, no override, no supervisor can substitute for it, because the factor does not exist inside the carrier's systems.

Step 5 — Design the override before you need it

A class 3 operation with no override strands subscribers whose devices are lost. An override that any rep can invoke returns the operation to class 1. The resolution is an override that is available, slow, attributable and rare.

Step 6 — Extend to the dealer channel

Authorised dealers and third-party retail are where this analysis usually finds its worst numbers, because the staff are not carrier employees, turnover is high, and the carrier's background screening does not reach them.

A class 3 operation is indifferent to employment status, which is the property that makes this approach workable across a channel the carrier does not directly control.

Failure traps

  1. Do not classify from documentation. Documentation describes intent; test the system.
  2. Do not treat supervisor approval as class 2 until you have measured how often supervisors decline.
  3. Do not move more than a handful of operations to class 3 in the first phase. Every one generates support volume while enrolment builds.
  4. Do not stigmatise staff. The overwhelming majority are honest, the taxonomy is about system design, and framing it otherwise will lose you the frontline cooperation you need.

A taxonomy of insider-completable operations

Four classes worth enumerating
ClassExamplesSecond party today?
Identity changeSIM swap, port authorisation, recovery contactNo
Contact changeAddress, email, phone of recordNo
FinancialCredit, refund, plan change with a balance effectSometimes above a threshold
AccessPassword reset, account unlock, profile mergeNo

Writing this list is the work. Once it exists, the question of which entries warrant a second party or a customer signature answers itself, and it is usually a short list at the top.

Objections and honest limits

“We monitor for unusual representative behaviour.” Which catches volume and pattern after several events. A bribed representative performing one high-value operation produces no pattern.

“Requiring a second party would halve our throughput.” On the whole queue, yes. On the four or five operations at the top of the list, it is a rounding error — which is why the enumeration matters more than the control.

Building the taxonomy

  1. List every operation a single representative can complete. From the permission model, not from the training manual.
  2. Score each by what it enables for an attacker. Not by how often it is used.
  3. Require a customer signature on the top entries. The customer is the one party the insider cannot impersonate.
  4. Leave the rest alone. Throughput matters, and most of the queue is harmless.

Terms used here

Insider-completable
An operation a single authorised staff member can carry out with no second party.
Bribed representative
An authorised user performing authorised actions for an attacker — the case least-privilege cannot address.
Customer signature
An authorisation from the account holder, which is the only factor an insider cannot supply.

Frequently asked questions

Is this not just least privilege? Least privilege reduces who can perform an operation. This taxonomy asks whether anyone inside the organisation can complete it at all, which is a different and stronger question.

How do we handle subscribers who have not enrolled? They remain on the current path until enrolled. Enrolment builds over months through natural touchpoints, and the control's value rises with coverage.

What about accounts with multiple authorised users? Decide explicitly whose credential governs which operations, and record it. Most carriers have never made that decision formally.

Does this apply to business accounts? Yes, and the delegation model fits well: an account administrator delegates specific operations to named individuals with expiry.

Why doesn't least privilege solve this? Because the representative legitimately needs the authority. The operations an attacker wants are inside the job.

Why doesn't monitoring solve it? It detects volume and pattern. A bribed representative performing one high-value operation produces neither.

What is the actual work? Enumerating the operations a single representative can complete alone. Most organisations have never written that list.

Where this fits in Manav

Manav puts the authorising party back in the loop for the changes that matter, with a signature bound to the specific change and verifiable by a counterparty without calling you.

See change authorisation →

Sources and further reading