Multi-tenant SaaS
Arc operates the application and managed data services, with logical tenant isolation, regional data-residency options and Arc-managed releases.
- Best suited to
- Fast deployment with managed operations
Security dossier / reviewed
Security and deployment for controlled space programmes
Arc protects controlled space-programme data through isolated access, encryption, exportable audit history and three application deployment choices: multi-tenant SaaS, on-premises and air-gapped. Customer-owned databases are available across those application models as a data-ownership configuration. AI processing follows the boundary selected by each customer: external inference can be governed or disabled, models can be customer supplied, and customer content is never used for training. These controls support programme assurance workflows while certification and regulatory accountability remain with the customer.
01 / Deployment and data boundaries
Put Arc inside the boundary your programme requires
Arc can run as a managed service or inside customer-controlled infrastructure. Bring your own database is available across the deployment models: it changes who owns and operates the data layer, rather than defining a separate hosting environment.
Bring your own database
Keep programme records in a customer-owned database while Arc operates in the selected SaaS, on-premises or air-gapped application model. Connectivity is agreed for that architecture.
- Best suited to
- Customer ownership of the data layer
On-premises
Run the Arc application and database inside customer-controlled infrastructure, with customer policies governing network access, identity, monitoring and approved model endpoints.
- Best suited to
- Controlled enterprise environments
Air-gapped
Operate Arc without required external network calls. Inference remains local or self-hosted, Arc has no standing administrative access and releases follow an offline update process.
- Best suited to
- Disconnected or tightly restricted programmes
Deployment control matrix
Responsibility changes with the boundary
Scroll horizontally to inspect every control boundary.
| Model | Application host | Database owner and location | Model-inference location | Outbound-connectivity requirement | Identity-provider ownership | Backup and monitoring responsibility | Release and update responsibility | Arc administrative access |
|---|---|---|---|---|---|---|---|---|
| Multi-tenant SaaS | Arc-operated shared application plane with logical tenant isolation | Arc-managed in the selected supported region | Configured approved provider or customer endpoint | Internet access protected by TLS | Customer owns users and roles; Arc operates service authentication | Arc | Arc-managed | Restricted to authorised service operations |
| Bring your own database | Follows the selected application model | Customer-owned and operated | Follows the selected application and AI policy | Only the connections agreed for the deployment architecture | Follows the selected application model | Customer for the database; application duties follow the selected model | Follows the selected application model | No database access unless the customer explicitly grants it |
| On-premises | Customer-controlled infrastructure | Customer-managed | Customer-approved endpoint or local model | Customer policy; external AI is optional | Customer-owned identities, roles and access policy | Customer | Coordinated release process | None by default; customer-granted when support requires it |
| Air-gapped | Customer-controlled isolated infrastructure | Customer-managed inside the isolated boundary | Local or self-hosted only | No required external calls | Customer-owned inside the isolated boundary | Customer | Offline update process | No standing Arc access |
02 / AI data privacy and model control
AI follows the programme boundary—not the other way around
Administrators decide where inference happens, which models can be used and whether external AI processing is permitted. Engineers remain responsible for meaningful changes and approvals.
No training on customer content
Arc and enabled model providers never use customer programme content to train models.
Transient inference
Provider processing is limited to returning the requested result and is not incorporated into model weights.
Organisation-specific embeddings
Embeddings and retrieval indexes are isolated to the customer organisation and its selected deployment boundary.
Bring your own model
Customers can connect approved model endpoints or credentials rather than use an Arc-selected provider.
Provider transparency
Administrators can identify the active provider, model and processing boundary for their deployment.
Self-hosted controls
On-premises and air-gapped deployments can keep inference local and disable external AI processing.
03 / Data protection and access
Controls that preserve engineering accountability
Arc combines encryption, isolation, role-based permissions and exportable records so programme teams can protect information without losing the history needed for reviews and assurance.
- 01 Encryption at rest
- AES-256 protects stored programme data.
- 02 Encryption in transit
- TLS 1.2 or later protects data moving between authorised systems.
- 03 Tenant isolation
- Logical controls separate organisations in the multi-tenant service.
- 04 Granular access
- Roles govern viewing, editing, reviewing, approving and administration.
- 05 Exportable audit logs
- Access, changes, approvals and AI actions can be exported for review.
- 06 Data residency
- Regional residency options keep managed data in an agreed supported region.
04 / Programme assurance
Space standards and regulatory workflows Arc can support
Arc can support the controlled requirements, traceability, baselining, review and verification-evidence workflows used within these frameworks. Using Arc does not itself certify a programme or establish regulatory compliance.
Workflow support ≠ agency approval
Applicable standards, contracts and licences govern the customer’s complete people, process and technology environment. Project tailoring and the customer’s assurance plan determine how Arc is configured and what evidence must be produced.
ECSS / ENGINEERING
Requirements, configuration, reviews and verification
Arc supports project-tailored requirements, bidirectional traceability, baselines, controlled changes, review decisions and verification evidence used with ECSS-E-ST-10, ECSS-E-ST-10-06, ECSS-E-ST-10-02, ECSS-M-ST-10-01 and ECSS-M-ST-40. Alignment to an ECSS workflow is not ESA approval.
ECSS / SECURITY
Security through the space-system lifecycle
Arc can hold security requirements, ownership, information markings, change history and verification evidence used in a tailored ECSS-E-ST-80C process. Programme accreditation and any classified-information controls remain outside the product claim.
NASA / SYSTEMS ENGINEERING
Requirements management and V&V evidence
Arc supports requirements, configuration and data management, technical reviews, traceability, verification and validation records associated with NASA systems engineering practice. NASA requirements apply to suppliers when they are flowed down through the relevant contract; Arc is not NASA approved or certified.
UK / SPACEFLIGHT
Cyber-risk strategy and licence evidence
Arc’s controlled records, access boundaries and linked evidence can support a licensee’s cyber-risk assessment, security strategy and safety-case evidence. The Civil Aviation Authority is the UK spaceflight regulator; the UK Space Agency toolkit is guidance, and responsibility remains with the licensee.
NIST / SPACE OPERATIONS
Commercial satellite cybersecurity assessment
NIST IR 8441 provides voluntary cybersecurity outcomes for commercial satellite operations. Arc can organise requirements, ownership, mitigations and verification evidence used in a customer-defined assessment; the publication is not a product certification programme.
US / CONTROLLED INFORMATION
Contract-specific CUI environments
Customer-controlled Arc deployments can be assessed within a customer-defined NIST SP 800-171 or CMMC boundary when a contract requires it. Suitability depends on the complete configured enclave and contractual flow-down; Arc does not claim that its multi-tenant SaaS is automatically suitable for CUI.