Skip to main content
Rye combines local enforcement with a hosted control plane. The local daemon enforces policy and records evidence on the workstation. The control plane gives security and platform teams one place to review AI activity, manage identity, authorize devices, distribute policy, and audit usage across tools.

​
Runtime surfaces

Production Rye services use Rye-owned domains:

​
Activity ingestion

Rye agents and gateways submit activity data to the control plane. The backend supports:
  • REST activity batch ingestion.
  • gRPC history batch ingestion.
  • Supabase JWT authentication.
  • Postgres persistence.
  • Raw batch storage plus normalized activity items.
  • Compressed payloads such as gzip, brotli, and deflate.
  • JSON, text, binary, and empty data types.
The goal is to preserve enough source data for replay and investigation while also normalizing records for search, review, and policy audit.

​
What the console is for

Use the console to review:
  • Prompts, model responses, tool calls, and user workflows.
  • Policy decisions and blocked requests.
  • Device and CLI authorization state.
  • User and organization administration.
  • Audit trails for incident review, compliance workflows, and security operations.

​
Local to cloud flow

​
Device authorization

Rye ties activity to authenticated users and devices. rye auth login uses device-code auth so a terminal session can be linked to the right account. The daemon sends device presence over gRPC when connected, including the device ID, client ID, platform, app version, and active status. This gives teams a control point for deciding which workstations can send activity and receive policy.

​
Policy distribution

The control plane distributes policy snapshots to local daemons. The daemon validates and caches each snapshot before applying it. This keeps policy outside the assistant’s local settings files. The same rules can govern model traffic across different AI coding tools and developer devices.