Test the systems you already run.
We test your applications, APIs, pipelines, infrastructure and vendor binaries as an adversary would. Where models and agents are part of that system, we test their permissions and integrations in the same engagement.
Most of an estate is unmapped, and the AI path runs through it.
The grid below shows 96 surfaces in the shape of an existing estate: applications, pipelines and CI, datastores and data paths, standing identities, vendor and native binaries, and the AI components now sitting on top of them. Most cells have no coverage record, which is the usual starting position. The few that hold credentials decide how far a steered agent can reach.
Coverage grid. Use the arrow keys to move between surfaces, Home and End to jump to the start or end of a row, Control with Home or End to jump to the corners of the grid, Enter to select a surface, and Escape to clear it. The same coverage is also available as a table below the grid.
96surfaces
whole estate
86 of 96 surfaces are untested; 74 have no coverage record at all. 3 have been hardened, 1 has been retested and proven closed, and 11 hold credentials.
Surface detail
Select a surface, click a cell, or press Enter on it, to see what it is, which finding class applies, and where coverage stands.
Accessible summary: the same coverage, counted
| Surface class | Surfaces | Unmapped | Mapped | Tested | Hardened | Retested | Holds credentials |
|---|---|---|---|---|---|---|---|
| Applications | 16 | 13 | 2 | 1 | 0 | 0 | 2 |
| Pipelines and CI | 16 | 14 | 1 | 1 | 0 | 0 | 2 |
| Datastores and paths | 16 | 13 | 1 | 1 | 1 | 0 | 1 |
| Standing identities | 16 | 12 | 3 | 1 | 0 | 0 | 4 |
| Native binaries | 16 | 14 | 1 | 0 | 1 | 0 | 0 |
| AI components | 16 | 8 | 4 | 2 | 1 | 1 | 2 |
| All surfaces | 96 | 74 | 12 | 6 | 3 | 1 | 11 |
Illustrative example, not client data. The five states are the Serpio Atlas states; the credential mark means the surface holds permissions a steered agent could borrow.
AI changes the attacker’s surface on systems you already trust.
The new risks are weak model and weight provenance, third-party binaries you cannot see inside, and authority boundaries that leak once an AI component is steered. We attack those paths, then harden what breaks.
Secure design review against your own threat model, including recovery and degradation when an agent fails or is steered wrong.
Scoped adversarial testing across AI and the surrounding software stack, with reverse engineering when risk sits past source.
Findings you can put in front of a board or auditor. Framework mapping lives on the Assurance page; we do not claim to make you compliant.
Where AI changes a system you already run.
None of this requires a rewrite. We find where an AI component widens reach that used to be limited, then close it. Each row links to the matching cells on the estate grid above.
A model or agent is added to a workflow that already had credentials. The model inherits those permissions, and the control that used to limit the action was never designed with a model in the chain.
Retrieval, tool results, and uploaded documents become instructions. Content the system already treated as data now influences what it does.
Vendor components, adapters, and toolchains arrive without source on the same path as your data. Reading the path past source means reverse engineering it.
Recovery, backup, and degradation behavior were designed for a system that fails predictably. An agent steered wrong fails differently, so we test those paths alongside the rest.
Agents write code faster than any review queue can read it. The approve click gets cheaper as the queue grows, and generated code inherits the credentials of the pipeline that produced it. We test what gets through at that speed, starting with those credentials.
Findings are ranked by blast radius, so the first fixes are the ones that close the most reach.
Agent → toolAG1 · AG2
Open: Nothing sits between the agent’s identity and the tool. Whatever the agent is persuaded to call, it can call.
Checked: Calls are logged and rate-limited. The call still lands.
Gated: The crossing needs a scoped, short-lived credential the agent does not hold. The call fails closed.
Vendor binary → data pathRE1 · SC2
Open: The binary reads and writes on the same path as your data, and nothing in the flow inspects what it does.
Checked: The binary’s behavior is observed but not restricted. A substituted or updated build still gets through.
Gated: The binary runs against a narrow interface with no reach past the one function you asked it to do.
Retrieved content → modelLLM01
Open: Text that arrived as data is treated as instruction. Content you already trust decides what the model does.
Checked: Injection attempts are flagged in the trace. The turn that acted on them still completed.
Gated: Content reaches the model with its provenance attached, and anything that could act is held for review.
Illustrative example, not client data. Checked means the step was logged or flagged and still ran; gated means it could not run without the control.
What you get back.
- 01Findings report
Every finding with the path it took, its rating, the steps to reproduce it, and the change that closes it.
- 02Executive summary
What was tested, what held, and what to fix first, written for the person who approves the fix.
- 03Evidence bundle
The record behind each finding, pinned to the run that produced it, so your team can replay it without us.
- 04Atlas map
The machine-readable map of every surface in scope. You keep it, and the next engagement starts from it.
Each fix comes with acceptance criteria, or as the change itself when we pair with your engineers. The evidence bundle is produced even when the engagement finds nothing.
First move per surface class.
| Surface class | First move | Classes that live here | Covered by |
|---|---|---|---|
| Applications | Map the credential each application holds, then test the path that reaches it. | LLM01, AG2 | Adversarial testing |
| Pipelines and CI | Trace what the deploy identity can touch, and what runs unreviewed. | AG2, SC1 | Secure design review |
| Datastores and data paths | Follow untrusted content from ingestion to the model turn. | LLM01, SC1 | Adversarial testing |
| Standing identities | Read the permissions each service account, key and certificate actually carries. | AG2 | Secure design review |
| Native binaries | Reverse-engineer what ships without source, in the same engagement. | RE1, SC2 | Binary reverse engineering |
| AI components | Test the reach the agent actually has, and the content it already trusts. | AG1, AG2, SC1 | Adversarial testing |
Bring an existing system.
We will tell you how an adversary would attack it, AI included, and what to harden first.