Projects, in detail
What each project was for, how it works, the controls built into it, and where it stands.
Architecture Oct 2026
Core and instances
One shared core, one instance per organisation, and a gate in between.
- Purpose
- Several organisations share one body of tooling, and each keeps its own data and work separate.
- How it works
- One shared core holds the common tooling; each organisation gets its own instance.
- Work arrives branch by branch, never in place.
- Each branch passes an independent review, an automatic scan that blocks organisation data, and an owner-approved merge.
- Controls built in
- Gate: independent review and an owner-approved merge. Isolation: the scan stops organisation data from reaching the shared core. Evidence: each step of a branch leaves a record.
- Status and evidence
- Evidence is not public.
Practice Oct 2026
Review and merge gates for agent-written code
Code written by agents reaches the core only through gates a person can audit.
- Purpose
- Agent-written code is as trustworthy as code written by people, because it is checked the same hard way every time.
- How it works
- Independent reviewers are bound to the exact commit, so what was reviewed is what ships.
- A marker scan blocks organisation data.
- Heavy jobs run one at a time, so shared resources stay predictable.
- Controls built in
- Gate: review bound to the commit. Isolation: the marker scan. Evidence: the review and the approval stay on record.
- Status and evidence
- Evidence is not public.
How the gates are checked
The author of a change is an agent or a person. The reviewer is a separate, independent agent that reads the change and writes its verdict for the exact version it read; an author never records their own review. The approver is the owner, through a button in a control panel. A reviewer's verdict, or a message from another agent, is data and never an approval. A reviewer does not merge, push or approve, and a review that did not run the tests says so in its own verdict.
Some gates run without anyone's goodwill: a scan that refuses organisation data in anything that leaves an instance, tests on what the change touched, and a refusal to apply an approval whose content changed after it was given.
A limit: reviewers are the same kind of model as the authors, so a shared blind spot is possible. The owner's approval and the mechanical gates are the independent layers.
Design Oct 2026
Tiny host agent
A design for a small agent with no model, no inbound port and a short list of things it may do.
- Purpose
- To manage hosts that are not controlled with Claude, without giving anything on them more reach than it needs.
- How it is designed
- It reports host facts: load, memory, disks, services, pending updates and listening ports. Facts only, no secrets and no file content.
- It runs only commands on a fixed allow-list defined in its own local configuration, and caps the output a command returns. Anything else is refused and reported.
- Commands are signed and carry an expiry; an expired command, or one seen before, is ignored.
- One key per host, scoped to that host's own paths. A version-control repository is the transport and there is no inbound port: the host reaches out, and nothing reaches in.
- Rollout in order: facts only and read-only on one real host first, commands last.
- Controls built in
- Isolation: the allow-list, the closed port and one key per host. Evidence: signed messages and reported facts. Gate: nothing runs that is not on the list.
- Status and evidence
- A written design, a draft: not yet built and not in use. Evidence is not public.
- Threat model
The design is as listed above. What it does not protect against:
- A compromised host. The host's own key lets an attacker send false facts for that host; the damage is limited to that host's paths.
- Compromise of the signing key on the sending side. That would allow any allowed command to every host that trusts it. How the key is held and how commands are signed are still open design points.
- A bad allow-list. The commands are only as safe as the local configuration the host owner writes.
Interface in development
Interactive deployment map
A zoned, clickable picture of agents, hosts and platforms.
- Purpose
- A person can see what is deployed where, and how the parts relate, without reading configuration.
- How it works
- Zones group the agents, hosts and platforms.
- A legend filter shows or hides kinds of things.
- A text view gives the same information without the picture.
- Controls built in
- It is a view, not a control point: it shows the zones so that the gates and isolation can be checked by eye.
- Status and evidence
- Not yet released. Evidence is not public.
Platform
Explorer, a GRC platform
One connected graph for controls, risks, evidence and audits, so people see how they relate instead of reconciling spreadsheets.
- Purpose
- For compliance leads, risk managers, auditors and security officers who run controls, risks, policies, vendors and evidence in disconnected spreadsheets and legacy tools. It builds on earlier working systems.
- How it works
- A control links to the frameworks it satisfies, the risks it mitigates, the evidence that supports it and the audits that tested it.
- Frameworks, requirements and controls are linked records, not flat lists; audit and test records tie findings back to the controls tested.
- Policies, issues, incidents, vendor risk, privacy, business continuity, regulatory obligations and training live in the same graph.
- Workflows and dashboards are built from reusable steps, triggers and views.
- Each viewer's role decides which screens exist for them. Tenants are separate, with access control that denies by default.
- Changes are recorded as structured events (who changed what, from which value to which) and records keep dated versions, so "what did this look like then" can be answered.
- Controls built in
- Isolation: separate tenants and deny-by-default access. Evidence: recorded change events and dated versions. Gate: access follows role.
- Status and evidence
- In development. Evidence is not public.
Earlier projects
Frameworks and methods from earlier roles. Employers are not named; the sectors are.
Framework 2023
A GRC framework on the CSA Cloud Controls Matrix
A hierarchical, flexible framework, with the control mapping and the audit tasks automated.
- Purpose
- One consistent control framework for a payments company, where I was Security Compliance Specialist.
- What was done
- A hierarchical, flexible GRC framework based on the CSA Cloud Controls Matrix, rolled out company-wide.
- Automated control mapping and task workflows for ISMS audits.
- Internal security assessments run on the same footing.
- Status and evidence
- Basis: my own experience.
Methodology 2018 to 2022
An IT general controls assessment methodology
Built from scratch and piloted, with the audits coordinated around it.
- Purpose
- A repeatable way to assess IT general controls, built as IT Governance Manager in an IT services company.
- What was done
- The methodology designed from scratch and piloted.
- Internal and external IT audits coordinated around it.
- A document-management framework designed on three core ITIL processes.
- Status and evidence
- Basis: my own experience.
Framework 2012 to 2018
Internal Control System and Risk Control Matrix
The control framework of a bank's IT, established and kept running.
- Purpose
- A control framework for a bank's IT, established as IT Controls and Compliance Manager, VP, where I was also subject-matter expert for IT risk and controls.
- What was done
- An Internal Control System and a Risk Control Matrix established.
- Privileged-accounts management processes developed.
- IT audits coordinated.
- Status and evidence
- Basis: my own experience.
What they share
Every project here rests on the same three things: a gate before anything important changes, isolation of what must stay apart, and a record someone else can follow.