Docs

Proxy

How the proxy works

End-to-end request flow through the RenLayer proxy: authentication, policy evaluation, DLP scanning, upstream forwarding, and trace persistence.

The proxy turns each agent request into a structured, governed event. This page walks the flow from the moment the request lands to the moment the trace is written.

Request lifecycle

  1. Ingress. The agent calls the proxy URL with its RenLayer API key in the Authorization: Bearer … header.
  2. Authentication. The proxy validates the API key, resolves the agent, and identifies the tenant. Invalid keys return 401 immediately.
  3. Classification. The proxy reads the path and body to determine the action type, chat completion, embedding, tool call, MCP request, or arbitrary HTTP.
  4. Policy evaluation. Policies for the tenant are evaluated in priority order. The first matching rule decides the action: ALLOW, FLAG, or DENY.
  5. DLP scan (request). Built-in and custom detectors scan the prompt for sensitive data. Findings are attached to the trace and may trigger a DLP_BLOCKED or DLP_WARNED outcome.
  6. Upstream forward. Allowed requests are proxied to the configured upstream (OpenAI, Anthropic, internal MCP server, or arbitrary URL). The proxy preserves streaming semantics for SSE responses.
  7. DLP scan (response). The response body is scanned the same way as the request. A blocked response can be replaced with a structured error.
  8. Trace persistence. A row is written with: tenant ID, agent ID, action type, status, latency, token usage, redacted request/response bodies, DLP findings, and policy IDs that fired.

Headers

The proxy reads and emits a small set of X-RenLayer-* headers so agents can attribute calls to logical users or sessions:

  • X-RenLayer-User: opaque end-user identifier (used by per-user rate limits and the audit log).
  • X-RenLayer-Session: groups multiple calls into a session in the console.
  • X-RenLayer-Trace-Id: populated on the response so agent-side logs can join to RenLayer traces.

These headers are optional. When absent, the proxy still records the call against the agent.

Action statuses

Every trace ends with one of these statuses:

  • ALLOWED: request matched a permissive policy (or no policy) and was forwarded.
  • FLAGGED: request was forwarded but flagged for review.
  • DENIED: policy rejected the request before forwarding.
  • DLP_BLOCKED: DLP detector matched a critical pattern; request blocked.
  • DLP_WARNED: DLP matched a non-critical pattern; request forwarded but recorded.

See action statuses for the full state machine.

Streaming

The proxy supports streaming responses (Server-Sent Events). It buffers minimally so it can apply response-side DLP without breaking the streaming contract for the client. For very long-running streams, the trace is written when the stream closes.

Failure modes

  • Upstream timeout: the proxy returns the upstream’s error verbatim and writes a trace with the error captured.
  • Database unreachable: by default the proxy fails open (request proceeds, trace dropped) to preserve agent availability. This is configurable per tenant.
  • Policy evaluation error: fails closed (request denied) so misconfigured policies never silently allow traffic.

Where to go next

Last updated: