Risk Decisions in the Era of AI: What Happens When the Subject Fights Back?

AI agents are transforming risk and compliance operations. At Unit21, our AI Agents now handle what used to require entire analyst teams: pulling entity data, running adverse media checks, reviewing transaction patterns, and generating SAR-ready narratives. Investigations that took days now take minutes.

‍

That capability comes with a responsibility we take seriously. The more consequential your AI's decisions are, the more important it is to understand where it can be manipulated.

‍

Earlier this year, we engaged Doyensec, a specialized security engineering firm, to conduct a full security assessment of the Unit21 platform. Our AI Agents were explicitly in scope. What their researchers found reshaped how we think about a category of risk that the fraud and AML industry hasn't fully confronted yet.

‍

The Threat Model Nobody Is Talking About

Traditional application security asks: can an external attacker access data they shouldn't? Can they escalate privileges? Can they compromise the system?

‍

Those are the right questions. Doyensec tested for all of them.

‍

But a fraud and AML platform with native AI introduces a different threat model alongside the conventional one. The AI doesn't just process your internal data. It processes data about the subjects being screened. Names, entity records, transaction descriptions, and company profiles. Some of that data comes from your customers; some comes from onboarding flows; and in some cases, the subjects being screened have a direct incentive to make the investigation go a certain way.

‍

A sophisticated bad actor doesn't need to hack your platform. They can try to manipulate what your platform knows about them.

‍

What the Pentest Found

Doyensec's researchers identified that Unit21's Online Research task, which performs automated adverse media checks and counterparty lookups as part of an AI Agent driven case review, was building its search queries directly from entity fields without sanitizing them first.

‍

The specific mechanism was subtle. Search engines like Google use special characters to modify query behavior. A leading hyphen, for example, tells the search engine to exclude results containing that term. By inserting a hyphen into a name field in their entity record, an actor could cause the AI's adverse media search to suppress the most relevant results entirely and return information about unrelated people instead.

‍

Doyensec demonstrated this concretely during testing. They created an entity record for a well-known subject and prepended a hyphen to the last name. The Online Research Summary came back with no adverse media on that subject at all. Instead, it returned a profile of a completely unrelated person.

‍

From the AI's perspective, the investigation was complete. The narrative would have reflected a clean online research result.  We fixed this. Entity fields used to construct search queries are now sanitized before they reach the search engine, stripping characters that carry operator meaning. The issue is closed.

‍

Why Our Architecture Held Up

The search manipulation finding was real and is now fixed. The rest of Doyensec's prompt injection testing, and they tested extensively, found no end-to-end exploitable path. That result wasn't luck. It reflects a set of deliberate architectural decisions we made when building our AI Agents.

‍

The core principle: the more you can do deterministically, the smaller the surface area for AI manipulation.

‍

In practice, that means our AI Agents don’t operate as free-ranging tool-users. It doesn't write its own database queries. It doesn't independently decide which APIs to call or how to structure a search. Instead, we provide it with pre-computed aggregations and curated data surfaces, assembled by standard application code before they reach the model. The AI reasons over a carefully bounded context. It doesn't construct that context itself.

‍

This matters because the most reliable defense against prompt injection is reducing the number of places where attacker-controlled input can reach the model in a form that looks like instructions. When the data pipeline runs through deterministic code, a crafted string in a name field stays a string. It doesn't become a query. It doesn't become a tool call. It arrives in the model's context clearly delimited as data, and the model treats it accordingly.

‍

Doyensec's testing validated this approach. The theoretical injection path existed at the architectural level, and they correctly flagged the pattern. But the downstream impact was contained because the agent's tool access is constrained by design, not by prompt-level guardrails that can themselves be bypassed.

‍

The lesson we take from this: for AI agents operating in high-stakes environments, trust in the output requires trust in the input pipeline. LLM-level defenses matter, but they work best when the architecture has already reduced the attack surface to a minimum.

‍

What This Means for the Industry

AI agents in risk and compliance occupy a unique position. They're reviewing adverse media on people who may have strong incentives to appear clean. They're screening entities that understand, at some level, what the screening process involves. As AI automation becomes standard, the subjects of investigations will increasingly understand how those investigations work.

‍

Input validation has always been a foundational security principle. For AI-native risk and compliance platforms, the input surface extends further than it did for rule-based systems. Names, descriptions, and free-text fields that were previously just data are now potentially interpreted by a model that's making decisions. That changes what "sanitization" needs to mean.

‍

It also raises a question worth asking of any risk and compliance vendor: Is your AI component held to the same security standard as the rest of your platform? Is it in scope for your security assessments? Is your security program built for a world where the subject of an investigation is a potential adversary to your detection logic?

‍

How We're Thinking About AI Security

Commissioning this assessment was a deliberate decision. We rebuilt Unit21's platform around AI agents because we believe agentic AI is the only way to scale effective financial crime operations. That conviction doesn't mean AI introduces no new risks. It means we have to understand those risks clearly and address them.

‍

Doyensec's AI chatbot testing methodology, grounded in OWASP standards and adapted for LLM-specific threat classes, gave us a structured way to evaluate the attack surface we didn't have before. The findings from this engagement are already shaping how we architect data flows into the agent's prompt pipeline.

‍

We're publishing this because we think the conversation matters for the industry, not just for us. Every team deploying AI for financial crime should be asking hard questions about what happens when the data their AI reasons about has been deliberately shaped by the entity being screened.

‍

The AI agents are getting better. So is the adversarial environment they operate in.

‍