Resources · Platform Architecture

How Safeguard is built. Under the hood, end to end.

A single-page reference for the moving parts of the platform. The control plane, scanner fusion, model serving, policy engine, audit trail, and the multi-tenancy boundaries that hold the whole thing together. Different from the model architecture or the surface map — this is platform engineering.

The seven-layer stack

Seven layers, one substrate.

Ingest at the bottom, surfaces at the top, audit running alongside the whole chain. Each layer is independently versioned and independently observable.

L1

Ingest

SCM webhooks (GitHub, GitLab, Bitbucket, Azure DevOps), container registry events, manifest uploads from the CLI, and scheduled scans on a per-project cadence. All ingest events land on a single durable queue with deterministic event IDs so retries and replays are safe.

L2

Scanner fusion

Eleven scanners run in parallel against the ingested artefact. A fusion layer collapses raw findings by (component, function, sink) and produces a single ranked candidate set with cross-scanner evidence bound to every item. The fusion result is what the rest of the platform reasons over.

L3

Enrichment

Seven feeds — NVD, OSV, EPSS, KEV, GHSA, VirusTotal, VulnCheck — cached in a Postgres warm tier with Redis as the hot path. Cache invalidation tracks upstream sigstore signatures, so a stale CVE record cannot survive past the upstream amendment.

L4

Reasoning

Lino runs on-device for inline. Eagle runs batched on the cloud for repo-wide ranking. Griffin (with its auto-router across Lite, S, M, L, Zero) runs for the deep pass. The reasoning trace is a first-class object — every verdict ships with the chain it survived.

L5

Policy engine

Rego-style policies authored once and enforced in CI, the IDE extension, the desktop app, the admission controller, and the MCP server. The same policy bytecode is what gates the build and what surfaces the violation in the editor — no drift between enforcement surfaces.

L6

Audit trail

Every action — ingest, scan, reasoning call, policy decision, fix, dismissal — emits a signed event in CycloneDX plus JSON. The chain is tamper-evident via sigstore: a regulator can verify a finding's full lineage without trusting Safeguard's word for it.

L7

Surfaces

REST API, IDE extensions, desktop app, CLI, MCP server, web portal, and marketplace. Every surface reads from the same audit trail and writes through the same policy engine. Eight ways in, one source of truth.

Multi-tenancy & isolation

Three independent isolation boundaries.

Tenant separation runs at the schema, the inference key, and the audit stream. A bug in one layer should not leak data across tenants — the other two have to also fail.

Tenant-isolated Postgres schemas

Every tenant gets its own schema with a row-level-security envelope. The application layer cannot reach across schemas; the database role used by the service has zero permission outside its bound tenant. Cross-tenant joins are physically impossible, not aspirationally forbidden.

Per-tenant inference keys

Each tenant has its own inference key with its own KMS-managed envelope. Prompt logs, KV caches, and reasoning traces are encrypted at rest with that key — a key revoke renders the tenant's history unreadable, including to Safeguard operators.

Per-tenant audit log streams

Audit events flow into a per-tenant stream with its own retention, signing key, and export endpoint. The stream is append-only and sigstore-signed so a regulator export carries provable lineage from event to verdict.

No cross-tenant model weights or training

Customer code never enters training. There is no shared per-customer fine-tune that other tenants inherit. Distillation runs on Safeguard's public-only corpus; tenant-specific behaviour comes from policy, not from weights.

Model serving

Where the weights actually run.

Each model in the lineup has a serving shape that matches its budget. The auto-router puts the work on the right hardware without the surface having to think about it.

Lino · on-device

Lino's 1B weights ship inside the IDE extension, the CLI binary, and the desktop app. Inference runs on the developer's laptop with no network egress. p95 inline latency is under 100 ms on M-series Apple Silicon and recent x86 GPU laptops.

Eagle · batched INT8 on shared GPU pool

Eagle's 13B dense head runs on a shared GPU pool with batched inference and INT8 quantisation. A 5k-package monorepo sweep returns ranked candidates at p95 ~420 ms per package. Per-tenant rate limits are enforced at the inference router, not the GPU.

Griffin variants · dedicated GPU per tier

Griffin Lite, S, M, and L run on dedicated GPU shapes per deployment tier. Shared cloud bursts on multi-tenant inference with prompt-level isolation; dedicated and VPC tiers get single-tenant GPU pools with SHA-pinned weight attestation.

Griffin Zero · sovereign / dedicated multi-GPU

The 671B-MoE Zero head runs only on sovereign or dedicated multi-GPU clusters — documented sizings start at 11x H100 and scale to multi-AZ topologies. It is not exposed on the shared cloud tier and not auto-routed without an explicit policy gate.

Data flow

Commit to portal, one pipeline.

Every event a developer triggers walks the same path. The diagram below is the full chain — no hidden services, no parallel universes.

Commit
Developer push or merge
Webhook
SCM event, deduplicated
Scanner fusion
11 scanners, cross-dedup
Enrichment
7 feeds, cached + signed
Reasoning
Lino · Eagle · Griffin
Policy
Rego v2 evaluator
Audit
CycloneDX + sigstore
Egress
Portal · Jira · Slack

Audit signing fans out alongside every node — egress is not the only place lineage is captured. Every node writes to the audit trail before passing the event on.

Performance posture

SLOs you can point at.

Availability targets, latency targets, scan-to-verdict windows, and auto-fix turnaround — the numbers the production tier is held to. Contractual SLAs live in the order form.

Availability by tier

  • Shared cloud99.5% application-layer
  • Dedicated cluster99.9% application-layer
  • VPC-isolated99.9% application-layer
  • Sovereign / air-gapped99.95% application-layer

p95 latency by surface

  • IDE inline (Lino)< 100 ms
  • REST API (single finding)< 350 ms
  • Console dashboard cold load< 1.2 s
  • MCP server tool call< 250 ms

Scan-to-verdict typical

  • Eagle sweep, 5k packages~6 minutes
  • Griffin S verdict (single)~2.8 s
  • Griffin L verdict (single)~8 s
  • Griffin Zero verdict (single)~12 s

Auto-fix turnaround

  • PR opened from CI gate failure< 90 s
  • Cross-service campaign rollout< 24 h
  • Coordinated disclosure draft< 4 h
  • Regulator export packaging< 60 s
Security architecture

Four boundaries we hold the line on.

Tenant isolation, signed weights, signed audit logs, and a break-glass workflow. Each one is independently testable; together they are how the platform earns the regulator export at the end.

Tenant isolation

Row-level security at the schema layer, per-tenant inference keys at the KMS layer, per-tenant audit streams at the egress layer. A bug in one layer does not cascade — three independent boundaries have to fail to leak data across tenants.

Signed weights

Every model weight file ships as a sigstore bundle with provenance. The IDE extension refuses to load an unsigned Lino weight; the inference server refuses to serve an unsigned Eagle or Griffin checkpoint. Weight rotation is auditable end-to-end.

Audit log signing (sigstore)

Each audit event is signed with a tenant-scoped sigstore key. Verification is open — a regulator with the public key can verify any finding's provenance without Safeguard's involvement. Tampering breaks the chain visibly.

Break-glass workflow

Operator access to tenant data requires a break-glass workflow: two-person approval, time-boxed access window, full keystroke audit, and customer notification. There is no path to tenant data that does not leave a trail.

What's NOT in the architecture

The shapes we refuse to build.

An architecture page that only shows what is built is incomplete. The list below is what is deliberately absent.

Out of the architecture, by design

  • We do not aggregate customer code into training. There is no shared corpus that other tenants inherit from your repo, contractually and by audit.
  • We do not share findings cross-tenant. A finding produced for one tenant never appears as evidence for another — not even in aggregate metrics.
  • We do not store credentials in plaintext. Tokens, OAuth secrets, and signing keys are KMS-wrapped at rest and only decrypted in the inference / signing service that holds the bound IAM role.
  • We do not ship without signed weights. An unsigned weight file fails to load — there is no fallback path, no 'unsigned but functional' mode.
  • We do not maintain a model that can answer questions outside its security frame. Griffin will not write your marketing copy. That is a feature.
Every item above is verifiable under NDA. Architecture attestation, weight signing manifest, and audit-log schema are all reviewable on request.

Want the architecture deck? Bring your platform team.

The full diagram set, the weight-signing manifest, and the audit-log schema are reviewable under NDA. Book a session and we will walk it with your platform and security engineering teams.