Context Pilot / Trust Center
Context Pilot / Trust Center / Compliance

Compliance Framework

Last updated: June 22, 2026
Policy CF-2.0

This document assesses Context Pilot's alignment with major regulatory and industry compliance frameworks. As a locally-deployed, open-source tool with no cloud infrastructure, Context Pilot's compliance profile differs fundamentally from cloud-hosted SaaS applications.

1. Regulatory Framework Assessment

The following assessments evaluate Context Pilot's applicability and alignment with each framework. Because Context Pilot is a locally-deployed tool that does not collect, process, or store user data on behalf of a service provider, many traditional compliance frameworks apply differently or are structurally satisfied.

GDPR (General Data Protection Regulation)

Compatible

Context Pilot does not act as a data controller or data processor as defined under GDPR. No personal data is collected, stored, or processed on Context Pilot infrastructure (which does not exist). The operator is the sole data controller for any data processed locally on their workstation.

  • Data minimization: Satisfied by architecture. No data is collected beyond what the operator explicitly provides to their configured LLM provider.
  • Purpose limitation: All data processing serves the operator's immediate coding assistance needs. No secondary use occurs.
  • Storage limitation: All data resides on the operator's filesystem under their full control. No external retention.
  • Data subject rights: Exercisable through direct filesystem access. See the Data Privacy page for details.
  • Third-party transfers: LLM API calls may constitute a data transfer to the provider's jurisdiction. This is governed by the operator's agreement with their chosen provider, not by Context Pilot.

SOC 2 (Service Organization Control)

Not Applicable

SOC 2 is designed for service organizations that process, store, or transmit customer data through cloud infrastructure. Context Pilot does not operate as a service organization: there is no cloud service, no customer data processing, and no multi-tenant infrastructure. A SOC 2 engagement would be structurally inapplicable.

However, the trust service criteria addressed by SOC 2 are substantially satisfied through Context Pilot's architectural controls:

  • Security: Local-first architecture, no network attack surface, path traversal protections, SSE ticket authentication
  • Availability: No centralized service to suffer outages; each deployment is independent
  • Processing Integrity: SHA-256 hash chain for critical files, 1001 enforced lint rules, automated CI
  • Confidentiality: No data collection infrastructure; credentials isolated per-provider
  • Privacy: No telemetry, no analytics, no user tracking; all data local-only

ISO 27001 (Information Security Management)

Not Certified

Context Pilot has not pursued ISO 27001 certification as it is designed for organizations operating information security management systems for cloud services. The project implements controls aligned with ISO 27001 Annex A categories where applicable to an open-source development tool:

  • A.8 Asset Management: All code assets tracked in Git with signed commits and CI enforcement
  • A.9 Access Control: Filesystem-scoped access, credential isolation, SSE ticket system
  • A.12 Operations Security: Automated build pipelines, dependency scanning (Dependabot), CodeQL analysis
  • A.14 System Development: 1001 lint rules, structural enforcement (500-line/8-entry limits), hash chain integrity
  • A.16 Incident Management: Responsible disclosure program via GitHub Security Advisories

HIPAA (Health Insurance Portability and Accountability Act)

Not Applicable

Context Pilot is a general-purpose coding assistant. It does not process Protected Health Information (PHI) by design. If an operator uses Context Pilot in a healthcare context, the operator is responsible for ensuring that no PHI is transmitted to LLM providers without appropriate Business Associate Agreements (BAAs) in place with those providers.

CCPA (California Consumer Privacy Act)

Compatible

Context Pilot does not sell, share, or collect personal information as defined under CCPA. The software does not have the technical capability to collect consumer data. No opt-out mechanism is required because no data collection occurs.

2. Open-Source Licensing

Context Pilot is distributed under the MIT License, one of the most permissive open-source licenses available.

MIT License

Permissive

The MIT License grants the following rights without restriction:

  • Commercial use in any context, including proprietary products
  • Modification and distribution of source code
  • Private use without disclosure obligations
  • No copyleft or share-alike requirements

The sole obligation is preservation of the copyright notice in distributed copies. The license includes a standard disclaimer of warranty and limitation of liability.

Dependency License Audit

Clean

All direct dependencies use permissive open-source licenses (MIT, Apache 2.0, BSD). No copyleft (GPL, AGPL) or proprietary dependencies exist in the dependency tree. The project's Cargo.lock and pnpm-lock.yaml files provide reproducible dependency resolution for independent audit.

3. Security Testing and Verification

Context Pilot employs continuous automated security verification as part of its development process. The open-source nature of the project additionally enables independent community audit.

Control Mechanism Frequency Status
Static Analysis CodeQL (GitHub Advanced Security) Every push and pull request Active
Dependency Scanning GitHub Dependabot (Rust + npm) Continuous monitoring Active
Lint Enforcement 1001 compiler/Clippy rules (980 forbid, 21 deny) Every build Active
Integrity Verification SHA-256 hash chain (12 protected files) On modification of protected files Active
Format Enforcement rustfmt (Rust) + ESLint (TypeScript) Every build and CI run Active
Community Audit Open-source codebase (MIT License) Continuous public availability Active

4. AI-Specific Regulation

As an AI-powered development tool, Context Pilot's regulatory posture includes assessment against emerging AI-specific frameworks.

EU AI Act

Low Risk

Under the EU AI Act risk classification framework, Context Pilot is categorized as a low-risk or minimal-risk AI system. It does not perform biometric identification, critical infrastructure management, education scoring, employment filtering, law enforcement, or any other high-risk use case enumerated in Annex III. Context Pilot is a general-purpose coding assistant that operates under direct human supervision at all times.

  • Human oversight: All AI outputs require explicit human review. The tool does not make autonomous decisions affecting natural persons.
  • Transparency: The system is clearly identified as an AI assistant. Users interact with it knowingly and intentionally.
  • No prohibited practices: No subliminal manipulation, social scoring, or real-time biometric identification capabilities exist.
  • General-purpose AI model: Context Pilot does not train or fine-tune AI models. It uses third-party provider APIs for inference only. GPAI obligations apply to the model providers (Anthropic, OpenAI, etc.), not to Context Pilot.

NIST AI Risk Management Framework (AI RMF 1.0)

Aligned

Context Pilot's design aligns with the NIST AI RMF's core functions:

  • Govern: Open-source development with public code review, documented architecture, and transparent decision-making.
  • Map: Clear system boundaries — Context Pilot is a developer tool, not an autonomous decision system. Usage context is well-defined.
  • Measure: All AI interactions are logged locally (conversation history) for operator review. Cost tracking provides usage visibility.
  • Manage: Guard rails (cost limits, message limits, duration limits) prevent runaway AI operations. Human approval is required for destructive actions.

Responsible AI Practices

Implemented

Context Pilot implements multiple safeguards for responsible AI use:

  • Cost controls: Per-agent budget limits prevent uncontrolled API spending. Circuit breakers halt operations when budgets are exceeded.
  • Audit trail: Complete conversation history, tool call logs, and decision traces are preserved locally for operator review.
  • Model transparency: The operator selects and configures the LLM model. Model identity is always visible. No hidden model switching occurs.
  • Output attribution: AI-generated content is clearly distinguished from user input in the conversation interface.
  • Operator control: The operator can interrupt, redirect, or terminate AI operations at any time through guard rails, keyboard shortcuts, or process termination.

5. Export Controls & Sanctions Compliance

This section addresses Context Pilot's posture regarding export controls and international trade sanctions.

Encryption Export Classification

Standard

Context Pilot uses only standard, commercially available cryptographic implementations (TLS via OpenSSL/rustls, SHA-256 via the sha2 crate). No custom or novel cryptographic algorithms are implemented. The software falls under EAR Exception TSU (Technology and Software Unrestricted) for publicly available encryption source code. As open-source software published on GitHub, it qualifies for the publicly available exemption under both US EAR and EU Dual-Use Regulation.

Sanctions Compliance

Context Pilot is distributed as open-source software under the MIT License. Distribution is subject to GitHub's terms of service and applicable US export control laws. The software itself does not interact with financial systems, payment processors, or sanctioned entities. Operators are responsible for ensuring their use of third-party API providers complies with applicable sanctions in their jurisdiction.

6. Accessibility

Context Pilot is committed to making its interfaces accessible to all users.

Web Interface

In Progress

The web frontend uses semantic HTML, ARIA attributes, and keyboard-navigable controls. The interface is built with React and shadcn/ui components that include accessibility foundations. Current accessibility features include:

  • Semantic HTML structure with proper heading hierarchy
  • Keyboard navigation for all interactive elements
  • Sufficient color contrast ratios for text and interactive elements
  • Screen reader compatibility for core workflows
  • No motion-sensitive content or auto-playing media

Formal WCAG 2.1 AA compliance audit has not yet been conducted. Accessibility improvements are accepted as contributions and prioritized alongside feature development.

Terminal Interface (TUI)

Screen Reader Compatible

The terminal user interface (TUI) renders through standard terminal emulators and is compatible with terminal-based screen readers. All interactive elements are keyboard-driven by design (the TUI has no mouse interaction as its primary mode). Color is used for enhancement only — all information is also conveyed through text labels and structural formatting.