Shielding
A shield is a safety filter between your policy and the environment: it checks every proposed action against a written safety rule and swaps out the ones that would cause harm.
Why Does This Exist?
Standard RL learns by trying things, and some things should never be tried even once. A robot arm that finds its joint limits by snapping them, or a trading bot that finds ruin by going broke, has learned a lesson you cannot afford.
Safe RL frames this problem with costs and constraints: maximize reward while keeping expected cost below a threshold. That framing usually promises a safe policy at the end of training. But during training the agent still walks off the cliff. It has to, because that is how it learns where the cliff is.
Shielding fixes training itself. A shield sits between the policy and the environment, inspects every proposed action, and replaces the dangerous ones before they execute. The agent never experiences the catastrophe, so it never needs to learn the penalty for one.
This page covers the shield mechanism: pre-shield versus post-shield, the written safety spec, minimal interference, and why this is not reward shaping. The broader costs-and-constraints picture lives on the Safe RL page.
Think of It Like This
The Height Bar at the Roller Coaster
You are a kid who wants to ride everything in the park. The height bar does not tell you which rides are fun, and it never changes the rides. It checks one rule, are you tall enough, and it stops you only at the rides that could hurt you. Every other choice stays yours.
A shield works the same way. Your policy picks whatever looks rewarding, and the shield checks one rule, does this action keep us inside the safe set. Safe proposals pass through untouched. Unsafe ones get swapped for a safe fallback, and the ride goes on.
Where the analogy stops: a height bar measures you directly, while a shield needs two things written down in advance, a safety spec and a model predicting what each action does next. Get either wrong and the gate guards the wrong thing.
How It Actually Works
The policy proposes an action in state . The shield computes a verdict. The environment only ever sees the shield's output:
where is a known safe fallback action and is the current state. Learning continues as normal on the executed action, but the catastrophe never executes.
Pre-shield versus post-shield
A pre-shield filters the action set before the policy chooses. In state it hands the policy only the safe subset, so the policy never considers the cliff. This is cheap at decision time but needs the safe set computed upfront for every state.
A post-shield monitors after the policy proposes. The policy ranks all four actions freely, proposes its favorite, and the shield overrides only on violation. This works with any policy, including one you already trained, at the cost of one safety check per step. The worked example below uses a post-shield.
The safety spec in LTL
The rule is written in linear temporal logic (LTL), a language for statements about behavior over time. Our toy spec is:
Read it as: at every future moment (, always), the position stays left of 3. Given this spec plus a simple model of how actions move the agent, the shield is synthesized from a safety game, and it is correct by construction for as long as the model matches reality.
Worked example: four actions on a ledge
The agent stands at . Positions 0, 1 and 2 are safe; anything at 3 or beyond is the cliff. The fallback is . The shield evaluates each proposal by adding the move effect and testing :
- left: , and , so ALLOW. The shield passes it through and the agent steps to 1.
- right: , and is false, so BLOCK. The shield substitutes stay and the agent stays at 2.
- stay: , and , so ALLOW. It passes through untouched.
- jump (+2): , and is false, so BLOCK. The shield substitutes stay and the agent stays at 2.
Two of the four proposals pass through exactly as proposed. That is minimal interference: the shield changes the minimum needed to keep true and leaves everything else alone. Note what never changed: the reward function. No penalty was added, no bonus removed.
Why this is not reward shaping
Reward shaping edits the reward signal, say for visiting the cliff, and hopes the policy learns to avoid it. But a policy maximizing shaped reward can still pick the cliff whenever the gain exceeds 10, and it must visit the cliff during training to learn the penalty exists. The guarantee is soft and arrives late.
A shield removes the choice instead of repricing it. Even with garbage Q-values on day one of training, the cliff action cannot execute, because the environment never receives it. The price is that you must write the spec and supply a model of action effects. Shaping needs neither, which is exactly why it guarantees neither.
Code
A post-shield for the ledge toy. The spec check is one comparison, and the fallback is always stay:
def shield(proposed: str, x: int) -> str: """Post-shield for the ledge toy: spec G(x < 3), fallback stay.""" effects = {"left": -1, "right": 1, "stay": 0, "jump": 2} if x + effects[proposed] < 3: return proposed return "stay"
x = 2for a in ["left", "right", "stay", "jump"]: print(f"proposed {a}, executed {shield(a, x)}") # -> proposed left, executed left # -> proposed right, executed stay # -> proposed stay, executed stay # -> proposed jump, executed stayWatch Out For
An over-conservative shield can deadlock the agent
When the spec is stricter than reality, the shield blocks the only routes to reward along with the danger. The symptom is an agent that sits perfectly still forever: zero cost, zero reward, and a shield intervention rate near 100 percent. The policy is not broken; it never gets to act.
Fix it by measuring the intervention rate during training. If nearly every proposal is overridden, loosen the spec to allow passing near the hazard with a margin, or give the fallback some recovery behavior instead of a frozen stay. A shield that fires constantly is a spec that needs editing.
A shield only enforces the spec you wrote
Our spec says nothing about position 0. If 0 hides a second hazard, say a patch of ice, the shield waves the agent straight into it with full approval. The symptom is a "safe" agent that still crashes, and the crash log shows ALLOW on every step that led there.
Fix it by reviewing the spec against real failure logs before trusting the gate. List every hazard from incident reports, check each one appears in the spec, and retest after every spec edit. A shield complements testing; it never replaces it.
The Quick Version
- A shield sits between policy and environment and replaces actions that would break a written safety spec before they execute.
- A pre-shield filters the action set before choosing, while a post-shield overrides bad proposals after the policy picks.
- The spec is written in LTL, such as , and the shield intervenes only when a proposal would violate it.
- In the ledge toy at , left and stay pass through while right and jump are swapped for stay, so 2 of 4 moves are stopped.
- Reward shaping reprices danger with penalties but still lets the agent visit it, while shielding removes the choice and holds during training.