Draft for review. This page is still being reviewed, and its content and figures may change.

Assurance

Assurance

How the platform's security and AI governance are controlled, what evidence each control produces, and where each control stops.

Evidence as of 2026-09-24

On this page
  1. The problem assurance has to answer
  2. Why it matters
  3. The approach: controls where the agent acts
  4. Security controls
  5. AI governance controls
  6. What the controls have produced
  7. Boundaries
  8. Applying it elsewhere

The problem assurance has to answer

An agent that can write code can also write it in the wrong place, bypass a check, read something it should not, or run up cost nobody approved. A reader evaluating an AI delivery capability needs to know which of those risks are controlled, how, and what proof each control leaves behind. A list of good intentions answers none of that.

Why it matters

Customers of an ERP platform trust it with their financial and operational records. A control that exists only in a prompt can be ignored the first time it is inconvenient, and a failure found by a customer costs far more than one found by a gate. Assurance therefore has to be designed into the places the agent acts, and it has to be honest about its reach.

The approach: controls where the agent acts

Controls are arranged on the Three Lines Model. The first line is preventive and acts on every action: runtime hooks and commit gates. The second line is detective and periodic: AI review tools that score the framework, each project and each tool against written rubrics, and turn their findings into queued work. The third line, independent assurance, is a person’s governance and any external assessment an organisation commissions.

Security controls

The platform is aligned to ISO/IEC 27001 and to the UK Software Security Code of Practice. It has not been assessed or audited against either, and holds no certification.

Each row reads from the risk to the boundary of its control.

An agent writes directly to a production database

Control objective
Every data change goes through a governed tool
Mechanism
A runtime hook refuses direct database writes and names the sanctioned tool; enquiries run through a read-only connection
Evidence
Each refusal is logged with the action and the rule that refused it
Boundary
A person with full access can still act outside the agent; the control governs the agent, not every account

Generated application metadata is hand-edited until it no longer matches its specification

Control objective
Generated artefacts come only from their generators
Mechanism
Commit gates check provenance on generated files; runtime hooks refuse hand edits
Evidence
Provenance records on each generated artefact; gate results on each commit
Boundary
Artefacts outside the generator catalogue are governed by review, not provenance

A credential or secret reaches a repository

Control objective
Secrets never enter version control
Mechanism
A commit gate refuses secret-shaped content; improvement records redact credentials before storage
Evidence
Refused commits in the gate log
Boundary
Pattern-based detection misses a secret with no recognisable shape

One compromised machine reaches the rest of the fleet

Control objective
No machine can reach another
Mechanism
Remote access comes only from a developer laptop; machines hold no private keys and exchange state only through version control
Evidence
Access keys are distributed from a reviewed roster, and each change is recorded in history
Boundary
Version-control credentials are shared more widely than ideal; per-machine credentials are planned

A change reaches customers without evidence that it works

Control objective
No release without evidenced requirements
Mechanism
Phase gates require code, passing tests and documentation for every requirement
Evidence
Gate results per project; phase-transition records
Boundary
The gates prove the process ran; they do not prove the requirement was the right one

AI governance controls

The platform is aligned to ISO/IEC 42001 and to the UK AI Cyber Security Code of Practice. It has not been assessed against either.

Controls over the AI the platform uses and the AI it ships.

AI spend grows unseen

Control objective
Every model call is attributable and costed
Mechanism
A usage ledger records purpose, model, tokens, latency and estimated cost for every call; spend is reported from it
Evidence
The ledger, and a fleet-wide spend audit carried out in September 2026
Boundary
One chat orchestration component records no usage yet; one shared vendor key limits attribution at the vendor

A model is chosen by preference, not performance

Control objective
Model choices are measured before adoption
Mechanism
Candidate models are scored against a golden question set checked against live data
Evidence
Scored evaluation runs with per-question cost
Boundary
Evaluations cover the product chat surface, not every AI purpose

An agent takes a decision that belongs to a person

Control objective
Reserved decisions stay with named people
Mechanism
Named touchpoints for commitment, risk acceptance, destructive operations and escalations; hooks refuse autonomous deletion
Evidence
Rulings and risk decisions are recorded with dates
Boundary
Where one identity is shared by a person and the agent, the record cannot always show which acted

Prompts drift from what was approved

Control objective
System prompts are governed records
Mechanism
Prompts are versioned in a registry, and the live chat configuration is re-derived from the active version and checked for drift hourly
Evidence
Version history and drift checks
Boundary
Covers the product chat surface

What the controls have produced

The first line acts in practice, not only on paper: runtime hooks logged more than 30,000 refused agent actions, recorded on a single workstation. Each refusal redirected the agent to the sanctioned tool.

Boundaries

Alignment is not certification. The mapping to each standard is a theme-level correspondence written by the platform’s authors, not a clause-by-clause opinion. No external body has reviewed these controls. The platform’s own review tools are second-line self-assessment, and are presented as such.

Applying it elsewhere

Start from the risks, not the standard. For each risk, decide the control objective, put the mechanism where the agent acts, and make sure it leaves evidence a reviewer can read. Mapping to a standard comes last, and is worth commissioning an independent assessment for only once the controls have run long enough to produce a record.

Work with Craig

Bounded engagements to design or review an AI delivery capability for an existing software organisation. Terms are agreed per engagement.

How engagements work Email craig.spong@syntegra.solutions