Change-Freeze-Aware Action Gate

Problem

A freeze stated only in a prompt or a UI label is an intention, not a control. An agent that can still reach production APIs can act inside the window whether or not it was told about the freeze, and one such action during a blackout can cause exactly the outage the freeze exists to prevent. Existing gates check an action's risk, reversibility, or role, but none of them encode time, so an otherwise-permitted action is allowed even when the calendar says no change may happen now. The freeze has to be enforced at action time, not assumed.

Solution

Maintain the freeze calendar as a queryable authority source: each freeze has a start and end time and a scope of services, regions, or teams. Before any mutating tool call, the gate looks up whether an active freeze covers the action's scope at the current time. If none does, the action proceeds; if one does, the gate blocks the action and either denies it or routes it to an explicit human re-authorisation that records who approved the exception and why. The freeze decision is made by the calendar and the clock, not by the agent's own reasoning, so the agent cannot talk itself past a blackout, and the same window a human would respect is enforced against the tool. Read-only actions pass freely; the gate constrains only changes.

When to use

• An agent can issue changes to production systems that are subject to declared freeze or maintenance windows.
• Freezes are scoped and time-bounded and can be exposed as a queryable calendar.
• Urgent exceptions must remain possible under explicit human authorisation.