Security & Privacy
Rilo is designed for organizations that handle sensitive operational data. Every layer of the system enforces strict tenant isolation, encryption, and access control.
This page is for security engineers and technical evaluators. For a business-focused overview of Rilo’s security posture, see Security on riloworks.com.
Organization Isolation
All data processing is partitioned by organization. Each org is assigned a high-entropy unique ID, independent of your auth provider. This decoupling means org isolation is enforced at the data layer, not just the auth layer.
Fail-closed enforcement: If an organization mapping lookup fails at any layer (ingestion, execution, memory), the request is rejected with an HTTP 500 — it never falls through to another org’s context.
| Boundary | Enforcement |
|---|
| Task ingestion | Org resolved from authenticated source; unknown sources rejected |
| Browser sessions | Isolated per org; never reused across organizations |
| Memory and vectors | Partitioned by org namespace in vector store |
| Credentials | Encrypted per org; resolved only within org context |
| Audit logs | Tagged with org ID for isolated retrieval |
Encryption
- In transit: All communication uses TLS. Webhook payloads are signed with HMAC-SHA256 for integrity verification.
- At rest: Credentials and sensitive data are encrypted using per-org encryption keys managed through AWS Secrets Manager. Raw payloads are stored in encrypted storage only.
Credential Handling
Rilo uses invite flows and secure credential submission — it never requests OAuth redirects during task execution.
Credential acquisition methods:
| Method | Description |
|---|
| Pre-provisioning | Customer creates an account for Rilo and shares credentials via the secure portal |
| Invite flow | Customer sends an invite to Rilo’s dedicated email address |
| Self-registration | For tools that support workspace invites (GitHub, Slack) |
Credentials are submitted through an encrypted portal with time-limited state tokens. Rilo’s team never sees plaintext credential values.
Browser Session Isolation
Every browser session runs in a sandboxed environment:
- Sessions are provisioned per-task and never reused across organizations
- A circuit breaker monitors session health — 3 failures in 60 seconds triggers a cooldown period
- All sessions are recorded for audit purposes
- Session recordings are archived to encrypted storage
Audit Logging
All operations are logged with structured telemetry:
- Task lifecycle events (created, planned, executing, completed, failed)
- Tool invocations with strategy metadata and timing
- Credential access events (which tool, which org, success/failure)
- Memory queries and updates
Audit logs are partitioned by organization and available for export.
Compliance Status
Rilo is actively working toward industry compliance certifications. Current status:
| Standard | Status | Detail |
|---|
| SOC 2 Type II | In progress | Audit preparation underway |
| GDPR | Architecture ready | GDPR-ready data handling and deletion capabilities |
| HIPAA | Eligible | Available as a deployment option on Enterprise plan |
Compliance certifications listed above reflect current status as of the last update. “In progress” means audit preparation is underway but certification has not been granted. “Architecture ready” means the system supports the requirements but has not been formally certified. “Eligible” means the deployment option is available but requires customer-specific configuration.
Secret Redaction
Rilo automatically redacts sensitive values from logs, telemetry, and error messages. Credential values, API keys, and tokens are never written to application logs or observability systems in plaintext.
Need our SOC 2 Type II report (in progress), security questionnaire, or architecture docs? Email security@riloworks.com and we’ll send them within one business day.