Skip to main content

Security model

ActionRail is a runtime correctness and enforcement gate for consequential agent tool calls. It assumes the host application and trusted Source systems establish identity and facts; ActionRail independently evaluates whether one proposed call is consistent with those inputs before the original tool runs.

Protection boundary​

The model is not trusted to authorize its own action. Tool arguments are treated as a proposal. Host context and Source results carry more authority because they originate outside the model loop.

Trust assumptions​

ComponentAssumption
Host applicationAuthenticates the caller, binds correct trusted context, keeps agent credentials secret, and invokes the wrapped agent.
ActionRail runtimeRuns in the same trusted process boundary as the agent application and loads reviewed configuration.
SourceReturns authoritative current facts through a least-privilege read identity.
Consequential toolCreates the effect only when its original function is actually called.
Control planeStores configuration and audit metadata according to the deployment’s access and retention controls.
Model and model-generated argumentsUntrusted for authorization and external facts.

What ActionRail protects against​

  • a model selecting a real record that belongs to another caller;
  • a fabricated, stale, missing, blocked, or wrong-state identifier;
  • an amount outside a deterministic local limit;
  • an action whose required verification Source cannot be reached, when configured fail closed;
  • execution after a human rejection, review timeout, unavailable review service, or expired remote configuration;
  • silent loss of accepted audit metadata during ordinary delivery failures.

What ActionRail does not replace​

Authentication and authorization​

The host must authenticate users and authorize access to the agent. Source systems and gateways must enforce their own credentials and tenant boundaries. ActionRail policy v1 is not a general replacement for OPA, Cedar, IAM, RBAC, or application authorization.

Source integrity​

ActionRail can only reason over the facts a Source returns. A compromised database, mislabeled MCP tool, overprivileged HTTP token, or incorrect verification endpoint can produce an unsafe answer.

Tool security​

The underlying tool must still validate inputs, authenticate to its destination, handle idempotency, and apply domain invariants. Defense in depth remains necessary even after an allow decision.

Direct calls outside the gate​

ActionRail wraps tools discovered on the agent. Application code that retains and calls an original function directly can bypass the wrapper. Keep consequential effects behind the wrapped tool surface and test that blocked paths never invoke them.

A compromised host process​

The SDK runs in-process. Code with control of that process can disable the wrapper, change local configuration, read trusted context, access Source credentials, or call tools directly. Use normal workload isolation, code review, deployment integrity, and secret controls.

General prompt-injection detection​

ActionRail can stop an injected instruction from producing an ungrounded consequential call when the relevant tool and arguments are covered. It does not detect or remove prompt injection from model input, retrieval, memory, or output.

Configuration is security-sensitive code​

Review rule changes with the same care as application authorization logic. In particular:

  • an uncovered consequential tool passes through;
  • monitor mode never enforces;
  • on_error: allow fails open;
  • on_fail: hold delegates a mismatch to a person;
  • max_config_staleness=None accepts indefinite old authority;
  • write.report_args exports selected runtime values.

The Console surfaces coverage, mode, invalid configuration, Source health, and recent issues so these choices are visible to operators.

  1. Start in monitor mode with production-like traffic.
  2. Verify every consequential tool is discovered and intentionally covered.
  3. Use authenticated invocation-scoped trusted context.
  4. Give each Source a dedicated least-privilege read identity.
  5. Keep default block behavior for Source errors unless risk review approves otherwise.
  6. Test allow, hold, block, Source outage, Console outage, and shutdown recovery.
  7. Switch to enforcement only after coverage and failure behavior are understood.