Trust & Safety
Context Trust & Safety Center
Security, compliance, and data-handling documentation for the Context platform. Deployment models, certifications, policies, subprocessors, and how to request audit artifacts.
Overview
Security posture at a glance
The controls that hold in every deployment mode, and where each one is documented. The sections below carry the detail.
Encryption in transit and at rest
Customer personal data is encrypted in transit using TLS and at rest using industry-standard encryption.
Documented in Data Processing Addendum
Identity from your IdP
Agents get identity from your identity provider. Runs in production at Qualcomm with SSO-scoped permissions.
Documented in Qualcomm case study
Per-action authorization and audit
Every action is authorized against policy and recorded in an append-only trail: task, tool calls, approvals, result.
Documented in the audit-story FAQ
Credentials brokered at runtime
Credentials are brokered to connectors at runtime — never written into runbooks or prompts.
Documented in the credentials FAQ
Isolated execution, your perimeter
Engine runs each agent in an isolated environment, and the platform deploys managed, in your VPC, on-premises, or air-gapped.
Documented in the agent-access FAQ
Documented data boundaries
Run traces stay inside your deployment. What crosses the boundary is documented during implementation, per architecture.
Documented in deployment models below
FAQ
Frequently asked questions
Full FAQDeployment
Where does Context run?
Context supports a managed deployment, deployment in a customer VPC, on-premises deployment, and environments designed for disconnected operation. Model endpoints, connectors, the update process, and the support model are configured for the selected architecture.
What data leaves our boundary?
Run traces stay inside your deployment. What crosses the boundary depends on the architecture you select — in a VPC, on-premises, or air-gapped deployment the platform itself runs inside your perimeter. Data-flow boundaries are documented during implementation.
Is it the whole platform inside our perimeter, or just inference?
The entire platform. Context deploys the control plane, execution, and run history — not just model inference — in your VPC, on-premises, or air-gapped.
Security
Do agents hold credentials?
No. Credentials are brokered to the connector at runtime rather than written into the runbook or prompt. Depending on the target system and deployment, the connector can use delegated user identity or a scoped service identity. Credential storage, rotation, and revocation are reviewed as part of the deployment design.
How do agents access our systems?
Engine runs each agent in an isolated environment and gives it only the tools configured for the runbook. Connectors use the authentication method supported by the target system, such as OAuth or a scoped service credential. Read access, write access, and human approval can be configured separately.
What does the audit story look like?
A run records the task, model and tool calls, source references, actions, approvals, and result. Reviewers can inspect the sequence and compare the output with its rubric. Export and retention requirements are configured for the customer's deployment.
How do we get security documentation for a review?
Email security@context.ai with what your review needs. Public documents on this page are linked directly; anything that requires an NDA is shared through your Context contact during evaluation.
Privacy
Is our data used to train models?
Context does not use one customer's traces, corrections, or institutional context to train models for other customers. Model-provider retention and training settings depend on the endpoints a customer chooses, so those controls are documented and verified during deployment.
Which model providers are involved, and what do they see?
Context is model-agnostic: Claude, GPT, Gemini, Kimi, or open weights. Available endpoints depend on your deployment architecture, and provider retention and training settings are documented and verified during implementation.
Deployment
Deployment models and data boundaries
ContactFour ways to run Context, one boundary story for each. The deployment menu is not an enterprise add-on — it is the platform's shape. Pick the perimeter; the control plane, execution, and run history deploy inside it.
Managed
Context operates the deployment for you. The fastest path to production when a hosted control plane fits your policy.
Data boundary
Run traces stay inside your deployment. Model-provider retention and training settings are documented and verified during implementation.
Your VPC
The platform runs inside your own AWS, Azure, or GCP account, under your cloud controls and your keys to the perimeter.
Data boundary
Sensitive data is not moved into someone else's cloud — the deployment lives in an account you own and govern.
On-premises
Context runs in your data center, on infrastructure you operate, inside your perimeter.
Data boundary
The deployment is operated inside your perimeter. Data-flow boundaries are documented during implementation.
Air-gapped
For environments designed for disconnected operation. The entire platform deploys inside the boundary — not just inference.
Data boundary
Built for disconnected operation: the entire platform, including run history, deploys inside the boundary.
In every mode: agents get identity from your IdP, every action is authorized against policy and recorded in an append-only trail, and credentials are brokered to connectors at runtime — never written into runbooks or prompts.
Compliance
Certifications and attestations
Ask usSOC 2
AttestedAttestation details for this page are being documented — ask us for what your review needs.
Additional attestations are added as audits complete. For the current status of the compliance program, contact security@context.ai.
Documents
Policies and documentation
Request accessAudit reports & assessments
Being populated
Audit artifacts are shared once they are confirmed, and under NDA where required. Request what your review needs at security@context.ai.
Public policies
- View
Data Processing Addendum
How customer personal data is processed, protected, and transferred.
- View
Subprocessor list
The vendor list referenced by the DPA, with purpose and location.
- View
Privacy Policy
What we collect, why, and the rights you can exercise.
- View
Terms of Service
The agreement that governs use of the Context platform.
- View
Acceptable Use Policy
What the platform may and may not be used for.
- View
Security & deployment FAQ
Deployment modes, credential brokering, training boundaries, and the audit story.
Subprocessors
Subprocessors
DPA listBeing populated
The per-vendor table — purpose, region, and each vendor's own trust page — appears here once our team confirms the full inventory. The list referenced by our Data Processing Addendum is published at /subprocessors.
Disclosure
Responsible disclosure
ReportFound a vulnerability in Context — the platform, a connector, or this site? Report it to security@context.ai. Include the affected surface, reproduction steps, and the impact you observed; remediation and disclosure timing are coordinated with you through that thread.
Updates
Change log
Subscribe to updatesBeing populated
Changes to certifications, documents, and the subprocessor list will be logged here as they happen. Subprocessor changes also trigger notice under our Data Processing Addendum.