Security & Trust
How MPP protects attestation integrity, what Q2X is responsible for, and what your organisation is responsible for.
The Commercial Promise
MPP is a security product. The integrity of attestation certificates, audit logs, and tenant isolation is what you are paying for. This page explains exactly how each guarantee is delivered and where the boundary between Q2X's responsibility and yours sits.
Signing Key Security
The private key that signs every attestation certificate never exists in code, environment variables, or files. It lives in a cloud Hardware Security Module (HSM) — the same hardware-level protection used by banks and payment processors.
When a publisher submits a package, our system sends a signing request to the HSM. The HSM returns the cryptographic signature. The raw private key never leaves the hardware module.
A full breach of our application servers would not expose the signing key. An attacker who gained access to our web infrastructure could not forge attestation certificates, because the key is not there.
Audit Log Immutability
Every package publish, version change, API key operation, and team login is recorded in an append-only audit log. "Append-only" is enforced at the database level — a trigger rejects any UPDATE or DELETE on the audit log table. Application code cannot bypass this.
This matters for two reasons:
Forensic integrity. If something goes wrong, the audit trail cannot be altered after the fact — by anyone, including Q2X staff.
Compliance evidence. For FCA AI governance reviews, internal security audits, or incident response, the log provides a permanent, tamper-evident chain of events: who published what, from which account, at what time. Enterprise audit logs are retained for 12 months and can be exported as CSV from the dashboard at any time.
Tenant Isolation
Every package record, audit log entry, and usage data point is tagged with your organisation's tenant_id. Row-level security (RLS) policies in the database enforce that queries can only return data belonging to the authenticated tenant — at the database level, independently of application logic.
This means your packages and audit logs are never visible to another tenant, even if there were a bug in the application layer.
Service Availability
Enterprise plan customers are covered by a 99.5% uptime SLA — a maximum of approximately 3.6 hours of unplanned downtime per month.
If the registry is temporarily unreachable, the MPP runtime supports a configurable attestation cache grace period: your systems continue using a cached attestation for a set window before refusing to run unverified tools. A registry outage does not immediately break your production deployments.
Live uptime history is at /status.
What Q2X Is Responsible For
- Attestation integrity — the records we sign accurately reflect what was submitted; they have not been backdated or forged
- Tenant isolation — your data is never accessible to another tenant under any circumstances
- Signing key security — the HSM holding the attestation private key cannot be compromised via our application
- Audit log immutability — no one, including Q2X, can retroactively alter audit records
- API availability — the 99.5% uptime SLA
- Vulnerability disclosure — if a flaw is found in the MPP platform, we disclose it and issue a fix
What Your Organisation Is Responsible For
- The content you submit for attestation. We certify a package is what you say it is and has not changed. We make no claim about whether the code is safe, correct, or appropriate for your use case.
- Your runtime environment. The servers, cloud accounts, and networks where attested tools actually execute.
- Access controls. Who in your organisation can publish to your namespace. If a team member publishes malicious code under your namespace, the attestation confirms it came from your account — not that it is safe.
- Correct integration. You must actually configure your agent framework to verify attestations before loading tools. Bypassing the check removes the protection.
- Your API keys and SSO configuration. Credential security on your side.
This is the same model as a code-signing certificate authority: the CA certifies identity and integrity, not the safety of the signed code. The same boundary applies here.
For Regulated Deployments
For organisations subject to FCA AI governance requirements, GDPR, or financial services procurement questionnaires:
- Audit logs provide a complete chain of custody: package publish, version changes, API key operations, and SSO logins — all timestamped and immutable
- 12-month retention for Enterprise plans aligns with common FCA evidence requirements
- Tenant isolation is enforced at the database level, not just application logic — satisfies data segregation requirements
- The Data Processing Agreement sets out sub-processors, data retention periods, and deletion timelines
- Our liability is capped at 12 months of fees paid — standard for SaaS security products
See our Data Processing Agreement and Security Policy for the full technical and legal detail.