Architecture and trust boundaries

ActionRail separates configuration and operations from the execution path. The Console manages agents, rules, Source metadata, activity, and reviews. Enforcement happens in the customer’s agent process.

Responsibilities by layer

Layer	Owns	Does not own
Host application	Model calls, orchestration, application state, and operation definitions.	Independent execution authorization.
ActionRail runtime	Rule evaluation, trusted context, live Source checks, decisions, durable reporting.	User authentication or business-system writes.
Source adapter	A restricted connection and a deterministic verification request.	Policy decisions or arbitrary model-generated queries.
Consequential tool	The actual side effect after an allow decision.	Deciding whether its proposed arguments are grounded.
Control plane	Registration, versioned configuration, audit metadata, reviews, operator health.	Proxying Source queries or tool execution.

The control plane is not a gateway

Tool calls do not pass through the ActionRail control plane. Source requests do not pass through it either.

The runtime receives configuration from the control plane, resolves secret references in the customer environment, establishes Source connections locally, and invokes the original tool locally after an allow decision.

This distinction matters for both latency and trust: adding ActionRail does not create a new hosted proxy in front of a customer’s databases, internal APIs, MCP gateway, or tools.

Local configuration mode

In local mode, the application supplies a rule configuration and Source definitions when it creates an ActionRuntime or wraps a supported agent.

This mode has no Console dependency and no remote human-review workflow. It is useful for development, tests, embedded deployments, and teams that want configuration entirely in code.

Console-managed mode

In managed mode, the SDK authenticates as a registered agent and fetches its current rule configuration and Source metadata. The Console also receives privacy-aware decision reports and can coordinate held actions.

Source credentials still resolve and remain in the customer environment. The control plane can store a reference such as ${env:BILLING_DB_PASSWORD}; it must not receive the referenced secret value.

Open-source scope and hosted tenancy

The open-source Console uses an implicit local scope and does not require users, organizations, or sign-up. It is designed for a developer or team running one trusted local installation.

Hosted deployments can resolve authenticated workspaces at the control-plane boundary. Core pages and runtime endpoints remain scope-aware without embedding hosted identity logic throughout the open-source application.

Agent runtime requests authenticate with the agent key associated with their scope. Browser workspace state is never used to authorize runtime reports or configuration fetches.

Data movement at a glance

Data	Default location	Control-plane behavior
Raw tool arguments	Customer runtime	Not reported by default.
Source query results	Customer runtime	Not reported.
Source credentials	Customer environment	Store only environment references in configuration.
Rule and Source metadata	Control plane or local config	Fetched and cached by the runtime in managed mode.
Decision outcome, timing, tool name, value-free reasons	Runtime and control plane	Reported as audit metadata.
Argument values explicitly named in write.report_args	Customer runtime and control plane	Exported intentionally; review this allowlist as sensitive configuration.

See Terminology for the object model and Mental model for decision behavior.