Security & assurance
The two questions a security team asks that most AI vendors answer vaguely. Ours are written down.
Published, not glossed over
Two more things your security team will ask, answered in full rather than gestured at — including the parts that are less flattering.
Who is in charge of the agents — the ownership charter+
The question that should worry you about AI agents isn't whether they're clever. It's what happens when two of them fix the same thing in opposite directions and nobody wrote down which was allowed to. We hit that. The fix was a ratified, version-controlled charter loaded by every agent that touches the system.
| Rule | In practice |
|---|---|
| One named owner per system | Exactly one agent is accountable for each machine's state. Written down, not remembered. |
| Authority is not transferable | No agent assumes another's authority or hands it onward. |
| Ask, don't reach | Agents request changes across a boundary. They never execute across one. |
| Verify, don't trust | Delegated work is checked by whoever dispatched it. An agent reporting its own success is not proof. |
| Least authority first | New connections start read-only — a grant is easy to widen and hard to withdraw. |
| Helpers hold no authority | Bounded work can go to other systems, including different tooling. Dispatched, never in charge. |
| One human decides | Disagreements escalate to a person. No agent settles a dispute unilaterally. |
| Classification travels with the work | A document's classification follows it through every step, including to helper systems. |
Read that list again and notice what it is: separation of duties, least privilege, change control, and data classification. The controls you already audit your own suppliers against — applied to the AI itself, in writing, before a regulator thought to ask.
What happens on a bad day — recovery objectives+
Every vendor's demo works. Under DORA, "what happens when it breaks" has a legal form.
| Scenario | Objective | How |
|---|---|---|
| A single service fails | Under 1 minute | Restarted in place; the rest keeps serving |
| A database is corrupted | Under 30 minutes | Restored from the most recent local backup |
| The machine is lost entirely | Under 2 hours | Rebuilt from bare metal against a written playbook |
| Maximum data loss | 24 hours | Full encrypted offsite backup, automated nightly |
| Maximum configuration loss | None | Rebuilt from source control |
Documented objectives, drilled quarterly against a separate machine. Note what gets drilled: nearly everyone takes backups and far fewer test that a restore works — the restore is the part we rehearse. When something does break it gets a written postmortem with a root cause and a fix proven by reproducing the failure.
This is a demonstration of the platform. The practice that designs, builds and hands it over — along with what that costs — lives on cplt.tech.