Standing coverage after a first engagement.
Continuous Assurance re-checks named assets every month and keeps the Serpio Atlas map of your system current. It starts only after a first paid engagement on your systems.
The baseline
Monthly re-checks on a bounded, named asset set.
The map
Every surface in scope, produced by the first engagement and yours to keep.
Not included
Novel classes and reverse engineering past source stay on scoped engagements.
Six cycles on one named baseline.
Continuous Assurance re-runs the agreed classes against named assets each cycle. The register below follows one bounded baseline across six cycles, including the cycles where something underneath it changed and coverage went backwards. Step through it to see the counts change.
0unmapped0mapped3tested4hardened4retested1outside the baseline7not proven closed
- Unmapped
- Mapped
- Tested
- Hardened
- Retested
- Reopened by a change
- Outside the baseline
Surface detail
Select a surface, click a cell, or press Enter on it, to read its six-cycle history and what changed underneath it.
Cycle register as a table: the same states, as data
| Surface | Type | Class | C1 | C2 | C3 | C4 | C5 | C6 | At close-out |
|---|---|---|---|---|---|---|---|---|---|
| support-triage | Agent · creds | AG1 | hardened | hardened | hardened | retested | retested | retested | retested |
| invoice-recon | Agent | AG1 | tested | hardened | hardened | hardened | hardened | retested | retested |
| http.fetch | Tool · creds | AG2 | hardened | hardened | tested | hardened | hardened | retested | retested |
| db.query | Tool | AG2 | mapped | tested | tested | hardened | hardened | hardened | hardened, not retested |
| mcp/inventory | MCP server | AG2 | tested | hardened | hardened | hardened | retested | retested | retested |
| mcp/browser | MCP server · creds | AG2 | tested | tested | tested | hardened | hardened | hardened | hardened, not retested |
| svc-tool-broker | Identity · creds | AG2 | hardened | hardened | tested | tested | hardened | hardened | hardened, not retested |
| oauth-app-crm | Identity | AG2 | mapped | mapped | tested | tested | hardened | hardened | hardened, not retested |
| rag-corpus | Data path | LLM01 | hardened | hardened | hardened | retested | tested | tested | tested, still open |
| vector-index | Data path | SC1 | mapped | tested | mapped | tested | tested | tested | tested, still open |
| pdf-parser | Native binary | RE1 | outside | outside | outside | mapped | tested | tested | tested, still open |
| fw-updater | Native binary | RE1 | outside | outside | outside | outside | outside | outside | outside the baseline |
| Hardened or better, in the baseline | 4 | 6 | 4 | 7 | 8 | 8 | - | ||
| Reopened in this cycle | 0 | 0 | 3 | 0 | 1 | 0 | - | ||
| Not proven closed at this cycle | 10 | 10 | 10 | 9 | 9 | 7 | - | ||
Illustrative example, not client data. Rows marked creds hold live credentials; a caution tick marks the cycle where a surface moved backwards.
Retainer coverage derived from what you already proved.
After a first paid engagement, we agree the named asset set, and re-checks run monthly. The retainer then re-checks closed paths, and whether recovery and degradation still hold, as agents, tools, and binaries change.
Monthly re-checks on named assets, inside a written baseline.
The map of the reviewed system, which every re-check runs against.
What a cycle looks like.
Each cycle has the same shape, so you know what is being re-checked, what changed, and what is still open.
The agreed attack classes are re-run against the named assets. A clean run still produces its coverage record, so a result with no findings is on record.
Agents, tools, identities, and binaries move between cycles. New surface enters by a scope amendment, so the asset set stays accurate.
Open findings carry a current disposition, fixed, mitigated, accepted, or deferred, each with a named owner. Only a retest confirms closure.
One written cycle report: what changed, what was re-checked, what moved, and what stays open.
At term, the assets, the findings, and the map are handed back in their current state.
Unreviewed dependency bump
Open
The change lands in your build with nothing watching it. The paths it touches stay unverified until the next monthly run reaches them.
Tool or MCP schema change
Checked
Change intake detects it, and the affected surfaces reopen for retest: the http.fetch caution tick on cycle 3 of the register. Checked means detected. The change still shipped; the retainer's job is to notice it and re-prove the path.
Identity or key rotation
Gated
The paths it touches are re-scoped and re-proven before a monthly run is allowed to count them as covered again.
Illustrative example, not client data. Nothing here reads your CI, your registry, or your keys: the register is re-run against the named assets, and intake is how a change gets onto the list.
Where coverage goes backwards.
Four surfaces moved backwards inside those six cycles because something underneath them changed. Each one needs a re-check before it counts as covered again. Three of these four reopened surfaces were not proven closed at the end of the term; the full list of seven open surfaces is below.
| Surface | State | What changed underneath it | Cycle | Class |
|---|---|---|---|---|
| http.fetch | hardened → tested | The tool's schema changed under it. The hardened path is unverified until the class is re-run. | Cycle 3 | AG2 |
| svc-tool-broker | hardened → tested | The service identity's scope widened for a new tool, so what it is allowed to do is retested. | Cycle 3 | AG2 |
| vector-index | tested → mapped | The index was rebuilt on a different embedding model. Provenance was reopened. | Cycle 3 | SC1 |
| rag-corpus | retested → tested | The retrieval corpus was replaced. A finding proven closed is unverified until it is re-run. | Cycle 5 | LLM01 |
Not proven closed at close-out.
Hardened means a control is in place. Only a passing retest proves the path closed.
Tool · AG2. Hardened at cycle 4, not retested before close-out.
MCP server · AG2. Hardened at cycle 4, not retested before close-out.
Identity · AG2. Reopened at cycle 3 when its scope widened, hardened again at cycle 5, not retested before close-out.
Identity · AG2. Hardened at cycle 5, not retested before close-out.
Data path · LLM01. Reopened at cycle 5, when the retrieval corpus was replaced. It was not re-run before close-out.
Data path · SC1. Reopened at cycle 3 on a new embedding model and re-run at cycle 4. It is still at tested at close-out: only a control change, then a passing retest, moves it on.
Native binary · RE1. Entered the baseline by a scope amendment at cycle 4, after reverse engineering on a scoped engagement. Its known path is re-run each month; it is still at tested at close-out.
The retainer is bounded, and we say where.
The baseline is a senior-led monthly re-check of named assets. Open-ended access and support stay outside it.
| Item | In the standing baseline | Not in the baseline |
|---|---|---|
| Asset set | Named assets, agreed before the first cycle. | Anything outside the named set. It enters by a scope amendment. |
| Attack classes | The agreed classes, re-run each month. | Novel classes and new research. |
| Schedule | Monthly. | Deeper work, time-boxed and scoped. |
| Access | Bounded by the named asset set and the monthly schedule. | An open-ended engagement. |
| Support | Not included. | Rebuild and harden, on a scoped engagement. |
| Past source | Known paths through a binary already reverse-engineered on an engagement. | Reverse engineering a new binary, as a scoped engagement. |
A first engagement, then the retainer.
Engagement shapes are on Services; method and threat vocabulary are under Resources. The register on this page starts from what the first engagement already proved.
The team that built a system is the wrong team to prove it safe. That takes an outside adversary accountable for the result.
Ask about standing coverage.
Available once we have completed paid work on your systems.