Know what your AI is allowed to do.
An AI workflow that sends messages, changes records or books appointments is no longer only answering questions. It is acting. Acting needs a clear list of what it may do, a person in the loop where it matters, tests before it goes live, and evidence afterwards.
Five questions about any AI workflow.
- 01
Permissions
What can it access and change?
A written register of the workflow: who owns it, which model it uses, which data it can reach, which actions it may take alone, which need approval and which it may never take.
- 02
Human review
Where does a person approve?
Approval points placed where a mistake would matter, such as before a message is sent or a record is changed, with a clear way for a person to take over.
- 03
Testing
What was tested before it went live?
Named test cases, including the awkward ones and deliberate failures, run before the workflow touches live work and again after changes.
- 04
Change controls
Does the safeguard still hold after the next change?
A check that an approval still matches what ships, so a safeguard does not quietly stop working when the software changes.
- 05
Evidence
Could you reconstruct what it did?
A record of what the workflow did, to which record, whether it was approved by a person, and what it cost, kept so a result can be traced back to the action that produced it.
Trace the result back to the action that produced it.
- In ReplyOS, a booking recorded against an enquiry is linked to the message that started it. The figure can be checked message by message rather than taken from a dashboard.
- In Slipmark, an agent's verdict is bound to a SHA-256 hash of the exact files it read. If anything changes, the gate refuses and nothing ships.
- Both apply one idea: do not accept a claim without a link to the evidence behind it.
What is implemented, what is configurable and what is planned.
This is the line between what runs today and what does not. The list is kept short on purpose, and it applies to the company's own systems. We do not claim controls that are not running.
Implemented and running
04- Attribution in ReplyOS: each recovered booking is linked to its source message.
- The Slipmark gate inside the ReplyOS pipeline, with behavioural locks for tenant isolation, inbound enquiry capture and email threading that an agent cannot waive.
- Slipmark released as an open-source GitHub Action, v0.2.0, under the Apache-2.0 licence.
- Human handover in ReplyOS where a person needs to take over an enquiry.
Configurable per project
03- Approval points before messages are sent or records are changed, set up as part of an implementation.
- Test cases and failure handling agreed in the quote for each workflow.
- A written register of the workflow, produced during an AI Control Review.
Planned, not yet available
03- An agent register and action ledger inside ReplyOS, starting with its own agents.
- A per-practice page showing which AI acts on its behalf, generated from that ledger.
- A paid layer for Slipmark: hosted dashboard, evidence reports, team policies and setup help.
We do not map controls to ISO/IEC 42001, NIST AI RMF or the EU AI Act, and we do not certify anything. A review is an engineering assessment, not a compliance certification.
Start with one workflow.
The AI Control Review looks at one agent or workflow for a fixed £2,000 and ends in written findings. If you would rather have the controls built into a new workflow, that is part of an implementation.