Home  /  Resources  /  White paper: Stolen trust

Whitepaper - 13 min read - 27 September 2026

White paper: Stolen trust - governing the authorisation signals your systems already believe

Three unrelated incidents from the past two weeks share a mechanism nobody planned for together. Bitget's attacker never stole a private key - they compromised a backend system and spoofed transaction data until the exchange's own authorisation process approved $351.6 million in transfers itself. Check Point's attackers didn't guess a password - they presented forged certificates that Security Gateway's VPN handling accepted as genuine. And the SalesBleed flaws in Salesforce Agentforce didn't need a stolen credential at all - a poisoned lead form got an AI agent to act using its own trusted identity, no impersonation required because the agent already had standing to act. Each system did exactly what it was built to do: trust a signal it had every reason to believe.

By Eli - Published: 27 September 2026

Executive summary

Security programmes have spent two decades hardening the theft of secrets - passwords, keys, tokens - because that has historically been how access got stolen. All three incidents behind this paper describe a different failure mode: an attacker who never needed the secret, because they found a way to make the system that checks the secret say yes anyway. Bitget's own account, covered by The Hacker News, describes a suspected North Korean actor compromising a backend system inside its wallet infrastructure on 24 September, spoofing transaction data, and triggering the authorisation process into releasing $351.6 million from hot and warm wallets - the largest crypto theft of 2026. Check Point's advisory on CVE-2026-85102 describes attackers presenting certificates with specific forged subject fields that its Security Gateway VPN handling accepted as legitimate, achieving unauthenticated remote code execution from 12 September, three days after a clean patch. And Zenity Labs' SalesBleed research describes a poisoned Web-to-Lead submission that sat dormant until an employee asked a Salesforce Agentforce agent to process it - at which point the agent executed hidden instructions using its own standing permissions, no credential theft involved because the agent was never impersonated; it was simply used.

What ties these together is that each target system had a legitimate, working mechanism for deciding what to trust - a transaction authorisation check, a certificate validation routine, an AI agent's permission to act on a lead - and each mechanism was fooled into extending trust to something that didn't deserve it, rather than bypassed outright. This paper sets out a governance framework for that specific category: authorisation and trust-decision logic that behaves correctly by its own rules, right up until someone learns exactly what those rules will accept.

1. Authorisation logic is a control, not just application code

Bitget's backend authorisation system existed to do one job: decide whether a requested transfer was legitimate before releasing funds. It functioned correctly by its own logic the whole time - it simply believed data it should have independently verified. Most enterprises apply far less scrutiny, change control and monitoring to the backend logic that approves a transaction, a permission, or an action than they apply to the credentials that logic is meant to be gatekeeping. That asymmetry is the exact gap this incident exploited: an attacker who can make the approval logic say yes never needs to touch the thing it's protecting. Any system with an automated approval or authorisation step handling meaningful value or access deserves the same segregation of duties, change control and independent monitoring as the credentials sitting behind it - not the lighter review typically reserved for internal application logic.

2. Validation routines only defend against the inputs they were tested with

Check Point's VPN certificate handling had a validation routine that, under normal conditions, correctly rejected certificates that weren't genuine. Truesec's analysis of CVE-2026-85102 and its paired management-layer flaw, CVE-2026-93616, describes attackers finding the specific certificate construction the validation logic would accept despite being forged. This is the recurring shape of every bypass in this paper: the defence wasn't absent, it was incomplete against inputs its designers hadn't anticipated an attacker constructing deliberately. Treat every authentication or validation routine - certificate checks, signature verification, permission gates - as tested against known-good inputs by default, and assume it has not been adversarially tested against deliberately malformed ones until you've verified that it has.

3. An AI agent's own permissions are now an attack surface

The SalesBleed flaws, reported by SecurityWeek, describe something neither of the other two incidents involve: an attack that required no impersonation at all. A malicious Web-to-Lead submission sat dormant until an employee asked an Agentforce agent to interact with it, at which point hidden instructions inside the lead caused the agent to exfiltrate CRM data or post phishing messages into internal Slack channels - using the agent's own legitimate, already-granted identity and permissions. Two of the three flaws worked with zero clicks from any human. This is a distinct and newer category from the first two: not a system tricked into extending trust it shouldn't have, but a trusted actor - the AI agent itself - manipulated into using trust it genuinely, legitimately holds. Any AI agent with standing permissions to act on data, send messages or trigger workflows is now a delegation-of-trust risk that needs its own governance, separate from the human identity it was granted on behalf of.

4. Detection built for credential theft won't catch any of this

None of these three incidents would have triggered a classic credential-theft detection: no unusual login, no password spray, no leaked-key alert. Bitget's transactions came through the front door of its own authorisation system. Check Point's attackers connected using accepted certificates. SalesBleed's exploitation looked, to the agent, like an ordinary lead conversion. Detection strategies built around watching credentials and login behaviour have a structural blind spot for attacks that never touch a credential at all - which is precisely the category all three of these incidents belong to, and precisely why they're becoming more common as credential hygiene improves elsewhere.

Practical framework checklist

The following translates the three incidents above into decisions a security or engineering leadership team can act on now.

  • Apply the same segregation of duties, change control and monitoring to automated authorisation and approval logic that you already apply to the credentials it protects - an attacker who controls the approval decision never needs the key.
  • Adversarially test every authentication and validation routine - certificate checks, signature verification, permission gates - against deliberately malformed inputs, not just known-good ones, before treating it as proven.
  • Inventory every AI agent with standing permissions to act on data, messaging or workflows, and treat its permission set as a distinct governance object from the human identity it was granted under.
  • Build detection specifically for anomalous authorisation decisions and agent actions, not only for credential misuse - a legitimate-looking approval or a correctly-authenticated agent action can still be the attack.
  • Patch paired vulnerability disclosures as a single job - Check Point's gateway and management flaws were disclosed together for a reason, and sequencing the fix as two separate, lower-urgency tasks leaves one door open while closing the other.
  • Treat "this system correctly rejected everything we tested it with" as an incomplete claim - the question that matters is what a deliberately adversarial input would do, not what a normal one does.

Risks and how to manage them

The most common failure mode is reviewing authorisation, validation and agent-permission logic with the same light-touch approach applied to ordinary internal application code, on the reasoning that it isn't customer-facing or doesn't itself store secrets. All three incidents in this paper show that reasoning failing in practice - the logic itself became the thing worth attacking. A second failure mode is treating AI agent security as equivalent to service-account security; an agent's permissions are usually broader and more dynamically exercised than a static service account's, and SalesBleed shows that gap being actively exploited within months of broad Agentforce adoption. A third is assuming a nine-day or three-day gap between patch and exploitation is unusually fast; on 2026's evidence, it is close to the median, not the exception, for any internet-facing perimeter component.

Conclusion

Bitget's backend, Check Point's certificate handling and Salesforce's Agentforce permissions each did what they were designed to do. The failure in every case was that the thing they trusted - spoofed transaction data, a forged certificate, a poisoned lead - had been deliberately built to pass exactly the check in place. Enterprises that keep investing solely in credential hygiene while leaving authorisation logic, validation routines and AI agent permissions under lighter scrutiny will keep missing this category of incident until it's their own name in the disclosure. Governing it requires treating the decision-making logic itself - not just the secrets it guards - as the asset under protection. For a facilitated review of where your own authorisation and agent-permission logic might already be trusting the wrong thing, contact sales@halfteck.com.

Not sure what your own systems already trust?

We can run a facilitated review of authorisation logic, validation routines and AI agent permissions against the framework in this paper.

Contact Halfteck

A maturity model for governing trust decisions

Organisations sit at recognisably different stages against this framework. At ad hoc, authorisation and validation logic is reviewed as ordinary application code with no distinct security control classification, and AI agent permissions are granted broadly at rollout with no separate governance from the underlying human identity. At managed, the highest-value authorisation flows - payment release, privileged access grants - get additional review, but validation routines are tested against known-good inputs only and agent permissions are documented but not independently monitored. At defined, every authorisation and validation control handling meaningful value or access carries the same segregation of duties and change control as the credentials it protects, is adversarially tested against malformed inputs before launch and periodically after, and every AI agent's permission set is inventoried and governed as a distinct object. At optimising, anomalous-authorisation and anomalous-agent-action detection runs continuously alongside credential-based detection, adversarial testing of validation logic is automated and recurring rather than a one-off pre-launch gate, and agent permissions are scoped dynamically to the task at hand rather than granted broadly and left standing. Most enterprises we work with in 2026 sit at ad hoc or early managed specifically on AI agent permission governance, even where their credential hygiene is comparatively mature.

Why "the system worked correctly" is not the same as "the system was secure"

Every one of the three incidents in this paper could be described, narrowly and accurately, as the target system functioning exactly as designed - Bitget's authorisation process approved a transaction that met its criteria; Check Point's VPN accepted a certificate that passed its validation checks; Salesforce's agent acted on a lead using permissions it genuinely held. That framing is true and almost useless, because it describes correctness against a specification that never anticipated a deliberately adversarial input. The governance question that actually matters isn't whether a system behaves correctly against the inputs its designers imagined - it's whether it behaves safely against the inputs an attacker will deliberately construct once they understand what the system will accept. Closing that gap means adversarial testing as a standing discipline, not a launch-gate checkbox.

Why this category will keep growing faster than credential theft

Credential theft has an increasingly well-funded countermeasure ecosystem: multi-factor authentication, passkeys, credential monitoring, breach-database checking. Attackers respond to defences that work by moving to ones that don't yet have an equivalent countermeasure ecosystem - and authorisation-logic exploitation, validation bypass and AI agent permission abuse are exactly that category right now. As agentic AI adoption accelerates through 2026, the number of systems making autonomous trust decisions on an organisation's behalf is growing faster than the governance discipline applied to those decisions. Enterprises that build this discipline now, before it's forced by their own incident, will spend materially less remediating it later than those that wait for their own version of these three stories.