Visca

Legal · v0.1 draft

Security Policy

Visca's security posture begins with where your data lives: the stack is self-hosted inside your own perimeter. This page describes that posture, the architectural controls behind it, and how to report a vulnerability responsibly.

Last updated 2026-05-11Effective 2026-05-11

1. Our security posture

Security at Visca is a derivative of architecture, not a program bolted on. The first principle is containment: the stack — identity, credentials, runtime, and audit — runs inside your own perimeter — your tenancy, your region, your keys — so Customer Data stays within your walls and is not sent to a chain of outside AI vendors. The stack is built so that the safe default is the default: no autonomous actor exists without a cryptographic identity; no consequential access happens without a scoped, time-bound credential grant; no action is unaccounted for on the audit ledger. Most of what other organizations achieve by writing policy, we achieve by writing protocols.

2. Architectural security controls

  • Cryptographic identity per actor — every autonomous actor receives a non-transferable identity at instantiation, bound to its principal, runtime, and lineage. Hardware attestation is supported for embodied actors.
  • Capability-scoped, ephemeral credentials — autonomous actors never hold long-lived credentials. The credential layer vends scoped, time-bound, audited grants for each consequential action.
  • Mutual TLS by default — every connection across the stack is rooted in actor identities and authenticated cryptographically. No anonymous network calls.
  • Tamper-evident audit — every action recorded on the ledger is cryptographically chained. Modification of a past record invalidates the chain forward.
  • Policy enforcement at the data layer — RBAC and ABAC rules are compiled down to the database; authorization is structurally enforced, not merely checked.
  • Operations on the same ledger — maintenance is performed by operator agents acting as principals within scopes, so deployments, patches, rotations, and incident response are recorded with the same rigor as any other action.

3. Compliance roadmap

Status, v0.1: Visca Cloud has not yet completed any formal compliance certification. The platform is being architected against the frameworks below, with audits planned. We do not claim certifications we have not earned, and we will publish completion dates on this page as each audit closes.

Frameworks Visca Cloud is being designed against:

  • SOC 2 Type II — targeted
  • ISO 27001 — targeted
  • HIPAA (under a Business Associate Agreement) — targeted
  • GDPR and CCPA / CPRA alignment — targeted
  • FedRAMP — on roadmap

For the current architectural readiness summary, contact trust@visca.ai. As certifications complete, the corresponding reports will be available under NDA.

4. Data protection

  • Data stays in your perimeter. On self-hosted and air-gapped deployments, Customer Data, models, and audit records reside within the customer's own boundary; the stack carries no outbound dependency on Visca to run.
  • All Customer Data is encrypted in transit (TLS 1.3) and at rest (AES-256).
  • Signing keys for identity issuance can be backed by hardware security modules (HSM).
  • Open-weight models can run in-perimeter, so inference does not require sending Customer Data to an external model vendor.
  • Customers may select regional residency for hosted Visca Cloud tenants.
  • Air-gapped deployments are supported for environments with no external connectivity.

5. Responsible disclosure

We are grateful for the security community's help. If you believe you have found a vulnerability in Visca, please report it to security@visca.ai. Encrypt sensitive details with our PGP key (fingerprint forthcoming on this page once published).

What to include

  • A description of the issue and the affected product, version, or endpoint;
  • Steps to reproduce, including required configuration;
  • The impact you believe it has;
  • Any proof-of-concept code (please do not include actual credentials or PII).

What we ask

  • Do not access, modify, or destroy data that is not yours;
  • Do not perform denial-of-service tests against production systems;
  • Do not publicly disclose the issue until we have had a reasonable opportunity to respond and remediate (we target 90 days);
  • Act in good faith.

What you can expect

  • Acknowledgement within two business days;
  • Initial assessment within seven business days;
  • Communication on remediation timeline and status;
  • Recognition in our hall of fame (with your permission), once published.

A formal bug-bounty program is on our roadmap and will be announced here.

6. Subprocessors

Visca uses a curated set of subprocessors to operate the Services. The current list is available at /legal/subprocessors. Material changes to the subprocessor list are communicated to customers in advance with a meaningful objection period.

7. Incident response

Visca maintains a 24×7 on-call rotation for security incidents affecting the production Services. Customers will be notified of confirmed incidents that affect them promptly, with regular status updates through resolution. Postmortems are shared on request, with sensitive details redacted as appropriate.

8. Contact

Security reports: security@visca.ai.
Trust and compliance requests: trust@visca.ai.