Security

Overview

Onagre applies multiple layers of protection to ensure your secrets remain safe at every stage — at rest, in transit, and at the application level. This page details the encryption model and access controls that protect your sensitive data.

Encryption at rest

All secret values are encrypted using AES-GCM with 256-bit keys, an authenticated encryption standard that guarantees both confidentiality and integrity. Each value is encrypted with a unique random nonce, making every ciphertext distinct — even for identical inputs.

Two-tier key architecture

Onagre uses a two-tier encryption model to isolate organizations from each other:

• A platform master key secures the infrastructure. It is configured at deployment time and never stored alongside your data.
• A tenant-specific key, unique to your organization, encrypts your secrets. This tenant key is itself encrypted by the master key and is never stored in plain text.

This design ensures that even in the unlikely event of a data breach, secret values remain unreadable without access to both key layers. Compromising one organization's data does not expose another's.

What is encrypted

Encryption in transit

All communications between agents and the Onagre platform use TLS encryption. The gRPC connection between each agent and the Hub is encrypted end-to-end, protecting secret values as they are transmitted for sensor execution.

Secrets are decrypted on the Hub (server-side) and transmitted to the agent within the encrypted gRPC channel. Agents never store secrets on disk — values are held in memory only for the duration of the sensor check.

Application-level controls

Access restrictions

• Only Administrators and Managers can create, update, or delete secrets and variables.
• Users with the Viewer role can see that secrets exist (code, type, version) but cannot read or modify their values.

Write-only secrets

Secret values are never returned by the API or displayed in the interface after creation. The platform stores only the encrypted form — no plaintext copy is retained.

Tenant isolation

All data is tenant-isolated by design. Cross-organization access is forbidden at every layer — API, database queries, and agent communication. An agent belonging to one organization cannot receive secrets from another.

Caching

• Tenant keys are cached in memory for a limited time to avoid repeated master-key decryption.
• Decrypted secret values are cached briefly (minutes) to avoid repeated decryption during frequent sensor execution cycles.
• Caches are invalidated when a secret is updated or deleted.

Summary