Security & Trust
This page covers Rivaro's security architecture, data handling, compliance posture, and deployment options. It is written for engineering and security leaders evaluating Rivaro for production AI workloads.
Data Handling
What Rivaro processes
| Data | Retention | Customer configurable |
|---|---|---|
| Request/response content — raw prompts and completions passing through the gateway | Archived async to cold storage (S3, GCS, Azure Blob, or local). 30 days default. | Retention period configurable per organization. |
| System prompts — deduplicated, fingerprinted, usage-tracked for prompt intelligence | Retained with sessions (90 days default). | Retention period configurable per organization. |
| Detection metadata — detection type, severity, confidence, location | 7 years default (SOC 2). | Retention period configurable per organization. |
| Policy decisions — action taken, rule matched, context | 7 years default. | Retention period configurable per organization. |
| Enforcement receipts — Ed25519-signed ActionRecord ledger entries | 7 years default. | Retention period configurable per organization. |
| Action records — audit ledger of all governed actions | 1 year default. | Retention period configurable per organization. |
| Sessions and telemetry — session context, token counts, cost estimates | 90 days default. | Retention period configurable per organization. |
| Agent identity records — agent metadata, trust scores, governance status | Retained while agent is registered. | Purge on agent removal. |
Raw content is archived to cold storage before retention-based deletion. All retention periods are configurable per organization via the retention policy API. GDPR deletion removes all associated records regardless of retention schedule.
Customer data controls
- Data export: Full export via API (JSON, CSV) or SIEM integration (CEF, JSON) for any retention window.
- Data deletion: GDPR deletion endpoints at
/api/v1/gdpr/deletion-requestsremove all associated records including ActionRecord ledger entries. - Data residency: Configurable per deployment model (see Infrastructure and BYOC / Self-Hosted).
AI and Model Usage
| Question | Answer |
|---|---|
| Does Rivaro use AI models internally? | Yes — for detection classification (LLM-as-judge), behavioral analysis, intent drift measurement, and semantic similarity scoring. |
| Where do these models run? | Self-hosted: In the customer's VPC, using whatever LLM provider the customer configures (Bedrock, OpenAI, Anthropic, Azure, or a self-hosted model like Ollama). Cloud-hosted: In Rivaro's infrastructure, using AWS Bedrock by default. The internal LLM provider is configurable per organization. |
| Is customer data used to train or fine-tune any model? | No. Customer data is never used for training, fine-tuning, or model improvement — under any deployment model. |
| Does Rivaro send content to LLM providers for its own detection? | Yes — when LLM-as-judge detection strategies are enabled, Rivaro sends content snippets to the configured internal LLM provider for classification. Pattern-based detectors run locally and do not call any external service. The internal LLM provider is configurable per organization — customers can point it at a self-hosted model to keep all data within their boundary. |
| Is customer data sent to the customer's own LLM providers? | Only when the customer explicitly configures LLM provider routing through the Rivaro Gateway. In that case, traffic flows to the provider the customer selected; Rivaro scans it in transit but does not copy it to any other destination. |
| Can Rivaro operate without calling external AI services? | Yes, if configured with a self-hosted LLM provider (e.g. Ollama) for internal detection. Pattern-based detectors always run locally. LLM-as-judge detectors can be disabled or pointed at a local model. |
Encryption
| Layer | Standard | Details |
|---|---|---|
| In transit | TLS 1.3 | All API traffic, gateway traffic, and internal service communication. TLS 1.2 accepted for backward compatibility; 1.0/1.1 rejected. |
| At rest | AES-256 | Database storage (RDS encryption), object storage, and backup volumes. |
| Key management | Pluggable | Self-hosted: any KMS the customer chooses (HashiCorp Vault, AWS KMS, Azure Key Vault, GCP KMS, on-premises HSM). Cloud-hosted SaaS: AWS KMS. Encryption keys are never stored alongside encrypted data. Key rotation supported on customer-defined schedule. |
| Receipt signing | Ed25519 | Per-organization signing keypair for AARM ActionRecord receipts. Private key stored in the customer's chosen secrets backend. |
Infrastructure
Rivaro is available in two deployment models. Both run the same product with the same configuration formats -- you can move between them without code changes.
Rivaro Cloud (recommended for evaluation and most production workloads)
| Property | Detail |
|---|---|
| Cloud provider | AWS |
| Available regions | US East (us-east-1). Additional regions on request. |
| VPC isolation | Dedicated VPC per deployment. No shared-tenancy compute. |
| Tenant separation | Logical isolation at the application layer (organization-scoped data access, row-level security). Dedicated compute available for enterprise plans. |
| Network controls | All origins locked to Cloudflare edge IPs. Direct instance access blocked. Security groups scoped to minimum required ports. |
| Secrets management | AWS Secrets Manager for detection keys, signing keys, and integration credentials. |
Self-Hosted (recommended for regulated industries and data sovereignty requirements)
| Property | Detail |
|---|---|
| Distribution | Container images on GitHub Container Registry, with Docker Compose and Helm chart for deployment. |
| Cloud provider | None required. Runs on AWS, Azure, GCP, on-premises, air-gapped environments, or a laptop. |
| Data plane | Runs entirely in the customer's environment. No data leaves the customer's network boundary. |
| Secrets management | Pluggable. Works with any secrets backend (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager, Kubernetes secrets, environment files). |
| Updates | Versioned container releases. Customer controls upgrade timing. |
See BYOC / Self-Hosted below for the full self-hosted deployment model.
AARM Alignment
Rivaro is designed around the Autonomous Action Runtime Management (AARM) specification — a Cloud Security Alliance standard for governing autonomous AI agent actions with cryptographic proof — and is listed in the AARM Builder Registry.
What AARM alignment means
Every governed action produces an ActionRecord — not a log entry, but a cryptographically signed receipt:
| Property | Implementation |
|---|---|
| Signing algorithm | Ed25519 (per-organization keypair) |
| Integrity chain | SHA-256 content hash linking each receipt to its predecessor, forming a tamper-evident hash chain |
| Canonical payload | Deterministic serialization of action, context snapshot, policy decision, identity binding, and resolution metadata |
| Offline verification | Any party can verify a receipt's signature and hash chain without contacting Rivaro — browser-verifiable via @noble/ed25519 |
If any field in a signed receipt is modified after the fact, the content hash breaks and signature verification fails. This is provable by any third party with the organization's public key.
AARM conformance testing
Rivaro maintains a conformance harness exercising the AARM v1 requirement areas (R1–R9). Each test issues a real governed action against the live pipeline, produces a signed receipt, and verifies it.
Formal Core / Extended conformance status is pending completion of the AARM review process; until that review is complete, Rivaro claims alignment, not conformance.
| Requirement | What it proves |
|---|---|
| R1 — Pre-execution interception | Actions are intercepted before execution; denied actions never reach downstream systems |
| R2 — Context accumulation | Session context (prior actions, data classifications, original intent) is tracked and hash-chained |
| R3 — Policy evaluation with intent alignment | Policies evaluate against accumulated context; intent drift triggers escalation |
| R4 — Authorization decisions | All five decision types (ALLOW, DENY, MODIFY, STEP_UP, DEFER) produce correct receipts including follow-up receipts on resolution/timeout |
| R5 — Tamper-evident receipts | Signed receipts break on tampering; offline verification succeeds for untampered records |
| R6 — Identity binding | Human, service, agent, session, role scope, and identity assurance level bound to every receipt |
| R7 — Semantic distance tracking | Intent drift detected via embedding similarity; configurable thresholds trigger escalation |
| R8 — Telemetry export | Structured SIEM/SOAR export in CEF and JSON formats |
| R9 — Least privilege enforcement | JIT scoped credentials issued on ALLOW; revoked on expiry or actor status change |
Regulatory Crosswalk
How Rivaro's capabilities map to specific regulatory requirements:
| Regulation | Scope | Relevant Rivaro capabilities |
|---|---|---|
| FFIEC / OCC SR 11-7 (Financial services — model risk management) | Model validation, ongoing monitoring, outcome analysis | Detection coverage across all LLM interactions; ActionRecord audit trail; policy enforcement with signed receipts; trust score tracking; compliance reporting with SOC 2 / FFIEC mapping |
| HIPAA (Healthcare — protected health information) | PHI safeguards, access controls, audit trails | PII/PHI detection and redaction in transit; per-actor access logging; GDPR-grade deletion; encryption at rest and in transit; exportable audit evidence |
| SOX (Public companies — financial controls) | IT general controls, change management, access controls | Immutable ActionRecord ledger with cryptographic integrity; role-based access with identity assurance levels; tamper-evident receipts for control evidence |
| EU AI Act (EU — AI system risk management) | High-risk AI system requirements: risk management, transparency, human oversight, accuracy | Pre-execution interception (Art. 14 human oversight); intent drift detection; STEP_UP human-in-the-loop approval; AARM-aligned signed receipts as technical documentation; agent identity via W3C DIDs with trust attestation VCs |
| Colorado AI Act (Effective June 30, 2026 — algorithmic discrimination prevention) | Impact assessments, risk management for high-risk AI, disclosure requirements | Detection taxonomy covering bias and fairness signals; governance decision history; compliance reporting with framework-specific evidence packages; ActionRecord ledger as impact assessment evidence |
SOC 2 and Compliance Status
| Certification | Status | Target |
|---|---|---|
| SOC 2 Type I | In progress | Q3 2026 |
| SOC 2 Type II | Planned | Following Type I completion |
| ISO 42001 | On roadmap | 2027 |
Rivaro already generates ISO 42001 evidence packages (clause-by-clause mapping) from production governance data — see Compliance Reporting. Formal certification will follow SOC 2.
Penetration Testing
| Property | Detail |
|---|---|
| Cadence | Third-party penetration testing planned alongside SOC 2 Type I (Q3 2026), with annual cadence thereafter |
| Scope | External attack surface (API, gateway endpoints, authentication flows), internal service boundaries, and cryptographic receipt verification pipeline |
| Methodology | OWASP Testing Guide, PTES |
| Test results | Will be available under NDA once the first formal engagement completes — contact [email protected] |
| Internal review | Continuous internal security review, automated container scanning (see .github/workflows/container-scan.yml), and secret scanning on every PR |
BYOC / Self-Hosted
For organizations in regulated industries — financial services, healthcare, government, defense — that cannot route production AI traffic through a third-party governance layer, Rivaro supports full deployment in the customer's own infrastructure.
Deployment model
| Property | Detail |
|---|---|
| Data plane | Runs entirely in the customer's VPC. No AI traffic, prompts, completions, or detection results leave the customer's network boundary. |
| Control plane | Customer-managed. Rivaro provides the software; the customer operates it. |
| Updates | Rivaro delivers versioned releases (container images, Helm charts). Customer controls upgrade timing and rollout. |
| Secrets and keys | Ed25519 signing keys, detection keys, and integration credentials are generated and stored in the customer's secrets management system. Rivaro never holds or accesses customer keys. |
| Monitoring | Customer integrates with their own observability stack. Rivaro provides Prometheus metrics endpoints and structured log output. |
| Network isolation | No callbacks to Rivaro infrastructure required. Fully air-gappable for classified environments. |
What Rivaro provides vs. what the customer owns
| Rivaro provides | Customer owns |
|---|---|
| Application software (container images) | Compute, storage, networking |
| Helm charts and deployment guides | Kubernetes / orchestration platform |
| Configuration templates | Policy configuration and tuning |
| Release notes and upgrade paths | Upgrade scheduling and execution |
| Support and incident response | Infrastructure operations and monitoring |
Sub-Processors
Rivaro Cloud uses a small set of sub-processors to operate the service. This list is the source of truth and is updated when sub-processors change.
| Sub-processor | Purpose | Customer data processed | Location |
|---|---|---|---|
| Amazon Web Services (AWS) | Compute (EC2), database (RDS), object storage, secrets management (AWS Secrets Manager), key management (KMS), container registry (ECR) | All customer data persisted by Rivaro Cloud is stored in AWS infrastructure under Rivaro's account | US East (us-east-1) by default; additional regions on request |
| Cloudflare | Edge proxy, DDoS protection, DNS | Inbound request metadata (IP, User-Agent, TLS metadata). Request bodies are forwarded to Rivaro origin servers; Cloudflare does not store request content. | Global edge |
| WorkOS | Authentication and SSO (SAML, OIDC, directory sync, SCIM) | User identity (email, name, directory attributes), authentication events | US |
Self-hosted deployments
Self-hosted Rivaro has no Rivaro-controlled sub-processors. The customer chooses every component: cloud provider, secrets backend, identity provider, observability stack. Rivaro provides software and updates only; no customer data leaves the customer's infrastructure.
Customer-configured AI providers are not Rivaro sub-processors
When a customer routes traffic through Rivaro to an LLM provider (OpenAI, Anthropic, AWS Bedrock, Google Vertex, Azure OpenAI, etc.), that provider processes the customer's prompts and completions under the customer's contract with the provider -- not Rivaro's. Rivaro scans traffic in transit and does not copy customer data to any AI provider beyond what the customer's own integration already does.
Notification of changes
Customers under Rivaro Cloud DPAs are notified of material changes to the sub-processor list with 30 days' notice and have the right to object per the DPA terms.
Responsible Disclosure
If you discover a security vulnerability in Rivaro, report it to:
| Property | Commitment |
|---|---|
| Acknowledgment | Within 2 business days |
| Initial assessment | Within 5 business days |
| Resolution target | Severity-based, communicated in initial assessment |
| Safe harbor | Good-faith security research conducted under responsible disclosure will not result in legal action |
| Recognition | Researchers credited in release notes (with permission) |
Do not disclose vulnerabilities publicly before coordinating with the Rivaro security team.