Skip to content
Project VELAProject VELA

Security overview

VELA is built for the most conservative operators — sovereign programmes and defence-adjacent missions. Security is architectural, not a bolt-on. This page is the model; the zero-trust posture, the advisory boundary, and the RBAC policy go deeper.

The load-bearing property: no commanding

VELA reads telemetry and produces advisories. It constructs, formats, and transmits no telecommands. This is not a promise — it is enforced:

  • scripts/guardrails/no-commanding.sh greps apps/ and vela/ for command issuance identifiers (issueCommand, sendCommand, send_command, sendTelecommand, transmit_command, dispatchCommand, uploadCommand, /api/**/commands, …).
  • It runs as a pre-commit hook and in two CI workflows.
  • Reading command history (get_command_history) and the telecommand context filter are deliberately allowed and are core features — they are how VELA distinguishes a real fault from an expected command response.

This boundary is the moat, not a limitation

An advisory, human-authorized tool is what a mission-assurance team, an insurer, and a defence programme will trust on a live fleet. VELA gets more autonomous over time by auto-releasing advisories as confidence calibration earns it — command execution always stays with the operator’s own mission-control system.

Grounding integrity

Every narrative/procedure claim carries Citation objects that resolve via vela.audit.citation_check. The rule is symmetric and both halves are enforced:

  • a grounded step with no citations is a violation → emit UNGROUNDED instead;
  • an UNGROUNDED step that carries citations is also a violation → it must carry none.

check_citations returns ok (integrity holds) and releasable (ok and no ungrounded steps). A hallucinated reference is a sev-1 — see the citation-integrity incident-response runbook.

Threat model & zero-trust posture

The zero-trust posture covers the trust boundaries in full. In summary:

  • Data-in never becomes action-out. The only mutating operation is releasing a drafted advisory to operators; there is no path from ingested data to a spacecraft command.
  • Agents are sandboxed to the MCP boundary (import-linter enforced) — reasoning cannot reach a store or adapter directly.
  • Determinism where possible — graph traversal, event forming, and citation checking are deterministic and unit-tested; replay is seeded and as_of is fixed.

Identity & access control

  • RBAC — viewer / operator / approver. The release of any advisory is gated behind an explicit, role-checked approval. The server (a 403) is the real enforcement point; the UI only gates affordances.
  • Enterprise SSO — SAML and OIDC, behind a build_authenticator seam.
  • Provisioning — SCIM 2.0 (Okta / Entra / Keycloak), tenant-partitioned.
  • Secrets — API keys and DB passwords are read from the environment at connect time, never from config files.

Tenant isolation

Every KG read goes through a store scoped to the caller’s tenant, and the whole investigation (event → report → record → audit) is tagged with the caller’s tenant. Per-tenant encryption keys and customer-managed keys are on the roadmap roadmap.

Auditability

Every investigation, approval, and release is recorded in an immutable audit trail, and advisories can be exported to a SIEM (CEF/OCSF/JSON) on release. graph.get_state_history() yields the forensic replay sequence — “one investigation, one record”. Audit-log retention is governed by the retention policy.

Air-gap & data residency

VELA runs fully air-gapped: the offline default uses in-memory stores + seeded replay, self-hosts its fonts, and performs no external network egress. The live telemetry sources are structurally barred in airgap mode. For sovereign and defence customers this is the default posture — telemetry never leaves your infrastructure. See Deployment.

Export control

Spacecraft-related software and technical data may fall under India’s SCOMET controls (DGFT, Foreign Trade Policy) and related regimes. Air-gapped, in-country deployment is offered specifically so sensitive operational data need not cross a border. Regulatory specifics for a given deployment should be confirmed with counsel.

Regulatory alignment

VELA is designed to India’s DPDP Act 2023 (data-principal rights + a grievance mechanism; the Act phases in through May 2027, with the IT Act / SPDI Rules governing in the interim). As a body corporate it is subject to the CERT-In Directions of 28 April 2022 (IT Act s.70B(6)): reporting a covered cyber incident within 6 hours, and retaining ICT logs for a rolling 180 days within Indian jurisdiction — which an air-gapped deployment satisfies by construction.

Certifications are pursued in customer-driven order and never claimed before held roadmap: ISO/IEC 27001, SOC 2 Type II, and a VAPT by a CERT-In-empanelled auditor (empanelment is a credential for auditing firms, not a product — a vendor engages an empanelled auditor rather than “being empanelled”). These are the usual credentialing path into iDEX / Ministry of Defence procurement.

IN-SPACe. A read-only, non-commanding advisory ground-software vendor is not itself among IN-SPACe’s enumerated authorizable activities — that authorization sits with the operator customer. VELA processes telemetry, not remote-sensing imagery, so the high-resolution EO-dissemination trigger (GSD ≤ 30 cm) does not apply to it.