Security and data boundaries

“Runs near your data” does not mean that no bytes can ever leave the boundary. RLM separates data access and code execution from model subcalls so you can control what each layer receives.

Local CLI

In the default mrl rlm mode:

• Python executes on your machine.
• Attached file paths are opened on your machine.
• SQLite credentials and database access remain local.
• The root-model request and any llm_query or llm_batch prompts go through ModelRelay to the selected model provider.
• Generated code decides which values are included in those model prompts.

Do not expose highly sensitive columns merely because the database connection is local. Generated Python runs with the current user’s local file access, so a SQL profile is a behavioral guardrail rather than a sandbox boundary. Use a restricted database copy or operating-system boundary when the model must not read particular tables, and inspect trajectories during development.

Hosted RLM

With /rlm/execute, the RLM sandbox runs in ModelRelay-managed infrastructure. Inline context, uploaded context, and values returned by a wrapper_v1 service become available to that runtime.

Hosted RLM does not accept direct database credentials. wrapper_v1 keeps credentials in your service and uses a request-scoped bearer token, but data returned by its /search, /get, and /content endpoints is delivered to the hosted runtime.

Use request and response limits to reduce exposure:

{
  "limits": {
    "timeout_ms": 15000,
    "max_requests": 20,
    "max_response_bytes": 1048576
  }
}

Private deployment

For data that cannot enter a shared hosted runtime, place the RLM runtime and data adapter inside your VPC or infrastructure. Model provider calls may still receive selected prompt content unless you also use an in-boundary model endpoint.

Document the complete route for each deployment:

data source → RLM sandbox → root/subcall prompt → ModelRelay routing → model provider

SQL controls

Local SQLite is opened read-only, which prevents mutation but not unauthorized reading by generated Python running as the current user. Production deployments should enforce policy outside the model:

• Use a database user without write privileges.
• Allowlist schemas, tables, and columns.
• Cap returned rows and response bytes.
• Block multiple statements and mutation operations.
• Exclude or redact sensitive columns before they reach the sandbox.
• Record the executed SQL and resulting trajectory for audit.

Model instructions are not a security boundary. Enforce data access in the adapter, SQL policy, database role, and network configuration.

Wrapper controls

For wrapper_v1:

• Issue short-lived, least-privilege bearer tokens.
• Authorize every resource ID instead of trusting the model-generated request.
• Enforce pagination and response-size caps server-side.
• Return only fields needed for analysis.
• Keep OAuth refresh tokens and database credentials out of the request body.
• Treat query, filter, ID, and format arguments as untrusted input.

See the full wrapper security requirements.