Trust — AI Control Plane

Last updated: 2026-08-06. Applies to controller.intelxview.com.

This page summarises how IntelXview operates the AI Control Plane ("ACP") securely. It complements the Privacy Notice and is intended for enterprise buyers evaluating ACP for their organisation.

Evidence signing key

ACP signs decision evidence with an Ed25519 key. Anyone holding an evidence pack can verify those records with standard tools and no IntelXview software. That establishes integrity — it does not, on its own, establish whose key signed them. This section publishes the fingerprint so you have a second place to check it against.

The commands below reproduce the fingerprint by hand. If you only want to know whether a pack you hold is intact, run the verifier instead — it needs no account, no admin rights and nothing installed, and it prints this same fingerprint for you to compare against the value below.

SPKI SHA-256 fingerprint

05ba016c7e7db42bd8b5b99d593117a8d32e9217f55bffb3d87007073b69fb51

"Fingerprint" here means one specific thing: the SHA-256 digest of the DER-encoded SubjectPublicKeyInfo. Reproduce it from acp-verification-key.json in a trust-ceremony evidence pack — the ceremony writes that file and records its digest in the transcript. (The /evidence/export API returns a different artefact, a signed bundle, which carries no keyring file.)

PUB=$(jq -r '."ev-k2".public' acp-verification-key.json)

{ printf '302a300506032b6570032100%s' "$PUB" | xxd -r -p | base64 -w0 \
    | sed -e '1s/^/-----BEGIN PUBLIC KEY-----\n/' -e 's/$/\n-----END PUBLIC KEY-----/'
  printf '\n'; } > key.pem

openssl pkey -pubin -in key.pem -pubout -outform DER | sha256sum

If that value does not match the fingerprint above, stop and contact us through a channel you already trust. Note that the ceremony transcript reports a different, shorter value it also calls a fingerprint — the first 32 hex characters of SHA-256 over the raw 32-byte key. The two are different algorithms over different inputs and are not meant to match.

This page is discovery, not proof. It is served from a domain we control, so an attacker who controlled that domain could change what you read here. Publishing the fingerprint on our own website and in our own DNS is one source quoted twice, not corroboration. The value is also carried inside a Git tag signed with a key that is neither our evidence key nor tied to this domain, and that signed object — not this page — is the anchor worth relying on. We are working towards inclusion in a public transparency log, where a party other than IntelXview witnesses the record; until that exists, treat this page as a convenience for finding the value quickly.

Rotation: only the currently active key appears above. When we rotate, this page is updated to the new key and the superseded fingerprint is removed. If you hold evidence signed under an earlier key and need its fingerprint, ask us directly — we chose a page that is always current over a growing list nobody re-reads.

Security posture in one page

• Identity: Keycloak OIDC with JWKS-validated RS256 tokens; custom email-OTP MFA authenticator mandatory for all management-plane and OrgAdmin roles.
• Authorisation: OPA policy-as-code with default-deny; explicit approval workflow for sensitive actions; approver must differ from requester (enforced in code).
• Tenant isolation: three independent layers — strict membership check at the API, OPA policy gates, and PostgreSQL Row-Level Security on all tenant-scoped tables.
• Secrets: HashiCorp Vault with AppRole authentication, TLS with CA pinning, persistent audit device.
• LLM request handling: PII scrubber runs before any upstream call; no raw prompt or response content is retained — only SHA-256 hashes and operational metadata, for 30 days.
• Change management: PR flow with required status checks (OpenAPI, OPA tests, PDP regression, backend compile, frontend build, supply-chain audit); semver-tagged CD; SECURITY_CHANGELOG entry required for security-relevant changes; branch protection evidence is published for reviewer diligence.
• Observability: Prometheus metrics; severity-routed Alertmanager pipeline with deadman's-switch heartbeat; per-alert runbooks deep-linked from rule definitions.
• Recovery: RTO 4h / RPO 24h. DR runbooks for Postgres, Vault, Keycloak. Annual DR exercise calendar.

Operational resilience — what happens to your AI estate when we are down

The question a risk officer should ask first. The design answer: for activity routed through ACP's enforcement surfaces, an outage pauses that activity — it never leaves it ungoverned. Each enforcement surface listed below — the agent tool gateway, the agent execution API and change management — fails closed under test, so unavailability degrades to "governed actions wait", not "actions proceed without control or evidence". Preventing workloads from bypassing ACP entirely is a separate control: network enclosure, covered below.

Where the network-enclosure pattern is deployed, direct egress to model providers is blocked at the boundary, so an outage cannot be bypassed by calling providers directly. Recovery objectives are stated above (RTO 4h / RPO 24h) with documented runbooks for the stateful components and an annual DR exercise calendar; deployment topology and the availability roadmap are shared under NDA, consistent with the boundary section below.

Data governance in brief

• Pointer, not value: ACP is designed to hold references and cryptographic digests rather than copies of your content — raw prompts and responses are not retained; evidence records carry SHA-256 hashes that let an auditor verify integrity without ACP storing the underlying data (UK-GDPR data minimisation by design).
• Retention is stated, not implied: the table below gives the retention period per data class; audit and decision evidence is kept 7 years, while operational content classes are measured in days.
• Isolation is layered: the three independent tenant-isolation layers listed above apply to every data class, including evidence and graph reads. Records that reference an actor outside your tenant resolve to a neutral "Platform / external actor" label — no cross-tenant attributes are ever returned.

Compliance programme

IntelXview is running a continuous SOC 2 readiness programme. The May 2026 internal gap assessment scored ~94 % readiness across Trust Services Criteria for Security, Confidentiality, Privacy, and Processing Integrity (Availability is out of scope for this pass). No criterion is currently scored Gap.

Full readiness detail is available under NDA: we can share the internal gap register and the executive summary PDF. This page is not a SOC 2 report. IntelXview is not SOC 2 Type II certified, and the AI Control Plane is not FCA-approved or independently certified. A formal SOC 2 engagement will be undertaken by a licensed CPA firm once remaining readiness items close.

Data handling at a glance

Subprocessors

• DigitalOcean — hosting, Kubernetes, managed PostgreSQL
• GitHub — source hosting and CI/CD
• Stripe — billing and payment processing
• Google Workspace — transactional email
• OpenAI — LLM completion provider (when routed)
• Anthropic — LLM completion provider (when routed)
• DeepSeek — LLM completion provider (when routed) — flagged: prompts transit CN infrastructure; formal DPA pending. Tenant admins can opt out by contacting [email protected].
• Cloudflare — Workers AI LLM backend

Material changes to the subprocessor list are notified to tenant admins at least 15 days in advance.

Reporting a vulnerability

Please send responsible-disclosure reports to [email protected]. We operate a published vulnerability-disclosure policy with defined SLAs (acknowledgement within 3 business days; full assessment within 7 business days). Researchers acting in good faith within the terms of the policy will not be pursued legally.

Asking for more

Enterprise buyers, procurement, technical deep dives (threat model, SBOM, pen-test evidence when available), and customer audits under your own framework: email [email protected]. We share under NDA.

What you won't find here

Detailed architectural diagrams that would aid an attacker, specific IP addresses or internal hostnames, or live secrets. That level of detail is shared under NDA or via an audit agreement.

This page is maintained in docs/compliance/customer-facing/trust-overview.md in the ACP repository. Change log is in version control.