Skip to main content
Rye evaluates policy at the network boundary before forwarding model requests upstream. The policy engine receives structured request context:
  • HTTP method.
  • URI, host, and path.
  • User agent.
  • Content type.
  • Model field when present.
  • Body length.
  • Parsed request body.

​
Decisions

Policy rules produce one of three decisions: Blocked responses include the request ID, decision, rule ID, rule version, reason, and match metadata when available.

​
Rule matching

Rules are checked in order. The first matching rule wins. Supported condition types include:

​
Local default policy

Rye starts with a local default policy so enforcement works before remote sync completes. The default policy:
  • Denies obvious SSH private-key exfiltration patterns.
  • Denies oversized payloads above 2 MB.
  • Allows common LLM and AI coding tool domains.
  • Requires approval for requests that do not match an allow rule.

​
Remote policy sync

When connected, the daemon syncs policy snapshots over gRPC. Remote policy snapshots are:
  • Validated before use.
  • Stored locally in SQLite.
  • Applied atomically.
  • Acknowledged to the control plane.
  • Reused from cache when the network is unavailable.
This makes policy a centrally managed and versioned artifact, not a local preference file inside one assistant.

​
Inspect policy effects

Use rye status and rye doctor to verify daemon and policy state:
Use history to inspect recent decisions and traffic:
Rye policy is external to the assistant. Prompt instructions such as “do not send secrets” can guide behavior, but Rye policy can block a request before it leaves the workstation.