Skip to content

Run Time Guardrails

At run time, the same RCG.md that guided development is loaded into your deployed agent's guardrail layer — checking every action and output against the regulatory dos and don'ts before it reaches the user.

How It Works

Run time guardrail architecture: agent action → RCG policy → allowed ships / blocked flagged

When an AI agent is deployed in production, it operates inside a layered architecture. The RCG.md file is loaded into the guardrail / policy engine as the policy source:

policy source: RCG.md → dos / don'ts

Every agent action and output passes through this policy check at inference time:

  • Allowed → ships — the action is within the regulatory boundaries; it proceeds to the user
  • Blocked / flagged — the action violates a dos/don't from RCG.md; it is stopped or flagged before it ships

This means regulatory oversight happens at the moment of inference, not after an audit. There is no post-effect gap.

The 7-Layer Deployment Stack

The MeridianPay demo illustrates how RCG slots into a full compliance-by-construction agent architecture:

MeridianPay demo showing pre-LLM and post-LLM layers with topic subscriptions and enforcement signals

Layer Role
Pre-LLM layers (L1–L5) PII detection, topic routing, retrieval, prompt construction
LLM (L5) The core language model
Post-LLM layers (L6–L7) Validator and redaction — where the RCG guardrail runs

The right panel of the admin console shows:

  • Topic subscriptions — the regulators actively monitored for this agent (CFPB, Federal Reserve, FDIC, OCC, FTC, NYDFS), each with a description of the specific guidance being enforced
  • Enforcement signals — live enforcement actions from those regulators, surfaced in real time when the Carver SDK is enabled

Live Enforcement Signals

When the Carver SDK is enabled, the guardrail layer receives live enforcement signals from Carver's regulatory monitoring network. If a regulator issues new guidance or an enforcement action that affects your agent's behavior, the policy engine can be updated without a code deployment.

This closes the gap between when a regulation is issued and when your agent complies with it — from weeks (waiting for the next audit cycle) to hours (next signal fetch).

Compliant-by-Default Behavior

The outcome of run time RCG enforcement is:

  • Violations are blocked or flagged in-line — the user never sees non-compliant output
  • No post-effect audit gap — compliance is proven at inference time, not reconstructed from logs after an incident
  • Consistent enforcement — the same RCG.md that shaped the code also governs the deployed behavior, so there's no drift between what was built and what's enforced