Trust & Safety
Context Trust & Safety Center
Security, compliance, and data-handling documentation for the Context platform. Deployment models, security controls, policies, subprocessors, and how to request audit artifacts.
Overview
Security posture at a glance
Context applies the same security controls across every deployment mode, from managed to air-gapped: identity from your IdP, per-action authorization, isolated execution, and documented data boundaries.
Encryption in transit and at rest
Customer personal data is encrypted in transit using TLS and at rest using industry-standard encryption.
Identity from your IdP
Agents get identity from your identity provider. Runs in production with SSO-scoped permissions.
Per-action authorization and audit
Every action is authorized against policy and recorded in an append-only trail: task, tool calls, approvals, result.
Credentials brokered at runtime
Credentials are brokered to connectors at runtime — never written into runbooks or prompts.
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 data boundaries
Run traces stay inside your deployment. What crosses the boundary is documented during implementation, per architecture.
Controls
Security controls
View all controls →Infrastructure security
- Encryption in transit
- Encryption at rest
- Network segmentation and firewalling
Reviewed Aug 2026View more →Identity & access
- Role-based access control
- MFA for administrative access
- Prompt access revocation
Reviewed Aug 2026View more →Operational security
- Vulnerability scanning and patching
- Third-party penetration testing
- Logging and monitoring
Reviewed Aug 2026View more →Organizational security
- Background checks
- Confidentiality obligations
- Security awareness training
Reviewed Aug 2026View more →Data & privacy
- No cross-customer training
- Run traces stay in your deployment
- Deletion and return of data
Reviewed Aug 2026View more →
FAQ
Frequently asked questions
View the full site FAQ →Deployment
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?
Use the request-access form on this page, or email security@context.ai with what your review needs. Public documents are linked directly; documents that require an NDA are shared once it is in place.
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
View full documentation →Four ways to run Context, each with an explicit data boundary. 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
View program details →Being populated
Compliance documentation for the current audit cycle is available on request. For the status of specific attestations, contact security@context.ai.
Documents
Policies and documentation
Public documents are linked directly. Gated documents are shared on request, under NDA where required.
Audit reports & assessments
Penetration-testing report (latest)
The most recent third-party penetration test of the platform.
CAIQ security questionnaire
Pre-completed Consensus Assessments Initiative Questionnaire for self-serve review.
Security policies (combined)
The policies of the written information security program, combined in one document.
Security & compliance program update
Point-in-time summary of the compliance program and what changed.
Security architecture
Security architecture whitepaper
The full architecture behind the public principles: the control-plane/sandbox split, tenant isolation, and the authorization model in depth.
Software Bill of Materials (SBOM) — latest release
Per-release SBOM with signed build provenance. On the security roadmap; requestable when the supply-chain work ships, and matters most for self-hosted installs.
Hardened base-image inventory
The minimal, pinned, regularly rebuilt base images shipped identically to managed and self-hosted. On the security roadmap; requestable once published.
Procurement & operations
W-9
Taxpayer identification form for vendor onboarding.
Evidence of insurance
Current certificate of insurance for procurement review.
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
View the DPA list →| Vendor | Purpose | Region | Website |
|---|---|---|---|
Amazon Web Services, Inc. Cloud infrastructure | Cloud infrastructure and hosting | United States | aws.amazon.com (opens in new tab) |
Vercel Inc. Web hosting | Website and edge hosting | United States | vercel.com (opens in new tab) |
Anthropic, PBC AI model inference | AI model inference | United States | anthropic.com (opens in new tab) |
OpenAI, LLC AI model inference | AI model inference | United States | openai.com (opens in new tab) |
Datadog, Inc. Monitoring | Application logging and monitoring | United States | datadoghq.com (opens in new tab) |
Grafana Labs Monitoring | Metrics dashboards and observability | United States | grafana.com (opens in new tab) |
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 updatesTrust center expanded
GeneralPublished August 14, 2026
Deep-dive documentation published for deployment models, identity and authorization, data handling, and the compliance program, with the full document library and request-access flow.
Subprocessor list updated
GeneralPublished June 9, 2026
Datadog and Grafana Labs listed for application logging, monitoring, and observability. Subprocessor changes carry advance notice under the DPA.
Penetration-testing report available
CompliancePublished May 12, 2026
The latest third-party penetration test of the platform completed; the report is available on request.