Cast & Rule security architecture

Status and scope

Each control 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 this page cites a standard, it names the practice we follow.

Scope. The machine's administrator controls the software on it, and these controls work inside that boundary. Our verification evidence comes from development work; independent security review is Planned.

1. Trust boundaries

There are four boundaries.

1. The practice machine. This is local hardware your practice controls. It runs the Cast & Rule agent, the local AI model and the Ledger (the audit record). We process client content here. Local processing is Built for a single machine, macOS only. Client isolation and the Strongroom's encrypted client stores are Planned.
2. A fully local install. The whole system runs on your machine and keeps working if your internet goes down. Planned.
3. The Cast & Rule control service. We host this service. It holds signed Rules and task definitions, each machine's public identity, the state of each job and fingerprints of each Ledger. It doesn't store client documents. Built. Authorised results may still 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.
4. Outside systems. These are the client systems your practice already uses: ledgers, Microsoft 365, Companies House and HMRC, plus an optional cloud model used only where your Rules allow it. Connectors and the cloud-model option are Planned.

1. Practice machinelocal processing and Ledger (what the agent does)—Built; client stores—Planned; Ruling—In build.
2. Fully local installPlanned alternative.
3. Cast & Rule servicereceives agent requests, status and permitted results; returns instructions.
4. Approved external servicesPlanned; receive authorised requests and return source data or model responses.

Logical data exchanges. These directions don't show which side starts the network connection.

An operating-system sandbox limits what a task can reach: working data, supporting resources, network connections and process activity. In build.

2. Data flows

Instructions travel in. 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. The control service digitally signs each work item, and the machine checks it before anything runs. The agent rejects and logs any item that fails that check. Built.

The practice's permissions always win. Tasks are limited to the permissions your practice has accepted. Our service can't expand them on its own. Built.

Status travels out. The agent sends the operational metadata and results your Rules permit. Where your Rules let a result leave the machine, it's encrypted first. In build. In today's development build, we hold the decryption keys, so we can access those results. Encryption to a key only your practice holds is Planned.

Identifying information is reduced. We're cutting the identifying information the agent sends us. In build. Further client-metadata minimisation is Planned. Some operational information will still be visible to our service.

If you allow a cloud model. 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.

3. Identity and credential custody

• One identity per machine, created on the machine. Each machine creates its own key pair when it's paired. The private key never appears in configuration, on the network, in a log or in a database. Built. New pairings keep that key in hardware-backed storage built into the machine. It can't be exported. In build.
• Authentication in both directions. We authenticate agent-to-service messages, and check work items from the control service against a key pinned at pairing. Built.
• Human presence for consent. Accepting or widening the practice's Rules on a machine needs the operating system to confirm someone is there, by Touch ID or login password. In build.
• Separate secrets for separate purposes. We keep machine identity keys, client-record encryption keys and credentials for outside systems separate, and never reuse them across purposes. Built for the signing keys that exist today; Planned for connector credentials and client-record keys.
• Connector credentials. We'll protect connector credentials separately, and limit them to authorised connections. They won't enter AI prompts. Planned.
• Your clients' own logins. Connectors never ask for or store a client's sign-in details for HMRC or any other service, in line with HMRC's standard for agents. Planned.

4. Least-privilege connectors

Connectors are Planned. None is live. Every connector we build will follow the rules below.

• Read before write. Connectors start read-only, with the narrowest scope each supplier offers. Where a supplier's token can technically write, Cast & Rule will still enforce read-only access itself.
• One organisation per connection. At onboarding, we'll bind each connection to one client organisation, and check that binding on every call.
• A small, fixed set of operations. Tasks will call specific, named operations, never open-ended query access or pass-through to a supplier's API. A change on the supplier's side must not silently give a task new abilities.
• Official interfaces only. We build against suppliers' official, documented APIs or authorised exports. No unofficial endpoints, no screen scraping, and no unreviewed third-party connector packages.
• Every write is a ruling. Any action that changes an outside system will need a partner's ruling (their sign-off) on that exact action.

5. Prompt-injection and tool-misuse defences

Client documents, emails, spreadsheets and web pages can contain text written to manipulate an AI system.

• Built controls restrict task permissions. Documents can't grant permissions, but hostile content may influence answers. Outputs still need review.
• Tasks run only from signed definitions whose fingerprint covers the whole task. An edited task is an invalid task. Built.
• Checks that cut down what gets disclosed are In build. They can't remove every confidential detail. Even an allowed summary might still be confidential.
• Checks that try to catch unsupported summaries are In build. They can miss errors, so check important statements against their sources.
• An operating-system sandbox limits what a task can reach: working data, supporting resources, network connections and process activity. In build.
• Checking the local processing environment is In build. Stronger network isolation is Planned. Running locally alone doesn't fully isolate a task.

These controls address the threats named in the Model Context Protocol security best practices, in everyday terms: instructions hidden in content, tool descriptions written to mislead, a tool using permissions it shouldn't have, stolen access tokens, and requests sent to places they shouldn't go.

6. Egress control and logging

• Agent connections. Controls to limit and check agent connections are In build. Our development testing has the same coverage limits stated here.
• Ledger coverage. The Ledger records what the AI did. Built. Full logging of agent connections is In build. Other apps are outside its coverage.
• No silent fallback. If local processing can't run, the job fails and says so. We never quietly move it to a paid or cloud route. Built.
• Legally required identifiers are declared. If Cast & Rule connects directly to HMRC's Making Tax Digital services (Planned), the law says we must send fraud-prevention data that identifies the device and user with each call. We'll declare that in the practice's documentation.

7. The tamper-evident Ledger

The Ledger accepts new entries, not edits. Each entry is locked to the one before it (hash-chained), so a later change to an entry we've already checked shows up. Each entry also records its class, size and a fingerprint of its content, never the content itself. Built.

The machine reports its latest entry to the control service at regular intervals, and the service checks again that the chain has only grown. The Ledger can reveal changes to records we've already checked. Built. Extra protection for the local audit record is In build.

This gives tamper evidence, not tamper prevention. Entries made since the last report aren't yet anchored, and the chain can't prove a compromised machine made no unrecorded calls. Extending the Ledger to cover every AI action, including reads, retrievals, proposals and rulings, is In build. The exact list of what's logged is Planned.

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. Planned. It also lists the operational details our management service received (who ran what, when, status), never content. Planned.

8. Encryption

• In transit. We authenticate agent-to-service messages. Built. Encrypted production transport is In build. Future connectors will need encrypted transport. Planned.
• Results leaving the machine. Result encryption is In build. In today's development build, we hold the keys. Encryption to a key only your practice holds is Planned.
• At rest on the machine. The Strongroom will keep each client's records in their own encrypted store, under their own key. Planned. Every practice machine should have full-disk encryption on. It protects a machine that's switched off, but it doesn't keep clients apart while the machine is in use.
• Backups. We'll encrypt backups per client. A restore will re-apply any erasures made since the backup was taken. Planned, and it needs checking before client use.

9. Key management principles

• Use hardware-backed, non-exportable keys wherever the platform offers them. In build.
• Separate keys by role and refuse cross-role reuse. Built for our signing keys.
• Separate signing-key custody and controlled rotation are In build. Managed signing integration is In build, and isn't active in the deployment yet.

10. Update and supply-chain integrity

• Signed tasks. We sign task definitions, and the signature covers every file in the task. Built.
• Signed releases. Each release will carry a signed manifest that the agent verifies at start-up. In build.
• Model integrity. Integrity checking for the on-device privacy detector is In build.
• Notarised installer and managed update channel. A signed, Apple-notarised installer with a controlled update and rollback channel is Planned.
• Dependencies. Our dependency policy, following the NCSC's supply-chain guidance, is Planned.
• Independent review. We'll have an independent review of the release candidate before the first client installation. Planned.

11. What we build on

We don't write our own cryptographic algorithms or policy engine. Where a well-reviewed open-source component or an open standard does the job, we use it rather than writing our own. The code of ours that joins them together has not yet been independently reviewed. That review is Planned before the first client installation.

• Permissive licences. The open-source components we build on are under permissive licences such as MIT and Apache-2.0, which let us and our clients use, inspect and keep them. We check each component's licence before we adopt it. Our written licence and dependency policy is Planned.
• From organisations that publish their work for review. The ones we're adding include components maintained by Microsoft, AWS and IBM and projects hosted by the Linux Foundation. Planned.
• Open standards, not private formats. Signatures, encryption and connections use published standards, so an auditor can check them with tools of their own choosing.
• Every release signed and checked before it runs. The agent refuses a release whose signature doesn't verify. In build.
• A full component list on request. A software bill of materials, in a standard format, is available to client practices under a non-disclosure agreement. Planned.

12. Incident response

We'll publish our incident-response plan before launch. Planned. It will cover:

• detection, drawing on the control service's checks of each Ledger and each machine's release status;
• containment, including revoking a machine, which blocks its future requests to our service (Built), and revoking connector access at the supplier (Planned);
• notification of affected practices without undue delay, so they can meet their own UK GDPR breach-reporting duties;
• credential rotation;
• a written post-incident review.

Where we act as your processor, we'll support your investigation with Ledger evidence.

13. Retention, erasure and AML records

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.

Retention and erasure controls are Planned, and need checking before client use. Cast & Rule handles them like this:

• material made from a record follows that record's rules: extracted text, search indexes, summaries and model memory follow the rules of the record they came from;
• erasure is separate from legal retention: CDD records are usually kept for five years after the relationship ends (HMRC guidance). Records under that kind of hold move to a restricted area, outside everyday AI use, for as long as the law requires;
• disposal is recorded without the data: the Ledger records that a disposal decision was made, not the personal data;
• disconnecting isn't erasing: disconnecting a source stops new collection. What happens to records you already hold is a separate decision for your practice.

Revocation blocks the machine's future requests to our service. Built. It doesn't erase local files or instantly stop offline processing, and it isn't offboarding. We'll show a documented export-and-deletion procedure before we accept the first practice's data. Planned.

14. Sub-processors

We'll publish the full list, with its data-flow diagram, before launch. It covers these categories:

• Hosting for the control service. It holds job state and metadata, and may hold authorised results as described in section 2. We'll confirm the hosting region on the published list.
• Authentication for some connections. Where a planned connection needs off-device processing of authentication information, we'll declare the data flows and any providers involved before use. Planned.
• A cloud-model route under your rules. This applies only if a practice turns cloud processing on for work its Rules allow. It's off by default.

Your practice engages your existing suppliers, such as your ledger and Microsoft 365. We'll assess their roles for each data flow. We'll document supplier roles, locations and transfer arrangements before use. Planned.

15. Responsible disclosure

We'll publish a vulnerability-disclosure policy and a dedicated security contact at launch. Planned. Until then, this site has no sign-in and no form that submits data.

For plain-English summaries, see the security overview and the security questions.