We test and attack AI agents before they touch anything that matters: client money, client data, production systems. Independent audits, built for regulated finance first.
We never declare an agent safe. No serious auditor does. We attest: tested against these attack classes, against this standard, on this date. Here is what broke. Here is what held.
The board’s question is fair. How do we know the agent will not pay the wrong person, leak client data, or obey a hostile email? Whoever answers that question should not be the team that built the agent, and should have nothing to gain from a pass. We answer it, independently. That is what gets an agent out of pilot.
There is no independent, attestation-grade auditor of agent deployments for EU regulated finance.
You cannot certify a language model. You can audit everything built around it: permissions, spend limits, approval gates, logs. And you can prove whether they hold under attack. The gate review does that in three days; the full audit takes each day deeper.
What can your agent read, write, spend, and send? We draw the complete map: every tool it can call, every permission it holds, every human approval it must clear, and what its logs would actually prove.
We attack everything the map shows, under written authorization: hostile documents, poisoned tool outputs, attempts to exceed its authority, and every path that could move data or money out.
Every result becomes a finding: what broke, what held, how to reproduce it, how to fix it, which standard it maps to. Written to be forwarded to your risk committee without us in the room.
Scope is declared in writing before testing starts: which agent, which version, which tools, which attack classes. The report states what the days found and where testing stopped.
Gate review · Report excerpt
Fictional sample
| ID | Finding | Severity | Class |
|---|---|---|---|
| GR-01 | Indirect prompt injection via hostile PDF drafts an attacker-directed payout | Critical | AF-01 |
| GR-02 | Spend and authority limits are prompt-level only, not externally enforced | Critical | AF-04 |
| GR-03 | Action log is writable by the agent’s own service account; not tamper-evident | High | AF-10 |
| none | What held: payment execution was outside the agent’s reach. A manual treasury approval stopped the drafted payout. Tested and held. A single human approval is currently the only barrier. | Held | none |
Every engagement is scoped to your system and quoted on a call; every price is fixed before we start.
3 days · paid upfront
For deployers
The three days above, run on your agent in your environment. You get the findings, the fix list, and the mapping to your regulatory obligations. Small enough to skip the procurement cycle, and credited in full against a full audit signed within 90 days.
Scoped on a call
For deployers and vendors
Each day expanded to the full attack surface, plus a review of the controls around the agent. Reported against external standards: AIUC-1, a certification standard for AI agents; ISO/IEC 42001; EU AI Act readiness. Findings are built to be the evidence an insurer will ask for.
For agents with payment authority, the policy-engine audit: is there any sequence of inputs that moves funds outside the declared limits?
Scoped on a call
For AI vendors
Selling an agent into enterprises means months in security review. We build the evidence pack that shortens it, mapped to the standards the buyer’s procurement team already recognizes, so procurement stops being where deals die.
Typically two weeks
For investors
Is the AI real, and what breaks under attack? Answered in a fixed scope: architecture review, verification of the target’s technical claims, and adversarial spot-testing.
Quarterly
After the audit
Quarterly re-testing keeps an attestation current; AIUC-1 mandates it. For clients in regulated finance, the testing follows the threat-led exercises their regulators ask for by name: the TIBER-EU and DORA TLPT tradition, extended to AI agents. Incident-response standby is quoted separately.
These classes cover the ways agents fail under attack and in operation. Every finding is tagged with one and maps to the standards named above: public yardsticks, set by others.
| ID | Class | Definition |
|---|---|---|
| AF-01 | Prompt injection | Untrusted content redirects the agent’s behavior against the operator’s intent. |
| AF-02 | Tool / MCP supply-chain compromise | A tool, plugin, or MCP server the agent trusts is malicious, compromised, or silently changed. |
| AF-03 | Excessive agency / authority escalation | The agent holds, acquires, or is manipulated into using more authority than the task requires. |
| AF-04 | Spend-limit / policy-engine bypass | Financial or action limits are advisory in the prompt rather than enforced outside the model. |
| AF-05 | Data exfiltration | The agent is induced to move sensitive data outside its authorized boundary. |
| AF-06 | Unsafe action chaining | Individually permitted actions compose into a harmful outcome no single step would flag. |
| AF-07 | Hallucinated actions | The agent invents tool calls, parameters, recipients, or facts and acts on them. |
| AF-08 | Memory / context poisoning | Persistent memory or retrieved context is corrupted so future runs inherit hostile instructions. |
| AF-09 | Human-gate circumvention | An approval step exists but can be skipped, spoofed, fatigued, or rendered meaningless. |
| AF-10 | Logging / audit-trail gaps | The record of what the agent did is missing, incomplete, or tamperable. |
Taxonomy v1 (2026), summary view. Sub-vectors, passing-control definitions, and clause-level standard mappings are engagement material, shared on request.