Security Overview

Rivano’s security model is built on a single principle: every AI request passes through a controlled pipeline before reaching an LLM provider. Security controls live at the infrastructure layer, not in application code. Your teams write features; Rivano enforces the guardrails.

Defense-in-depth pipeline

Every proxied request travels through a 13-stage pipeline in the Rivano data plane:

Inbound request
      │
      ▼
1.  Authentication & tenant resolution
2.  Rate limiting (60 req/min per tenant)
3.  Agent context lookup
4.  Request policy evaluation
      ├── Injection score check
      ├── PII detection (request)
      ├── Token count check
      └── Content pattern match
5.  Provider key decryption
6.  Provider request forwarding
7.  Provider response received
8.  Response policy evaluation
      ├── PII detection (response)
      └── Content pattern match
9.  PII redaction (if policy action = redact)
10. Quality scoring
11. Cost calculation
12. Trace recording
13. Response returned to caller

Each stage can independently block, modify, or pass the request. A block at stage 4 prevents the request from ever reaching the LLM provider — no tokens are consumed and no data leaves your network.

What Rivano secures

Prompt injection — Rivano scores every inbound message for injection patterns using a 0.0–1.0 risk score. Requests above the configured threshold (default: 0.7) are blocked with a 403 before reaching the provider.

PII in transit — Six entity types (SSN, email, phone, credit card, name, address) are detected in both request and response bodies. Detected values are redacted, replaced, or cause the request to block, depending on your policy configuration.

Provider key protection — Provider API keys are never stored in plaintext. They are encrypted with AES-256 using a tenant-specific key derived via HKDF. Decryption happens in memory, inside the data plane, only at request time.

Access control — Tenant isolation is enforced at the Postgres RLS layer. A bug in application code cannot expose cross-tenant data because the database enforces the boundary independently.

Audit trail — Every control-plane mutation and every proxied request is logged. Logs are immutable and retained per your plan’s retention policy.

Compliance posture

Rivano’s built-in controls are designed to support the following frameworks:

FrameworkRelevant controls
SOC 2 Type IIAccess control, audit logging, encryption at rest and in transit, change management
GDPRPII detection and redaction, data retention limits, right-to-erasure support via trace deletion
ISO 27001Policy management, risk assessment via posture score, incident logging
HIPAAPII detection (PHI patterns), audit logging, encryption
💡

The Compliance page in the dashboard generates framework-specific reports from your actual trace and policy data. You don’t fill out a questionnaire — Rivano derives the report from evidence.

Security boundaries

Rivano does not provide:

  • Endpoint security for the machines running your agents
  • Network-level isolation (that is your infrastructure’s responsibility)
  • Malware scanning of file attachments
  • Human review of AI outputs

Rivano is an observability and governance layer. It works best when combined with your existing security controls — network policies, secret management, and code review.

Reporting vulnerabilities

If you discover a security issue in Rivano, report it to [email protected]. Do not open a public GitHub issue. We respond within 24 hours and aim to patch critical issues within 72 hours.

Previous ← RBAC Next PII Detection →