Compliance and the trust center
Context’s audit reports, certifications and policies are in the trust center. This page shows where each document is, how to request the gated ones, and which docs pages answer each part of a security questionnaire.
Audit reports and certifications
The trust center document library lists every document. Context holds SOC 2 and ISO 27001. The reports and assessments are gated: you request them, and Context shares them under NDA where required.
| Document | What it is |
|---|---|
| SOC 2 report | The current independent audit report for the Context platform |
| ISO 27001 certificate | Certification of Context’s information security management system |
| Penetration-testing report (latest) | The most recent third-party penetration test of the platform |
| CAIQ security questionnaire | A pre-completed Consensus Assessments Initiative Questionnaire |
| Security policies (combined) | The policies of Context’s written information security program, in one document |
| Security & compliance program update | A point-in-time summary of the compliance program and what changed |
| Security architecture whitepaper | The control-plane and sandbox split, tenant isolation and the authorization model in depth |
The trust center also has W-9 and evidence-of-insurance documents for vendor onboarding, under Procurement & operations.
Request a gated document
- Open the document library and select Request access.
- Enter your first and last name, work email and company.
- Choose a reason: Security review, Procurement, Compliance audit or Other.
- Choose Full access: everything listed, or Specific resources and pick the documents you need.
- Select Submit request.
You can also email security@context.ai with what your review needs. Documents that require an NDA are shared once the NDA is in place.
To hear when documents or subprocessors change, click Subscribe to updates on the trust center’s updates page. It opens an email to security@context.ai.
Data processing and subprocessors
These documents are public and linked directly from the trust center:
| Document | Where |
|---|---|
| Data Processing Addendum (DPA): how customer personal data is processed, protected and transferred | Data Processing Addendum |
| Subprocessor list: the vendors the DPA refers to, with each one’s purpose and region | Subprocessors |
| Privacy Policy | Privacy Policy |
| Terms of Service | Terms of Service |
| Acceptable Use Policy | Acceptable Use Policy |
| Security and deployment FAQ: deployment modes, credential brokering, training boundaries and audit | Trust center FAQ |
Subprocessor changes carry advance notice under the DPA.
Answer a security questionnaire
Start with the CAIQ: it answers the standard questions, so request it with the SOC 2 report. For questions about how a self-hosted install works, these pages give the detail. They describe a self-hosted install on AWS.
| Questionnaire area | Where to look |
|---|---|
| Architecture, deployment and shared responsibility | Security architecture |
| Network security, segmentation and outbound traffic | Network boundaries |
| Workload isolation | Agent sandbox |
| Encryption and where data is stored | Data at rest |
| Data retention, deletion and legal hold | Data retention |
| Secrets and credential management | Credential handling |
| Sign-in, single sign-on and user provisioning | Sign-in options and Sign-up and accounts |
| Access control and authorization | Permissions reference and Roles matrix |
| Privileged and administrator access | Administrator access and audit |
| Logging and audit trail | Audit log |
| Change management and releases | Change management |
| AI risks such as prompt injection and excessive agency | Agent threats and controls and Agents and approvals |
| Third parties and model providers | System context and Model gateway and third parties |
| Hardening and known weaknesses | Known issues and hardening and Security configuration reference |
| Support and incident response | Get help and SLAs and priorities |
Report a vulnerability or security concern
Email security@context.ai. This covers a vulnerability in the Context platform, a connector or Context’s website. Include:
- The affected surface
- Steps to reproduce it
- The impact you saw
Context coordinates the fix and the disclosure timing with you in that email thread. The same address is in the security.txt file the Context app serves at /.well-known/security.txt.
For an incident that affects your deployment’s service, use the routes on Get help.
Self-hosted installs
On a self-hosted install, your organization runs the infrastructure and Context supplies the software. Who owns each part is in Responsibilities, and the decisions to settle with Context are in What your team decides.
In the reference architecture, model requests go to a LiteLLM model gateway that your organization operates, and your organization holds the agreements with the model providers behind it. Which provider hosts each model is set in your gateway (see System context). By default the installer runs the gateway inside your cluster (Run LiteLLM in-cluster); LiteLLM Base URL points the deployment at an external gateway, for example one inside your network.
With Forward User Email to LiteLLM on (the default), each model request that reaches your gateway carries the email of the person who sent the work, so your gateway’s spend reports can name them. The email goes only to your gateway. Turn the setting off if your organization doesn’t allow staff emails to be sent to it; requests then carry only opaque IDs.
Next steps
- Security architecture: the components of a self-hosted install and who owns each one.
- What your team decides: the decisions and confirmations a self-hosted install needs.
- Data at rest: where data is stored and who sets its protection.
- Audit log: read and export the record of who did what.
- Get help: reach Context support.