Proxy policies

Policies are the rules the proxy uses to decide what each agent action is allowed to do. They are authored in the console (or via the Platform API), stored once in PostgreSQL, and read live by every proxy instance.

The policy model

A policy has four parts:

• Match conditions: which requests this policy applies to. Conditions can match on agent, action type, upstream, prompt content, headers, or any combination.
• Action: one of ALLOW, FLAG, DENY.
• Priority: an integer; lower priority evaluates first. The first matching policy wins.
• Scope: which tenant (and optionally, which set of agents) the policy applies to.

Actions

• ALLOW: the request is forwarded to the upstream. The trace is recorded as ALLOWED.
• FLAG: the request is forwarded but the trace is marked FLAGGED and surfaces in the dashboard for review.
• DENY: the request is rejected before forwarding. The agent receives a structured 403 error and the trace is recorded as DENIED.

Match conditions

Common conditions include:

• Agent ID: restrict the policy to specific agents.
• Action type: chat_completion, embedding, tool_call, mcp_request, http_request.
• Upstream URL: match calls to a specific provider or domain.
• Prompt content: substring or regex match against the user message body.
• Header value: match on X-RenLayer-User, X-RenLayer-Session, or any forwarded header.
• Tool name: for tool calls, match by the tool the agent is invoking.

Conditions combine with AND. To express OR, write multiple policies with the same action.

Priority and ordering

When multiple policies match, the one with the lowest priority number wins. A common pattern:

1. Priority 10: a DENY rule for known-dangerous patterns (e.g. credential exfiltration).
2. Priority 50: FLAG rules for sensitive but ambiguous patterns.
3. Priority 1000: a default ALLOW rule that catches everything else.

If no policy matches, the proxy applies the tenant default (usually ALLOW).

Authoring and rollout

Policies are authored in the Policies page of the console. When you save a policy, it is written to PostgreSQL and picked up by every proxy instance on its next request, there is no cache to bust and no restart required.

You can disable a policy without deleting it; disabled policies remain in history for audit.

Versioning

Every policy edit creates a version row. The audit log records who changed what and when. Rolling back is a one-click action that creates a new version pointing at an older definition.

Testing

The console includes a policy test form: paste a sample request body and see which policies match and what the resulting action would be. This is the recommended way to validate a policy before enabling it for production agents.

Where to go next

• DLP: content-based blocking that runs alongside policies.
• Rate limits: quota-based protections.
• Console: policies: authoring policies in the UI.
• Action statuses: what each policy outcome looks like in traces.