Time-Based Policies: Different Rules for Different Hours
Time-Based Policies: Different Rules for Different Hours
At 2 PM on a Tuesday, your AI agent has your full attention. You're watching the dashboard, reviewing escalations promptly, and ready to intervene if something goes sideways. At 3 AM on a Saturday, nobody's watching.
These two scenarios require fundamentally different safety policies. Time-based policies in SafeClaw let you define exactly that — different rules for different hours.
The Intuition
Time-based access control is a well-established pattern in traditional security. Corporate networks restrict VPN access outside business hours. Building access cards work only during scheduled shifts. Database admin privileges expire after maintenance windows.
The same logic applies to AI agents. An agent running with human oversight can operate with broader permissions because a human is available to catch and correct mistakes. An agent running unattended should operate with tighter constraints because mistakes will go unnoticed until someone checks in the morning.
How It Works
Time-based policies are defined as schedule blocks in your SafeClaw configuration:
``yaml
time_policies:
business_hours:
schedule: "Mon-Fri 09:00-18:00"
timezone: "America/New_York"
profile: standard
after_hours:
schedule: "Mon-Fri 18:00-09:00"
profile: strict
escalation: defer
weekends:
schedule: "Sat-Sun *"
profile: strict
escalation: defer
budget: 5.00/day
`
Schedule blocks are evaluated in order. The first matching block determines the active policy. If no block matches (which shouldn't happen with a complete schedule), SafeClaw falls back to the most restrictive profile defined.
What Changes with Time
Time-based policies can modify any aspect of SafeClaw's behavior:
Policy Profile — Switch between different policy profiles based on time. Use a standard profile during business hours and a strict profile after hours.
Escalation Behavior — During business hours, escalations go to push notifications for immediate response. After hours, escalations are deferred — the agent pauses and the escalation waits until the next business hours window.
Rate Limits — Tighter rate limits after hours slow the agent down, reducing the blast radius of any mistakes before a human can review.
Budget Caps — Lower budget limits outside business hours prevent overnight cost surprises. A $50/day budget during business hours might become $5/day on weekends.
Action Restrictions — Some actions that are allowed during business hours might be completely denied after hours. Deployments, database migrations, and infrastructure changes are common candidates for after-hours denial.
Timezone Handling
Getting timezones right is critical. SafeClaw uses IANA timezone identifiers (like
America/New_York, not EST) and handles daylight saving time transitions correctly. The schedule evaluation uses the system's timezone database, so it stays accurate without updates from us.
For teams spread across timezones, you can define multiple schedule blocks with different timezone references:
`yaml
time_policies:
us_business:
schedule: "Mon-Fri 09:00-18:00"
timezone: "America/New_York"
profile: standard
eu_business:
schedule: "Mon-Fri 09:00-18:00"
timezone: "Europe/London"
profile: standard
``
Overlapping schedules are resolved by priority order — the first match wins. This lets you define broad default schedules with specific overrides.
Transition Handling
What happens when the clock crosses a boundary mid-session? SafeClaw handles transitions gracefully. The current action completes under the old policy, and subsequent actions use the new policy. There's no interruption to the agent's workflow — the policy simply becomes more or less restrictive.
A warning is logged when a transition occurs, and if the new policy is more restrictive, a notification is sent to inform the user that the agent is now operating under tighter constraints.
Real-World Patterns
Our users have developed creative time-based policy patterns:
- Maintenance windows — Allow infrastructure changes only during scheduled maintenance periods.
- Demo protection — Restrict all write operations during customer demo hours.
- Learning hours — Relax policies during training sessions so new developers can experiment freely.
Full configuration documentation is in our docs. The time-based policy implementation is on GitHub.
Time is context, and context determines risk. Time-based policies let you encode that relationship directly into your safety configuration.