Referencearchitectureforsecurityreview

What a reviewer needs before a call: the trust boundaries, the request path, where data goes, and what the platform depends on.

Layerview

The functional layers and what each is responsible for.

Platform architecture
Eight layers. Select a layer to read what it is responsible for.

Control

Who may do what, to which data, with what evidence.

Components
Identity · Policy · Permissions · Governance · Evidence · Audit · Lifecycle
Control in depth

Requestpath

The sequence every request passes through. Useful for identifying where a reviewer's controls attach.

Sovereign intelligence control plane
The path every request travels before anything changes state.
  1. IdentityWho is acting?
  2. OntologyWhat is being acted on?
  3. PolicyIs this allowed?
  4. ExecutionHow is it carried out?
  5. EvidenceWhat actually happened?
  6. EvaluationWas it any good?
  7. LifecycleWhat happens next?
Identity
Every agent, model and workflow has its own identity — not a shared service account. Non-human identities are issued, scoped, rotated and revoked like any other principal.
Ontology
Requests resolve against typed enterprise objects rather than free-text table names, so permissions and policies can be expressed in the organisation's own terms.
Policy
Data scope, tool scope, model policy, network egress, cost budget and approval requirements are evaluated before execution, not asserted in a prompt.
Execution
Approved work runs in an isolated runtime with short-lived credentials, brokered tool calls and a recorded plan.
Evidence
Inputs, retrieved context, model selection, tool invocations, approvals and outputs are captured as a reviewable trail attached to the decision.
Evaluation
Behaviour is scored against task-specific evaluations and regression suites, so quality is measured rather than assumed after a change.
Lifecycle
Promotion between environments, ownership, review dates, deprecation and shutdown are managed explicitly — including a kill switch that works.
Policy evaluation happens before execution. The component that evaluates policy does not read untrusted content, which is what prevents a persuaded model from exceeding its mandate.

Trustboundaries

  • Untrusted content boundary

    Everything a model reads is untrusted. Authority is enforced outside the model by a component that never reads that content.

  • Tenant boundary

    Data, indexes, credentials, evidence and compute separated per tenant, with cross-tenant access tested against.

  • Agent boundary

    Per-agent identity and scope, so one agent's compromise does not confer another's access.

  • Egress boundary

    Default-deny outbound with explicit per-mandate allowlists.

  • IT/OT boundary

    One-directional observation through a broker; no unattended write path.

  • Deployment boundary

    In customer-infrastructure postures, the platform operates entirely inside your perimeter.

Dataflowsareviewershouldtrace

  • Ingest

    Source system to broker to ontology, with what is copied versus referenced in place.

  • Retrieval

    Query to permission check to index to passages, with access-awareness applied before results.

  • Inference

    Request to model policy to selected model, including where the call physically terminates.

  • Tool invocation

    Agent request to authorization to broker to target system, with the credential never reaching the agent.

  • Approval

    Proposal to ownership resolution to approver to decision record.

  • Evidence

    Capture to storage to retention, staying within the same residency boundary as the data.

This page is the shape of the architecture. The security pack contains the detail a review needs: component inventory, dependency list, port and protocol matrix, identity flows, key hierarchy and test evidence.

Bring us one operational problem.

You do not need a finished brief. Bring the problem — we will work out the next step together.

Or book a call with the team