Build a Defensible Trust Product by Turning Scammers Into Data: The Apate.AI Adversarial AI Wedge

CBA has run more than 2.5 million autonomous conversations with threat actors and extracted over 250,000 intelligence artifacts. That is the kind of number that makes a fraud product less like a detector and more like an operational surface.

A detector is a reasonable first instinct, but it is a familiar wedge. In practice, it may be evaluated against other AI security features, rules engines, and vendor promises of fewer false positives. The harder-to-copy product is one that gives the institution countable attacker behavior: minutes, artifacts, and loss outcomes.

Apate.AI raised an $11.4M seed round led by Lobby Capital. The round was described as among the largest seed rounds for an Australian security startup, in the top 1% of 134 comparable deals. The funding is earmarked for international expansion and platform development. The raise and US move are being framed as a signal of investor interest in offensive fraud defense.

The global scam industry costs around $1.4 trillion a year. That number is too large to be useful on its own. The founder question is narrower: which fraud surface is expensive enough, frequent enough, and attacker-initiated enough that an institution will pay to count the attacker's time and artifacts?

The product is a controlled adversary

Apate uses voice and text AI agents that mimic victims. The key word is controlled. The stated job is to waste the fraudster's time and extract intelligence for the institution.

The CBA figures show the scale of the engagement. A detector tells you what happened. A controlled adversary gives the institution a way to spend attacker time and collect artifacts.

There are trade-offs. This approach works best where the attacker initiates contact and the institution can safely simulate a plausible target. It is less useful for purely internal, purely transactional, or non-conversational fraud. It also raises data retention, privacy, legal review, and escalation risk. At CBA's scale—2.5 million conversations and 250,000 artifacts—those questions would require a latency or handoff threshold for when the agent stops engaging, a privacy review step for retained artifacts, and an escalation path when a real customer may be at risk. A founder who ignores those questions will build a demo, not an enterprise product.

The Adversarial Trust Wedge checklist

1. Choose a high-cost fraud surface

Pick a surface where the institution already has a measurable pain: voice phishing, account takeover, customer support impersonation, social engineering, or fraud that moves through a call or chat channel. The surface should have three properties: attacker-initiated contact, a clear loss metric, and enough volume to justify autonomous engagement.

If the fraud is rare, the loss is small, or the attacker is already well understood, the wedge is thin. The product is not a better alert. It is a way to count attacker time and artifacts.

2. Simulate attacker behavior with voice or text agents

The agent should not be a generic honeypot. It should behave like a plausible victim or customer: confused, impatient, occasionally helpful, and constrained by the institution's policy. The goal is to make the attacker spend time on a simulated target and produce artifacts the institution can use.

Build the narrowest useful persona first. A bank customer about to approve a transfer is more useful than a universal victim model. A support representative about to share credentials is more useful than a broad social-engineering bot. The narrower the persona, the easier it is to measure, deploy, and turn into actionable intelligence.

3. Measure attacker time, fraud loss, and intelligence yield

Do not lead with 'AI detected more fraud.' Lead with operational metrics. Attacker time is the first one: how many minutes did the scammer spend on the simulated target? Fraud loss is the second: did the attack convert, partially convert, or fail? Intelligence yield is the third: what new scripts, phone numbers, domains, payment instructions, or behavioral patterns did the engagement produce?

For an institution, the value is not a single artifact. It is the rate at which the attacker model improves. If a bank can show that a voice scammer spent extra minutes on a simulated customer and that engagement produced new call patterns, the budget conversation changes.

4. Sell to institutions as countable outputs and loss metrics

A practical procurement metric is minutes of attacker time per month, intelligence artifacts per quarter, or cost per prevented loss on a named fraud surface. The CBA figures show why those metrics are concrete: 2.5 million conversations and 250,000 artifacts are countable outputs.

A practical framing is: this gives the institution a countable way to defend a specific fraud surface and document what the attacker did. That is a stronger wedge than 'we use AI to detect fraud.' It is also easier to defend in a procurement review.

5. Expand by productizing the attacker model, not the alert

The durable asset is not the first dashboard. It is the evolving model of how attackers behave across conversations, channels, and institutions. Once you have enough engagement data, the product can expand from one fraud surface to adjacent ones: from voice scams to account takeover, from customer support impersonation to employee social engineering, from one bank to a network of institutions.

The alert is a byproduct. The attacker model is the durable asset. If your product only improves when a new fraud type appears, you are building a feature. If it improves because it has seen more attacker behavior than most, you are building infrastructure.

What this means for founders

If you are building B2B trust infrastructure, fraud, identity, or customer-safety products, the wedge is not to out-detect the competition. It is to make the fraud surface easier to count, document, and defend. Start with one high-cost surface, deploy a narrow adversarial agent, measure attacker time and intelligence yield, and sell the result as countable outputs plus loss metrics.

A generic AI security feature is easier to copy. A product that produces countable attacker behavior is harder to copy. The test is simple: if you cannot report attacker minutes, artifacts, and prevented loss for a named surface, you are selling a detector, not an adversarial trust product.

This article is general information, not investment or legal advice.