Arivaran / Security and trust
Security that is enforced in code
This page lists the security properties the platform ships today, names the mechanism that enforces each one, and states exactly where our compliance posture stands. No certification claims, no vague absolutes.
Backup immutability
ConfiguredEnforced in code, per backendWhere a retention deadline is set, the storage layer itself refuses the delete.
A block written with a retention deadline to an S3 block store with Object Lock is held in compliance mode: inside the window the object store rejects deletes and overwrites no matter who asks, including the storage administrator account. Compliance mode is the only mode the product emits. A block written without a deadline takes the ordinary write path, and a backend that cannot honour a deadline refuses the write rather than storing the block mutable.
Mechanism: The S3 residency preflight verifyManagedS3WormResidency in aaStorSvc runs when a deployment requires Object Lock, sets a retention floor, or pins a bucket region, and it fails startup rather than degrading. A separate startup gate, StorageAssurance, refuses to start whenever a declared assurance requirement exceeds what the selected backend can actually deliver.
- Retention window
- Set per deployment, not a product default. Arivaran-operated nodes run an S3 compatible object store we host ourselves, on an Object Lock capable bucket with no default retention configured, so no block is held immutable today. While the service is in its pre-customer test phase every tenant is treated as a test tenant, which caps the effective hold at 10 minutes wherever a hold is resolved.
- Scope and exceptions
- Object Lock compliance mode applies to deployments whose block store is S3 with Object Lock. Arivaran-operated nodes do not run that compliance configuration today. They run an S3 compatible object store we host ourselves; its bucket is Object Lock capable, but the capability is not armed, because no default retention is set and no per object retention is requested, so no block carries a compliance hold. The filesystem, reflink and XFS VDO backends have no immutability control of their own and fail closed on a retained block rather than storing it mutable. Self hosted deployments choose their own backend and their own retention floor.
Credential scope
ConfiguredEnforced in codeA compromised endpoint cannot destroy its own history.
The agent credential is scoped to write operations only. It can add new backup data and nothing else, so malware that fully owns an endpoint still cannot reach back into the platform and erase that endpoint's restore points.
Mechanism: Agent tokens carry the write-only kuiperdesk.agent scope. Deletion and retention changes require the separate admin and security-officer credential tiers, which never live on an endpoint.
Outside the agent credential's scope
DeleteHashesDedup metadata cannot be marked for deletion by an agent.
DeleteSnapshotRestore points cannot be removed from the catalog by an agent.
S3 DELETEThe agent's storage credential cannot issue object deletes at all.
Edge connectivity
Observed operatingShipping in productionSatellite sites open zero inbound ports.
A satellite deployment dials out to the gateway on port 443 and keeps that single outbound connection alive. Browser sessions reach services at the site back through it. No inbound ports, no port forwarding, no VPN appliance at the customer site.
Satellite dials out
The edge agent opens one outbound connection to the gateway over port 443, with automatic reconnect.
Gateway bridges
The hub gateway maps each incoming browser request to the right satellite over that existing stream.
Site services respond
Responses travel back over the same outbound connection. The site's firewall never accepts a new inbound flow.
Scope: This describes satellite and edge sites. Endpoint agents talk to the backend directly over outbound HTTPS on port 443 by default; the relay is not in that default data path.
Mechanism: Satellite gateway (aaSatGwSvc): one outbound gRPC stream carries multiplexed request and response frames in both directions.
Enrollment identity
ConfiguredEnforced in codeHardware attestation where the hardware exists, honest labels where it does not.
Enrollment is tiered by what the server actually verified, not by what the device claims about itself.
Hardware tier
Requires a TPM 2.0 resident key whose endorsement certificate chains to a manufacturer root pinned in the deployment's trust store. This is the tier designed for high-assurance tenancies.
Software-key fallback
Still enrolls a device, but only with a short-lived, single-use, rate-limited enrollment key, and it is not valid for high-assurance tenancies.
A key merely resident in a TPM is not attested identity. Where the key lives (custody) and what the server proved about its hardware root (attestation) are recorded as separate facts, and compliance posture derives only from the proven side.
Mechanism: The enrollment service ships an endorsement-key chain validator: when a deployment provisions the pinned manufacturer trust store, TPM endorsement-key certificate chains are verified against it, and key custody is always recorded separately from proven attestation depth.
Certificate authority chain
ConfiguredRoot ceremony completedA six-level chain from the offline root to an agent certificate.
The root key was generated in AWS CloudHSM, FIPS 140-2 Level 3 hardware, and is kept offline. The chain is designed so day-to-day issuance happens at online intermediate tiers and a compromised online tier can be revoked and re-issued without touching the root. Today the company intermediate is the tier issuing day to day; the product tiers below it are built but not yet issuing in production.
Mechanism: Root created in a recorded CloudHSM key ceremony, then taken offline. The hardware-module rating describes the AWS root environment, not a certification of Arivaran's product.
- 1
Root CA
Generated in AWS CloudHSM, kept offline
- 2
Company CA
Online intermediate in OpenBao
- 3
Geo CA
One per operating region
- 4
MSP satellite CA
Scoped issuance for managed service providers
- 5
Client satellite CA
Scoped issuance per customer site
- 6
Agent leaf certificate
Short-lived endpoint identity
Compliance posture
Where we stand, stated plainly.
Our controls are designed against the AICPA Trust Services Criteria, and the federal deployment path is engineered toward FIPS 199 High-impact use and FedRAMP Rev5 Class D assurance.
Arivaran does not currently hold a SOC 2 report, a FedRAMP authorization, or an ISO certification. When an independent report exists, this page will name its exact scope and period. Until then, every claim on this page stays in the first two states below.
How to read the labels on this page
The control exists in the shipped product and is turned on in the stated deployment.
We run the control in production and watch it work. The evidence is ours, not a third party's.
A qualified third party has examined the control. Nothing on this page carries this state today.
A formal certification or government authorization names the exact scope. Arivaran holds none today.
Policies
The policy corpus behind these controls.
Every control on this page is governed by a published policy. The full corpus is public; these are the documents most relevant to security review.
Responsible disclosure
Found a weakness? Tell us first.
Report vulnerabilities to security@arivaran.ai. We practice coordinated disclosure: report privately, give us a reasonable window to fix, and we will credit you if you want credit. Our security.txt (RFC 9116) is served on blog.arivaran.ai.
For policy or audit questions, write to compliance@arivaran.ai.