Why agent safety policies need AND/OR logic (and how we added it to Canopy)

When I shipped Canopy v0.1 last week, the most common question I got was some version of this: "Can I write a policy that only blocks in production? Because I want the same agent to run freely in staging." The answer was no. And that was a real problem. The Limitation in v0.1 Canopy's original policy engine matched on substrings and regex patterns against the action payload. Simple and fast. But the rules had no awareness of context. This meant you could write: execute_shell : deny_if : - " rm -rf" - " mkfs" But you couldn't write: DENY rm -rf only when env == "production" The only option was to either block everywhere or block nowhere. For teams running the same agent in multiple environments, that's a non-starter. The Real-World Case That Broke It Here's the scenario that made this concrete. Imagine an agent that manages log cleanup across environments. In staging, rm -rf /tmp/logs is fine — that's exactly what it should do. In production, you want a human to approve that before it r