Independent evidence that your AI agent is safe to run in production.

A four-week controls review of a live agentic platform, against thirty controls in six areas. It ends in a board paper with a go-live opinion and a one-page Statement written for supervisors and insurers.

Example Statement, illustrative figures

Who it is for

You are a board, an MD, or the Senior Manager whose name is on the AI system, and a team wants to put an agent into production. It will read documents, call systems and take actions on the firm's behalf, faster than anyone can review.

You have a policy that says a human is in the loop. You want to know, independently, whether the platform does what the policy says.

We work mostly with regulated UK financial services firms, where SMCR accountability, Consumer Duty and operational resilience expectations make the question sharper. The method applies to any firm running agents under UK GDPR.

It's 2am. Your agent has just made its four hundredth decision of the hour. Who's watching?The human in the policy went home at six. What is controlling the agent now is code and configuration, and that is what nobody has checked.

What the Health Check tests

Thirty controls in six areas. Every one is tested against the running platform, not the document, and graded Verified, Partial, Not evidenced or Contradicted, with the artefact that proves it.

Reasoning

Is model output treated as a proposal that must pass a check before anything runs, or does it execute directly?

Tools

Does each agent have the minimum access its task needs, with read and write separated and credentials that expire?

Runtime

Are budgets, sequencing, logging and loop detection enforced by deterministic code, or by asking the model to behave?

Oversight

Is there a named person who owns the runtime policy, reads the logs, and has a kill switch that has actually been pressed?

Data

What personal and confidential data does the agent see, where does it go, and can it leak through the agent's own output?

Supply chain

What does the platform depend on that the firm does not control, and what happens when that changes or fails?

Two tests are done live

We press the kill switch in production, under written authorisation, with the named non-engineer operating it. Rehearsed in staging first. Then we measure.

Time to haltSeconds from press to the last new action attempt
Actions after pressIn-flight calls that finished anyway
Orphaned stateRuns left half-done with no record of the halt
Restart timeSeconds to the first healthy run

We plant harmless canary instructions on every surface the agent reads: documents, email, web pages, tool results, other agents, memory. Five classes of payload. We record whether each one was stopped before the model, stopped after it, or executed.

The class that reaches production undetected is parameter tampering: the right action with a poisoned value. A gate that checks which tool is called will pass an invoice for 4,850 when the real figure is 485.

  • Command. Do something the task did not call for.
  • Parameter tampering. The right action with a poisoned amount, account or recipient.
  • Exfiltration. Put data from the context into a reply, summary or log.
  • Delayed. Planted now, triggered on a later run.
  • Modality. Hidden in an image, a PDF layer, metadata or an encoding.

Four weeks to a board decision

About eleven days of our time and a few hours of yours. The board date is fixed at scoping and the plan works back from it.

  1. Week 1Scoping, access, testing authorisation. Your platform owner completes the free Readiness Check so we have a record of what the firm believes.
  2. Weeks 1 to 2Automated inventory of every agent, tool, credential and external system. Code walk. Log sampling. Owner session, held after the inventory so answers are tested against what we found.
  3. Weeks 2 to 3Injection testing. Fault, loop and provider-outage tests in staging. Kill switch rehearsal in staging, then production.
  4. Week 3Draft findings to the platform owner for factual correction only. Board paper written. Readout to the sponsor.
  5. Week 4We present to the board or risk committee. Twenty minutes. The board records the go-live decision and the remediation owner.

What the board receives

Four pages, presented by the assessor. Everything else is appendix.

Page 1

The decision

Go-live opinion, believed against verified score, the kill switch result in one line.

Page 2

Three things to fix

Severity, what each means for the business, an owner and a date.

Page 3

Loss scenarios

Which losses this platform can trigger, and which are bounded today.

Page 4

The Statement

One page in a fixed format, readable by a broker, underwriter or supervisor on its own.

Behind the four pages: a scorecard with an artefact reference for every grade, a findings register, a 90-day remediation plan, a standards annex mapping every control to ISO 42001, NIST AI RMF, OWASP and UK regulation, and the injection test report.

Download the one-page board briefing (PDF)

What it is

  • A point-in-time controls review of one platform, as scoped.
  • Independent. We fix nothing during the review, and severity and the go-live opinion follow published rules, so they cannot be softened for a client who might buy remediation.
  • Backed by an evidence pack a second assessor could re-grade.

What it is not

  • A certification or a warranty.
  • An assessment of whether the agent is good at its job, or whether the model is biased.
  • A review of your cloud estate beyond what the agents touch.
  • A sales pitch for remediation. Anything we offer afterwards is a separate engagement you are free to place elsewhere, and the 90-day re-test can be done by another assessor.

Time and cost

Fixed fee for a single platform of up to five agents, quoted at scoping. Larger estates are scoped as more than one check. The 90-day re-test is a fraction of the original.

Start with what your firm believes

The Readiness Check is twenty questions, ten minutes, no registration. It records what your firm believes is true about its controls. The Health Check tells you which of those beliefs hold.

Questions boards ask

We already had a penetration test.

Good. A pen test checks whether someone can get into your systems. This checks what your agent can do once it is already inside, on purpose, with the credentials you gave it.

Our model provider says the model is safe.

The model is not the platform. The review is about what your runtime lets the model's output do, which is entirely in your control and entirely your accountability.

Can we do this before the platform is built?

Partly. The Readiness Check works at design stage. The Health Check needs a running platform in staging; the earlier in the build, the cheaper the findings are to fix.

Will you sign something an insurer can rely on?

The Statement is written for that audience, states its limits, and is backed by the evidence pack. Reliance terms are set out in the engagement letter.