Security Overview

Relynt is designed with security as a foundational requirement. This page covers the key security mechanisms that protect your organization’s data and agent operations.

Architecture

Relynt’s security operates at multiple layers:

Agent Request
  → TLS encryption (in transit)
  → Credential verification (hashed comparison)
  → Organization scoping (RLS + middleware)
  → Policy evaluation (deterministic engine)
  → Receipt signing (HMAC-SHA256)

Row-Level Security (RLS)

All database tables enforce Supabase Row-Level Security. Every query is automatically scoped to the authenticated user’s organization:

• Agents, policies, receipts, and approvals are only visible to members of their organization
• RLS policies cannot be bypassed from the client
• Backend API endpoints add an additional layer of organization membership verification

Credential security

Agent credentials

• Credentials are stored as bcrypt hashes — the plaintext is never stored
• The plaintext secret is shown exactly once at rotation time
• Each rotation immediately revokes the previous credential
• Credentials are verified by comparing the bcrypt hash on every gateway request

User authentication

• User sessions are managed by Supabase Auth
• Session tokens are short-lived and automatically refreshed
• Passwords are hashed using bcrypt with salt

HMAC-SHA256 receipt signing

Every receipt is signed with HMAC-SHA256 to ensure tamper detection:

1. A canonical representation of the receipt fields is computed
2. The representation is signed using a server-side signing key
3. The signature is stored as part of the receipt
4. Verification recomputes the signature and compares it to the stored value

What is signed

The HMAC signature covers these receipt fields:

• receipt_id
• organization_id
• agent_id and instance_id
• action and resource
• decision and risk_level
• policy_version
• request_hash
• created_at

Signing key management

• The signing key is stored server-side and is never exposed to clients
• Verification is performed server-side via the GET /v1/receipts/:id/verify endpoint
• Clients cannot compute or validate signatures directly

Request and response hashing

Request hash

Every request body is serialized to canonical JSON and hashed with SHA-256:

{
  "request_hash": "sha256:a1b2c3d4..."
}

This allows verification that the request recorded in the receipt matches the original request.

Response hash

When a connector executes, the response body is hashed with SHA-256:

{
  "response_hash": "sha256:e5f6g7h8..."
}

This records what the target system returned without storing the full response.

Data protection

What is never stored

• Plaintext agent credentials
• Connector API keys and tokens (stored encrypted)
• Authorization headers from agent requests
• Raw connector responses (only the hash)

What is never exposed

• Agent secrets (shown once at rotation, never again)
• Signing keys
• Connector credentials
• Other tenants’ data

Role-based access