How to read the status labels
Every capability on this page carries one of three labels:
- Built: working in our development build.
- In build: partly working, and being finished for release.
- Planned: specified, and next in line to build.
Where client data lives
We process your clients' content on hardware your practice controls. You can host it in two ways:
- On local hardware in your practice. The Cast & Rule agent and the AI model both run on a machine you own. Built. (The agent runs on macOS today. Windows isn't supported.)
- The whole system on your machine. In the first release, the screens, the AI, the Ledger and client records all run on the practice's machine, and a fully local install keeps working if your internet goes down. Planned.
The agent starts the connection to our service itself. It won't accept incoming task connections. Built. Other services on the machine need their own protection.
Our own service sends instructions and shows your Desk. It holds only what it needs to run the work: the state of each job, the machine's public identity and a fingerprint of your Ledger. It doesn't store your clients' documents, figures or correspondence. Built. But results that your Rules allow to leave the machine may still contain client information. The next section explains who can read them.
If you allow a cloud model. You'll be able to turn on a more capable cloud model for work your Rules allow, through a controlled route. It would be off by default, and it would never switch itself on. The product will never quietly fall back to a cloud model when the local one is busy or unavailable. Before any text goes to a cloud model, names, NI numbers, UTRs, sort codes and company numbers are swapped for placeholders on your machine, and the text is checked again just before it's sent. The answer is swapped back on your machine. The key that links placeholders to real values never leaves it, and is destroyed with the client's key. Anything marked sensitive stays on your hardware automatically. Planned. Pattern-based checks for personal data on the machine are Built today.
Who can see client data
Your people, under your Rules. Your firm's AI-use policy becomes Rules. They work as guardrails, not just a policy filed away as a PDF. They decide which tasks can run, and against which folders and sources. The agent sends the operational metadata and results your Rules permit. A job can ask for less than your Rules allow, but it can never ask for more. Task-permission controls limit what the agent can do. Built. Full agent connection controls are In build; other apps are outside their scope.
Each client kept apart. Each client's work sits in its own compartment, the Strongroom. Local processing is Built. Client isolation and the Strongroom's encrypted client stores are Planned.
Us. Authorised results may contain client information. Result encryption is In build. In today's development build, we hold the decryption keys, so we can access those results. Practice-only decryption is Planned. We're telling you plainly, because you need to know it before you rely on it.
Not for training. Cast & Rule doesn't use your clients' data to train AI models. The full statement of what we never use for training is Planned.
Built on proven, open components
The controls are ours. The cryptography, policy language and detection components under them are well-reviewed open source and open standards, under permissive licences such as MIT and Apache-2.0. The ones we're adding include work maintained by Microsoft, AWS, IBM and the Linux Foundation. Planned. An independent review of the whole is Planned before the first client installation. The security architecture lists what each part does and its status.
What the AI can and can't do
Cast & Rule's assistant is called the Clerk. The Clerk prepares work. It never decides anything for you.
The Clerk can:
- read the client records your Rules allow, through Sources. Connections to Xero, Microsoft 365, Companies House and HMRC are Planned. They'll start with read-only access to one organisation at a time;
- help prepare work for review. Planned work includes preparing and checking practice working papers, casting the column (that is, adding it up) and marking the work Prepared. Planned.
The Clerk can't:
- send, file, post, pay or delete anything outside the practice. The product can't do this today. When it can, it will run only on a partner's ruling;
- change your Rules, or give itself new permissions. Tasks are limited to the permissions your practice has accepted. Built.
- take permissions from a client's document or email. Built controls restrict task permissions. Documents can't grant permissions, but hostile content may influence answers. Outputs still need review.
- run any task that hasn't been signed and approved for your practice. Built.
The partner's ruling
Ruling is the partner sign-off queue. In build.
When it ships, a partner will see each piece of prepared work with the evidence beside it: what would happen, where any data would go and the steps that produced it. It will say, in words, what the decision covers and what happens as a result. Approving will never be a drag, a tick-box or a strike-through.
A ruling will approve one exact piece of work. If anything in it changes after the partner has ruled, including a figure, a recipient or an attachment, the approval no longer applies. The work comes back for a fresh decision. Every ruling will record the partner's name, qualification and the time.
Until Ruling ships, every demonstration stops at Awaiting partner.
The Ledger
The Ledger is the practice's audit record: who did what, and when.
- The Ledger records what the AI did. Built. Full logging of agent connections is In build. Other apps on the machine are outside its coverage.
- Each entry is locked to the one before it, and we check a fingerprint of the chain regularly. The Ledger can reveal changes to records we've already checked. Built.
- The Ledger records the kind of each action, its size and a fingerprint of its content. It never records the content itself. That way, the record doesn't become a second copy of your clients' confidential material. Built.
- The full record of each AI run, including what it read and what it changed, is kept separately, encrypted, in your practice's own store on the machine. Every change is marked as made by a person or by the AI, with the task and its version, the model version, and whether anything left the machine through Cast & Rule. Planned.
- For any period, a no-cloud report you can download and check without us shows every AI run and what left the machine through Cast & Rule, and, once the engine's network block lands, whether the AI engine's own network access was blocked. It also lists the operational details our management service received (who ran what, when, status), never content. Planned.
- Extending the Ledger to cover every AI action, including reads, retrievals and rulings, is In build. The exact list of what's logged is Planned.
If a laptop is lost
- Revoke the machine. From the administration screen, your practice revokes the machine's pairing. The lost machine doesn't need to be switched on, or to co-operate. Revocation blocks the machine's future requests to our service. Built. It doesn't erase local files or instantly stop offline processing.
- The machine's identity can't be copied off it. Its signing identity sits in hardware-backed storage built into the machine. It can't be exported to another computer. In build.
- We'll close connections at the source. We'll revoke the practice's connections to outside systems at the supplier, so the lost machine can't use them. Planned, alongside the connectors.
- Client records are encrypted. The Strongroom will store each client's records encrypted, each with its own key. Planned. Until then, your practice should turn on full-disk encryption for every machine.
We recommend a dedicated machine, not a laptop that travels. Cast & Rule includes encrypted backup, with a tested restore. Planned.
Your duties, and how Cast & Rule helps you show you meet them
Cast & Rule is built to support these duties. It doesn't discharge them for you.
ICAEW Code of Ethics, section 114 (confidentiality). The 2026 Code has applied since 1 July 2026, and ICAEW issued a reminder on confidentiality on 28 July 2026. Putting a client's figures into an AI tool is a decision to use and disclose confidential information. Cast & Rule keeps that information on hardware your practice controls, and to record in the Ledger what the AI does, so far as it can capture it.
ICAEW guidance on generative AI. ICAEW's guidance says you shouldn't put confidential client information into public AI tools. Cast & Rule gives your team a place to use AI that isn't public. It runs inside your practice, under your Rules.
UK GDPR. Your practice's role depends on the processing. See the ICO's guide to controllers and processors for more. Where we process personal data for you, our contract will set out our duties as your processor. Planned. The design supports your duties in four ways:
- minimisation: task permissions limit what the Clerk can reach (Built);
- security: access limits (Built) and encrypted per-client compartments (Planned);
- accountability: the Ledger records what the AI did (Built), and expanded auditing is In build;
- meaningful human review: a partner rules with the evidence in front of them. This matters under the Data (Use and Access) Act 2025 rules on automated decisions. Ruling is In build.
Your practice still needs its own lawful basis, privacy notice, retention schedule and, where the risk is high, a data protection impact assessment. Our sub-processor list and data-flow diagram are published before launch. Planned.
Anti-money-laundering records. The Money Laundering Regulations say you must keep customer due-diligence records, generally for five years after the relationship ends. Cast & Rule supports this: it keeps that evidence for as long as the law requires, while removing it from everyday AI use. Planned, and it needs checking before client use.
What stays with you
Cast & Rule is not an accountancy practice. Your firm keeps the client relationship, the professional judgement, the tax treatment and the sign-off. Directors still approve company accounts, and clients still approve their returns.
For the technical detail, see the security architecture. For short answers, see the security questions.
