Security & Compliance

We build the control plane that lets an enterprise see, govern, and prove what its AI agents are allowed to do. A company that sells governance has to be governed at least as well as the systems it protects. So we hold our own engineering, infrastructure, and data handling to the standard we ask customers to hold their agents to, and we treat security as a property of the design rather than a layer added at the end.

Product security

• Least privilege by default. Every service, credential, and internal actor runs with the narrowest set of permissions its job requires, the same principle TESSERACT enforces for agents. Standing access is minimised in favour of scoped, time-limited grants that are logged and reviewed.
• Tenant isolation. Customer environments are logically separated so that one customer's data and activity cannot be reached from another's, and isolation boundaries are a first-class part of the architecture rather than a configuration afterthought.
• Encryption in transit and at rest. Data is encrypted on the wire with modern TLS and encrypted at rest under keys held in dedicated key management with strict access control. We support customer-managed keys for deployments that require them.
• Tamper-evident evidence. The audit records the product produces are designed to be independently verifiable, so a customer, an auditor, or a regulator can trust what happened without having to trust us.
• Secure development lifecycle. Changes are peer-reviewed, tested, and put through automated security checks before release. Development and production are kept separate, and production access is limited, logged, and periodically reviewed.
• Supply-chain and dependency hygiene. We inventory the components we depend on, monitor them for known vulnerabilities, and patch on a risk-based schedule. We deliberately prefer a small, well-understood dependency surface over convenience.
• Secrets management. Credentials and keys live in dedicated secret stores, never in source code, and are rotated. Access to secrets is scoped and audited.
• Logging, monitoring, and detection. Security-relevant events across our infrastructure are centrally collected and monitored, with alerting tuned to the behaviours that matter rather than to noise.
• Vulnerability management. We run regular scanning across our code and infrastructure, and ahead of general availability we commission independent penetration testing. Findings are triaged by severity and tracked to closure.
• Resilience and recovery. We design for availability and for clean recovery, with backups, tested restore procedures, and an incident-response process that defines how we detect, contain, communicate, and learn from an event.

Data protection and privacy

• Data minimisation. We collect and retain only what a task requires, and we design features so that sensitive data does not leave a customer's boundary unless it genuinely has to.
• Deployment choice for regulated estates. The control plane is designed to run as SaaS, in a hybrid model, or fully inside a customer's own environment, so data-residency, sovereignty, and isolation requirements can be met without compromise.
• Retention and deletion. Data is held for defined periods tied to its purpose and deleted on a schedule or on request, subject to legal and contractual obligations.
• Sub-processors. We keep the set of third parties that process data deliberately small, hold them to obligations equivalent to our own, and will publish and maintain a current sub-processor list.
• Privacy by design. Our handling of personal data is built around the GDPR and UK GDPR principles of lawfulness, purpose limitation, minimisation, and accountability, with data-protection considerations assessed before a feature ships rather than after.

Compliance and regulatory alignment

Our customers operate in regulated industries, and increasingly the agents they deploy fall under new supervision of their own. We are building the product and our internal control environment to meet the frameworks those customers and their regulators rely on.

• SOC 2. We are implementing controls mapped to the SOC 2 Trust Services Criteria and are working toward a Type II report against them.
• ISO/IEC 27001. Our information-security management approach is aligned to ISO 27001, with certification on our roadmap.
• GDPR and UK GDPR. We act as a processor for customer data and design for the obligations that role carries, including support for data-subject rights and lawful cross-border transfer safeguards.
• Financial-services operational resilience. For customers in banking, markets, and insurance, we build toward the operational-resilience and third-party-risk expectations set by frameworks such as DORA in the European Union and equivalent supervisory guidance elsewhere, including the auditability those supervisors expect of a critical provider.
• Emerging AI regulation. We track the EU AI Act and comparable regimes, and we build the governance and audit capabilities that help our customers evidence how their agents are controlled and how decisions can be reconstructed.

We will publish attestations and reports as they are completed. Until then we are precise about what is in place and what is in progress, and we are glad to walk security and compliance teams through our current posture under NDA.

Shared responsibility

Security is a shared responsibility. We are accountable for the security of the platform, and we give customers the controls, evidence, and documentation to operate it safely inside their own environment. We respond to security questionnaires and vendor due-diligence reviews, and every design-partner engagement begins with a review of exactly these questions, not a slide that waves them away.

Reporting a security concern

If you believe you have found a vulnerability in our product or systems, we want to hear from you, and we extend clear protections to good-faith researchers. Our disclosure process, scope, and safe-harbour commitments live on a dedicated page.