Understand where your AI controls could fail
A focused review of one AI workflow: what it can access, what it can change, where a person must approve an action and what evidence remains afterwards. You receive written findings and prioritised changes. This is an engineering review, not a compliance certification.
Service 03
No 17040048
Fixed price
£2,000
One day, fixed
Follow-on days at the same rate if the findings need hands, never assumed. Three reviews a month at most.
Who it is for
- Product teams and founders whose AI agents take real actions: sending messages, changing records, booking, paying or deploying.
- Teams that want to know what an agent may do, what it did, and whether its safeguards still hold after the next change.
- Agencies deploying AI for clients who need to show the controls around it.
What the work covers
Building the register
The day starts with a register of the one agent or workflow under review. We record who owns it, which model it uses, what data it can reach and what it can do. Actions are sorted into three groups: what it may do alone, what needs a person to approve and what it must never do. Writing this down is often where the first findings appear, because permissions granted for convenience during a build tend to outlive the reason they were granted. The register also gives everyone the same picture to work from, which matters more than any single control.
Tracing real actions
Next we take three real actions the agent took recently and follow each one from what the agent said it was doing to what actually happened in your systems. Did the record it claimed to update change? Did the approval it relied on cover the thing that went out? Could you reconstruct the action from your logs alone, without asking the agent? Tracing real actions is the quickest way to find the gap between what a team believes its controls do and what they do in practice, and it shows whether the evidence you would need after an incident exists today.
Checking that approvals match what ships
An approval is only worth something if it covers what is actually used. We look for the places where a check passes on one version of the work while a different version ships: a review of yesterday's branch, a test run against a stale file, a sign-off given before the final edit. This is the failure we found in our own pipeline, where a gate reported green for months while checking the wrong branch. It is quiet, easy to miss and usually invisible to ordinary monitoring, so it gets dedicated attention on the day.
Designing a control that survives the next change
Controls usually fail after a change, not on the day they are built. A model update, a new tool or a refactor shifts what the agent can do, and a safeguard written for the old shape quietly stops applying. In the afternoon we design a control that holds up to that: for example, a gate that refuses when what was approved no longer matches what is about to ship, which is the idea behind Slipmark. The design is specific enough for your engineers to build, or for us to build on a follow-on day if you want hands.
Findings ranked by exposure
By close of day you receive a written findings note: the register, the gaps ranked by how much harm they could cause and how likely they are to be reached, the control design and each decision with its reason. Ranking matters because most teams can act on a few changes at a time, and a long unranked list of concerns tends to produce no action at all. The note is written for both the engineer who will make the changes and the manager who has to decide what comes first.
What the review is not
It is an engineering review of one bounded agent or workflow, not a compliance certification. We do not map your controls to ISO 42001 or the EU AI Act, and we do not issue any certificate. Where UK GDPR, as amended by the Data (Use and Access) Act 2025, or sector rules look relevant, we note what we saw so you can take it to your advisers, and we are glad to work alongside them. What you get is a clear, evidenced picture of what the agent can do, which any later assurance work needs anyway.
What we look at
These are illustrations of the kind of work, not client results.
A support agent that edits records
What it can change, which changes need approval, and whether you could reconstruct what it did last Tuesday. Example only.
A coding agent that opens pull requests
Whether the checks that clear its work inspect what actually ships, or something that has since changed. Example only.
An agent that sends messages to customers
Where a person sees the message first, what it is not allowed to say, and how you would stop it. Example only.
What you get
The review works with whatever you run. Bring the logs, configuration and the person who knows how it was built. The findings are yours to act on with or without us.
- 01A register of the agent or workflow: owner, model, data it can reach, actions it may take alone, actions that need a person, actions it may never take.
- 02A trace of three real actions from what the agent asserted to what actually happened.
- 03A design for a control that survives the next change, such as a gate that refuses when what was approved no longer matches what ships.
- 04A written findings note by the end of the day, with every decision and its reason.
What changes
- A written register of what the agent may do alone, what needs a person and what it must never do.
- Evidence of whether three real actions did what the agent said they did.
- A ranked list of changes, so the team knows what to fix first.
- A control design meant to keep holding after the next model or code change.
How it runs
- Scope agreed in advance: one agent or workflow, the access needed and who is available.
- One working day at a fixed £2,000, on site or remote.
- Morning register, midday trace of three real actions, afternoon control design.
- Written findings note by close of day.
- Follow-on days at the same rate, only if the findings need hands.
What you supply
- Access to configuration, logs or traces for one agent or workflow, plus a person who can answer technical questions during the day.
- Three real recent actions the agent took, which we trace together.
- A clear boundary for the review: which agent, which workflow.
Limits
- One bounded agent or workflow per review.
- Not a compliance certification. We do not map controls to ISO 42001 or the EU AI Act, and we do not certify anything.
- Not for chatbots that only answer questions. If the AI cannot change anything, there is little to control.
- Practices running ReplyOS-style enquiry handling are usually better served by the enquiry recovery setup.
How it works
- 01
Scope
We confirm the one agent or workflow, the access needed and the person who will be available on the day.
- 02
Review
Morning: register. Midday: trace three real actions. Afternoon: design the gate.
- 03
Findings
A written note by close of day: the register, the gaps ranked by exposure, the control design and every decision with its reason.
- 04
Follow on
If the findings need implementation, follow-on days are available at the same rate. They are never assumed.
The incident behind the method
Evidence from our own work
The review comes from running our own agent pipeline. A security gate once reported green while inspecting the wrong branch, and no monitor caught it. When approval was bound to a hash of what was actually inspected, every open agent pull request failed the check. This is internal engineering evidence, not a client result.
How Slipmark worksWhere it fits
Teams usually arrive with an agent already running; where the findings point to wider gaps, assurance work extends the method across more systems, and monitoring checks that the controls keep holding.
Questions before you start
How much does an AI Control Review cost?
£2,000 fixed for one working day, on site or remote. Follow-on days are the same rate if the findings need implementation work.
Is this a compliance audit?
No. It is an engineering review of one workflow. We do not certify anything or map controls to a regulation. You get findings you can act on, not a certificate.
What do you need from us?
Access to the agent's configuration and logs, three real recent actions to trace, and a person who knows how it was built, available for the day.
Can you review an agent you did not build?
Yes. The review is about what the agent can do and what evidence exists, not who wrote it.
What is the next step?
Tell us which agent or workflow you want reviewed using the contact form. We confirm scope and book the day.
Is the review suitable for regulated sectors?
Yes, as an engineering input, not as a compliance sign-off. The review shows what the agent can access and change and what evidence exists, which is useful material for a regulated business. It does not replace your compliance function or legal advice. We note anything that looks relevant to UK GDPR, as amended by the Data (Use and Access) Act 2025, or sector rules, and work alongside your advisers.
What if our agent keeps no logs?
Then that becomes the first finding. Without logs or traces you cannot reconstruct what the agent did, which is a gap in its own right. We still build the register and trace what we can from other evidence, such as records changed in your systems or messages sent, and the control design includes the evidence the agent should leave in future.
How should we prepare for the day?
Choose the one agent or workflow, confirm access to its configuration and logs, and pick three recent real actions for us to trace. Make sure the person who knows how it was built can give us the day. If you have a permissions list, an architecture note or an incident history, send it beforehand, as it speeds up the register.
Tell us what needs to work better.
Describe the process and the tools involved. If it looks like a fit we will arrange a 20-minute call.