Case study: security audit of a crypto-asset exchange

Key figures

Background: how secure was a crypto-asset exchange from the inside?

A crypto-asset exchange subject to know-your-customer (KYC) obligations commissioned an external audit in 2026. The question was simple: can an ordinary user see, change or trigger something that belongs to another user?

The platform runs on a cross-platform web app, a business API split into several services (users, orders, KYC files, recipients, messaging, conditional orders, pricing) and an open source identity component in front of authentication. Overall it was well built, which is what makes the case useful: the problems sat in business logic and persistent access, exactly where automated scanners do not look.

This case study is anonymized: no platform, vendor or identifiable component, and no request or value anyone could reuse.

Scope and authorization: under what terms did the audit take place?

The audit was an authorized black-box engagement using two user accounts created for the purpose, with no identity verification, and non-destructive tests. No real production data was modified, and test artifacts were cleaned up at the end.

The central technique is cross-account testing: account A creates an object, account B tries to read, change or delete it. It is the most reliable way to find authorization flaws, and it mirrors the position of an AI agent, which acts with the rights of the account that invoked it.

Rules applied: test orders cancelled and their status verified, fictional data, third-party identity-verification vendors out of scope (no document submitted to them), and a few fictional leftovers with no delete method flagged to the client for purging. One conditional order deliberately left armed on an unverified account is recorded in the report, along with how to read its outcome.

What we found: which findings, and how severe?

No critical finding, but three structural ones, two of which depend on a fact the test could not observe. The report says so: a conditional severity beats a false critical.

The three findings that matter:

1. API keys (medium, high in a financial context). A key is created with an open session alone: no password, no second factor, no alert email. It never expires, keeps working after the session is fully logged out, and a key can create further keys.
2. Negative-amount orders (medium proven, critical if executed). The server accepts and stores as active conditional orders whose amount and price are negative. Execution by the engine could not be observed within the test window.
3. Beneficial-owner files (medium+ proven, high if identifiers circulate). Two methods do not check that the supplied identifier belongs to the calling account. They allow reading a third party's information and generating valid identity-verification sessions on their file.

The attack chain: how does an ordinary account become a threat to the platform?

There are two conceptual chains, one on the account side and one on the trading engine side.

Chain 1: from temporary to permanent access.

1. The attacker obtains a victim's session by a classic means (injected malicious script, cookie theft, shared computer). Thirty seconds is enough.
2. With that session, they create an API key. No re-authentication, no alert.
3. They may create several spare keys, since a key can create others.
4. The victim notices, logs out everywhere and changes their password. The keys stay valid: the attacker keeps full, silent access to balances, the KYC file, recipients and history.

Survival after logout and key-creates-key were proven. Survival after a password change was not tested because it required a privileged session, but it follows from the architecture.

Chain 2: from a free account to the trading engine.

1. The attacker opens a free account. The conditional-order service even accepts unverified accounts, unlike the direct purchase service.
2. Validation error messages describe the exact expected schema: fields, types, constraints. They rebuild the order format in minutes.
3. They submit inconsistent orders, which the server stores as active for a year.
4. If the execution engine processes a negative order, the risk ranges from an absurd accounting entry to stalling the periodic job for every user.

No link is sophisticated. A stolen session becomes durable because of a convenience feature, and the absence of a trivial check opens the engine's integrity to any account.

What held: which controls worked well?

Many defenses held:

• Update and delete attempts on another account's files were all blocked, even if the response was sometimes an internal error rather than a clean refusal.
• Injecting a user identifier into requests was ignored: identity comes from the session.
• Mass assignment attempts (forcing a verified status or groups) were neutralized.
• Message, order and recipient lists were isolated by session; attachments returned a clean refusal.
• Forged, expired or unsigned tokens were rejected, CORS did not reflect the origin, and account enumeration through login failed.
• On the non-custodial wallet side, the recovery phrase stays in the operating system's secure storage and the backup is encrypted client-side.

Fixes: what to change, and in what order?

The plan is ordered by urgency and effort:

• 24 to 48 hours: server-side validation of the sign and consistency of amounts and prices, a database constraint, purge of inconsistent orders; ownership checks on the two file methods, removal of the default record returned to everyone, invalidation of the old session on regeneration.
• This week: re-authentication and a second factor to create a key, invalidation of keys on global logout and password change, no key creation with a key, expiry, read-only by default, email notification; uniform refusals; atomic creation of recipient and order; email anti-spoofing policy moved to quarantine, then reject.
• This month: security headers, generic validation messages, stronger password policy and key derivation for the backup, masking of sensitive screens, retirement of the legacy app.

What it means for an AI agent: what happens when an assistant acts on a trading account?

An AI assistant acting on a trading or payment account with the user's token inherits every authorization gap in the API. The model does not know an identifier belongs to someone else, or that a negative amount is absurd.

Three concrete consequences:

1. Authorization flaws become actions. If a method accepts a third party's identifier, a prompt injection in a message, document or web page is enough to push the agent into calling it. The attacker no longer needs to steal an identifier: the context supplies it. This is the scenario behind OWASP's "Excessive Agency" category for LLM applications.
2. Persistent access survives remediation. An agent that can create an API key, or a tool that exposes that method, hands an attacker exactly chain 1: the incident looks closed after logout while a parallel access exists. Access-creation capabilities must be excluded from the agent's scope.
3. Validation must live outside the model. Positive amount, ceiling, list of known destination addresses, delay before execution: these rules run in a deterministic controller between the agent and the API, and cannot be negotiated in a prompt. Every payment or order action also requires explicit human approval, shown with the real parameters of the action rather than the model's summary.

That is precisely the role of an action layer between what the model proposes and what the system authorizes. Our guide to AI agent security details the approach, and the AI agent red teaming page explains how we test it. The same pattern appears in the n8n webhook case study and the Supabase paywall case study: a side door never tested as a door, bypassing the protections of the main entrance.

To go further: the article on BOLA and IDOR in APIs, the one on human-in-the-loop for agent actions and the one on excessive agency.

Result: what to take from this audit?

The platform had no critical flaw and good isolation between accounts, but three mechanisms born of convenience or business-logic laxity (durable API keys, no sign check, identifiers not tied to an owner) created real attack paths. Fixing them takes a few days of targeted development.

For any organization planning to plug an AI agent into a financial API, the starting rule is to test the API first as if the agent were a hostile user: two accounts, crossed identifiers, aberrant values, persistent access. The Agent Red Team Express covers that scope in five days for €1,900.

Other case studies

• n8n webhook: admin accounts opened
• Supabase paywall bypassed in two requests
• AI writing SaaS application
• Restaurant: back office opened by a forgotten file