When support staff can be bought, the only control is a key they do not hold

A bribed support agent is not an intruder. They are an authorized employee, doing a task inside their job description, with permissions your access review deliberately granted them. Every control built to keep outsiders out is pointed the wrong way. The one control that still works is the one the agent cannot exercise: the customer's own signature.

The change that was completely legitimate and completely wrong

The notification email arrives at 4:12 on a Tuesday afternoon and there is nothing suspicious about it. It comes from the real domain. It passes SPF, DKIM and DMARC, because it genuinely originated from the company's own systems. It appears in the account activity log with a case number, an agent ID, and a timestamp. Subject line: your withdrawal address has been updated.

A support agent really did make that change. The agent was really authorized to make it. They had passed a background check, completed the annual security awareness training, and worked the same queue for eleven months without a single policy violation. If you pulled their access record you would find nothing out of place, because changing a customer's withdrawal address is a normal part of the job. People genuinely do get new hardware wallets, genuinely do lock themselves out, and genuinely do need a human to help.

The only thing wrong with the change is that the customer never asked for it.

Somewhere in a messaging app, weeks earlier, that agent had received an offer. Security researchers who monitor these recruitment channels describe a consistent structure: a small payment per customer record retrieved, a larger one for a completed account change, paid in crypto, with no need to install anything, exfiltrate a database, or defeat a single technical control. The agent simply does their job, on request, for someone who is not the customer. It is the cheapest intrusion in the industry, because it does not involve an intrusion.

What actually happened in the 2025 exchange insider case?

In May 2025 Coinbase disclosed, in a filing with the US Securities and Exchange Commission, that overseas customer support contractors had been paid by criminal actors to access internal customer data. The company said the exposed data affected a small share of its monthly transacting users, that it refused an extortion demand, and that it expected to incur significant costs for remediation and voluntary customer reimbursements. The company's own disclosed estimate of that cost was a range in the hundreds of millions of dollars.

Treat that range as what it is: a company's forward looking estimate in a securities filing, not a settled number. The precise figure matters less than the shape of the incident, which is what makes it worth studying. No malware was needed. No perimeter was breached. No credential was stolen. The attackers did not defeat multi factor authentication, because they never had to authenticate as anyone. They recruited people who were already inside, already authenticated, and already permitted to do the exact thing the attackers wanted done.

The same shape appears in the help desk intrusions attributed to the threat cluster commonly tracked as Scattered Spider. In those cases the attacker called the service desk and talked an agent into resetting credentials or enrolling a new authenticator. US cybersecurity authorities published a joint advisory on the group's social engineering of help desks (CISA advisory AA23-320A), and the widely reported casino intrusions of 2023 are the reference examples, with MGM Resorts describing a roughly one hundred million dollar impact in its own subsequent filings and Caesars reported to have paid a substantially smaller ransom.

Bribery and social engineering look like different problems and get assigned to different teams. They are the same problem wearing two coats. In both, an authorized employee performs an unauthorized action, and in both, every technical control passes, because from the system's point of view nothing anomalous occurred.

Why does least privilege not stop this?

Least privilege is a genuinely good control, and this is not an argument against it. It is an argument about what class of problem it addresses.

Role based access control works by answering a question at the door: is this person allowed to perform this category of action? For an outsider, the answer is no, and the door holds. For a bribed support agent, the answer is yes, because you decided it should be yes, because you cannot run a support function where nobody can help a customer. Your access review last quarter looked at that permission, considered whether the role needed it, and correctly concluded that it did.

Think of a hotel. You can restrict which staff hold a master key, log every use of it, and review the logs monthly. All of that is worth doing. None of it helps on the night a housekeeper is paid to open room 412, because opening rooms is the job, the key is issued on purpose, and the log entry will look exactly like the four hundred legitimate entries around it. The control you actually need is different in kind: a deadbolt on the inside that the master key does not turn.

That is the shape of the fix, and it is worth naming precisely before going further. It is not a better door policy. It is a lock the staff key does not open.

What each existing control actually catches

Run through the standard insider risk stack honestly and you find that each control is real, each is useful, and none of them is aimed at this.

Notice the pattern across the right hand column. Almost everything in the stack is either a filter on who gets in, which the insider passes, or a way of finding out later, which is a cost recovery mechanism rather than a control. This is the accumulating spend on estimating a loss instead of preventing it, and the reason it accumulates is that the underlying question is being asked at the wrong moment.

The two insiders that everyone keeps confusing

Here is the distinction that makes this whole topic tractable, and almost nobody draws it cleanly.

The insider who reads. This person pulls up customer records, copies names, balances, addresses and phone numbers, and sells the list. What has been lost is confidentiality. The correct controls are the ones you already know: minimise what is visible in the console, mask fields by default, require a case reference to unmask, restrict bulk export, log every view, and review. You will not stop every lookup, because looking is the job, but you can dramatically reduce what a single lookup is worth. A support agent who can see a masked email and the last four digits of an account has stolen much less than one who can see everything.

The insider who acts. This person changes the account. New email, new phone number, new authenticator, new withdrawal address, new bank details. What has been lost is not confidentiality. It is authorization. And here is why the distinction matters so much: access control is structurally incapable of helping, because the access is legitimate. There is no permission to revoke without breaking the support function.

Most insider risk programmes are built almost entirely for the first insider. They are data protection programmes wearing an authorization label. They invest in visibility, classification, and export controls, all of which are good, and then they are surprised when the incident that actually costs money is one where no data left the building at all, just a fourteen digit destination that used to belong to the customer and now belongs to someone else.

Splitting the problem this way immediately tells you where to spend. Read side: minimisation and masking. Act side: something else entirely, because nothing on the read side applies.

What would make a bribe worthless?

Work backwards from the economics. The bribe is worth paying because the agent can complete the action. If the agent can only start it, and completion requires something the agent structurally cannot produce, the price of that agent drops to whatever the read side is worth and no further. You have not made your staff more honest. You have made dishonesty less purchasable, which is a far more reliable engineering goal.

The thing the agent cannot produce is a signature from the customer's own enrolled device. Not a code read out over the phone, which the customer can be talked into reciting and the agent can request under a pretext. Not a confirmation email, which the agent can often trigger, and which a compromised or attacker controlled mailbox will happily receive. A cryptographic assertion, generated by a private key that lives in the secure element of the customer's phone or laptop, over the specific details of this specific change.

The properties that matter here are worth being precise about, because "the customer confirms it" is a phrase that hides an enormous amount of variation in strength.

• It is bound to the payload, not the session. The customer does not sign "yes, I approve something". They sign the actual destination address, the actual new email, the actual amount. Change one character of the payload and the signature no longer verifies.
• The key never leaves the customer's device. There is nothing in your support console, your database, or your outsourcer's environment for anyone to steal or be paid for.
• It is verifiable without calling anyone. The receipt checks against a published public key. Your auditor does not have to trust your logs, and neither do you.
• It names a human, not a role. The evidence says which enrolled person authorized this change, which is exactly what the dispute a year later will turn on.

What does the propose, sign, apply pattern look like?

The implementation change is smaller than people expect, because you are not rebuilding the support console. You are splitting one operation into three, and moving one of them onto the customer's device.

Today, a support console almost always does this: the agent submits a form, the backend validates that the agent's role permits the change, and the change is written. One actor, one step. The fix separates the actor who prepares the change from the actor who authorizes it.

// 1. Staff prepare the change. This writes nothing to the account.
POST /support/changes
{ "customer_id": "c_8241",
  "type": "withdrawal_address.update",
  "payload": { "asset": "BTC",
               "new_address": "bc1q9x...k4ts",
               "label": "Ledger Nano" },
  "case_ref": "SUP-114293",
  "agent_id": "agt_4471" }
-> { "change_id": "chg_77b2", "state": "proposed",
     "payload_hash": "sha256:4f1c...9ae2" }

// 2. The customer signs the exact payload hash on their own device.
//    Delivered in-app or through Beam to a paired phone.
//    The agent cannot produce this and never sees the key.
POST /support/changes/chg_77b2/sign
{ "assertion": { "credential_id": "cred_c8241_a",
                 "signature": "MEUCIQD...",
                 "signed_hash": "sha256:4f1c...9ae2" } }

// 3. Apply. The service refuses without a verified customer signature.
POST /support/changes/chg_77b2/apply
-> 200 { "state": "applied",
         "receipt": "rcpt_2f90...",   // Ed25519, verifies offline
         "authorized_by": "customer",
         "prepared_by": "agt_4471" }

Read the third response carefully, because it contains the property that makes the whole thing worth building. The receipt records two different humans in two different roles. The agent prepared it. The customer authorized it. Those have always been two distinct facts, and every support system in existence has been recording them as one.

The service does the enforcing, not the console. That matters. If the check lives in the support user interface, a sufficiently motivated insider with API access goes around it. The refusal to apply an unsigned change belongs in the account change service itself, so that there is no code path to the account state that does not pass it.

What the customer actually experiences

They are already on the phone or in the chat asking for the change. Their app shows a prompt with the destination address rendered in full. They read it, they use Face ID or their fingerprint, and it is done. The whole interaction adds perhaps fifteen seconds to a call that was going to take four minutes anyway.

The critical detail is that the address the customer sees comes from the payload being signed, not from the support console's rendering of it. This is the same discipline that separates the display from the signer in high value payment approvals, and the reasoning is identical: if the thing showing you the transaction and the thing signing it can be compromised together, you have not actually confirmed anything. We wrote about that failure mode in detail in the analysis of what Bybit's signers were shown versus what they signed.

Which support actions can the customer sign, and which cannot?

Not every support action fits this pattern, and pretending otherwise would be the kind of over claiming that gets a control deployed badly and then abandoned. Sort your support catalogue honestly. The test is simple: at the moment of the action, is the real customer reachable on an enrolled device?

Most of the money in insider assisted account takeover sits in the top six rows, which is convenient, because those are exactly the rows where the customer is reachable and the pattern applies cleanly.

What about the customer who cannot sign?

This is the honest hard case, and it deserves more than a hand wave, because it is precisely where a determined attacker will go the moment you deploy everything above.

If sensitive changes require the customer's key, then the attacker's optimal move is to claim the customer has lost their key. That is account recovery, and account recovery is a genuinely difficult problem that a signature requirement does not solve. It is not solved in this post and I am not going to pretend otherwise. What you have done by deploying customer signatures is concentrate the attack into one flow. That is real progress, because a single hard flow you have thought carefully about is a much better position than fifteen soft ones you have not, but it is progress, not a finish line.

The recovery flow then needs its own design: a second enrolled device where one exists, a co signature from a prior key, a companion device liveness check that re establishes continuity rather than re running document checks, and deliberate delay on high value actions after a recovery event. We have written that up separately in the piece on why recovery is now the weakest link behind strong authentication, and the argument there is the necessary companion to this one. Deploying customer signatures without hardening recovery moves the problem rather than fixing it.

What does this give the auditor and the regulator?

Two things you cannot currently produce.

The first is attribution that survives a dispute. When a customer says they never authorized a change, today's evidence is a log line your own systems wrote, asserting that your own employee recorded the customer's consent. That is not evidence, it is testimony, and it is testimony from the party with an interest in the outcome. A receipt signed by the customer's device and verifiable against a published key is a different category of artifact. It does not require anyone to trust the institution holding it.

The second is the negative case, which is quietly more useful. Once changes require signatures, unsigned change attempts become a clean, unambiguous signal. Not a risk score, an event: someone prepared a change on this account and no customer signature ever arrived. A queue of those, per agent, is the most direct insider indicator you will ever have, and it needs no behavioural modelling to interpret.

On the regulatory side, third party and outsourcing risk expectations have tightened considerably. The EU's Digital Operational Resilience Act has applied to in scope financial entities since January 2025 and puts direct obligations around information and communication technology third party risk, which includes outsourced operational functions. Supervisors asking how you control an outsourced support function currently receive answers about contracts, screening and monitoring. Being able to answer that the outsourcer structurally cannot complete a sensitive change is a materially stronger response.

Honest limits

This control is narrow on purpose, and it is worth being explicit about the edges.

• It does nothing about read only exfiltration. If the bribe is for data rather than for changes, a signature requirement is irrelevant. That is the other insider, and it needs masking, minimisation and per action staff attribution instead. Do both, and do not confuse them.
• The customer can still be socially engineered. If an attacker with stolen data calls the customer, walks them through a plausible story and gets them to sign, the signature is valid and the money moves. Signatures bind intent, not judgment. Clear rendering of what is being signed and a cooling window on first use of a new destination both help, and neither is a cure.
• Enrollment is the trust bottleneck. Whoever controls the moment the customer's key is first bound controls everything downstream. If an insider can enroll a device on a customer's behalf, you have moved the bribe target rather than removed it. Enrollment needs the same rigour as the changes it protects.
• Collusion where the customer is the attacker is out of scope. Someone signing their own fraudulent chargeback or reversal claim produces a perfectly valid signature. That is a different problem.
• Coverage will not be universal. Some customers will have no enrolled device, and you will need a documented path for them, which will be your weakest path. Measure what fraction of sensitive changes go down it.

What to do this week

1. Inventory the completable actions. List every action a support agent can complete today that changes an account's contact details, credentials, destinations, or limits. Most teams have never written this list down and are surprised by its length.
2. Split it into read and act. Put every item in one column or the other. Resist the urge to invent a middle column.
3. Find where enforcement lives. For the top three act items, trace the code path from console to database and confirm whether the check is in the interface or the service. If it is in the interface, that is your first fix regardless of anything else here.
4. Pick one action and pilot it. Withdrawal or payout destination is usually the right first choice: highest loss per event, cleanest payload, easiest for a customer to verify by eye.
5. Instrument unsigned attempts. Even before enforcement, log proposed changes that never receive a signature. This costs almost nothing and is immediately informative.
6. Mask the console by default. Independent of signatures, reduce what one lookup is worth on the read side. Unmask on case reference, log it, review it.
7. Write down the recovery path. Explicitly document what happens when a customer cannot sign, and get it reviewed as an attack surface rather than a support convenience.
8. Take it to your outsourcing review. Ask your BPO what an agent can complete alone. The answer is a better third party risk metric than most of what is currently in those reviews.

If you want to see the shape of the flow before designing your own, the privileged change demo in the labs runs the same propose, sign, apply sequence against a privileged role grant, and the developer documentation covers the signature and receipt format.

Frequently asked questions

How do you stop bribed support agents from changing customer accounts? Require the customer's own enrolled device to sign the specific change before it is applied. The agent can prepare the change but cannot complete it, because the signing key never leaves the customer's device. Bribery stops being worth paying for, since the agent has nothing completable to sell.

Can support staff change my email or phone number without me? At most institutions today, yes. Those actions sit inside normal support permissions and are completed by staff on your behalf, usually with a notification sent afterwards. Whether staff can complete them alone is a specific question worth asking your bank or exchange, because the answer varies widely.

Is this not solved by least privilege and access reviews? No. Least privilege stops actors who lack the permission. A bribed support agent has the permission by design, because you cannot run a support function where nobody can help customers. Access reviews correctly approve that permission every quarter. The abuse is invisible to the control.

What happened in the Coinbase insider incident? The company disclosed to the SEC in May 2025 that overseas support contractors had been bribed to access customer data, that a limited share of monthly transacting users was affected, that it refused an extortion demand, and that it expected substantial remediation and reimbursement costs, which it estimated as a range in the hundreds of millions of dollars.

Does requiring a customer signature slow down support? Barely. The customer is already in the conversation. Signing adds roughly fifteen seconds to a call. Where it does add real work is account recovery, when the customer genuinely cannot sign, and that flow needs deliberate design rather than a quick fallback.

Which account changes should require the customer's device? Anything that changes where value goes or how the account is accessed: payout and withdrawal destinations, bank details, email, phone, authenticators, and transaction limits. Refunds toward the customer and read only lookups do not need it and should be handled with masking and staff attribution instead.

Does this stop insiders stealing customer data? No, and it is important to be clear about that. Signatures address the insider who acts on an account. The insider who reads and sells records is a separate problem addressed by field masking, data minimisation, unmasking on case reference, and per action staff receipts for attribution.

Sources

1. Coinbase Global, Inc. investor disclosures and filings, May 2025, on the bribery of overseas support contractors and estimated remediation costs: investor.coinbase.com
2. US Securities and Exchange Commission, EDGAR full text search for company filings and current reports: sec.gov/edgar/search
3. Cybersecurity and Infrastructure Security Agency, joint advisory AA23-320A on Scattered Spider, including help desk social engineering: cisa.gov
4. Regulation (EU) 2022/2554, the Digital Operational Resilience Act, applicable from 17 January 2025: eur-lex.europa.eu
5. NIST Special Publication 800-53 Revision 5, security and privacy controls, including personnel and access control families: csrc.nist.gov
6. Federal Financial Institutions Examination Council guidance on outsourcing and third party risk: ffiec.gov

You cannot screen your way out of bribery. You can make the thing being bought impossible to deliver.