Zapier Redesigns AI Agent Governance Around Resource-Based Rules

Zapier recently published a technical retrospective detailing how it redesigned the permission and approval architecture for Sidekick, its AI workspace agent. The company shifted away from fragile tool-centric prompts toward a deterministic, resource-based security engine designed to eliminate approval fatigue and prevent unexpected execution side effects.

What happened

According to the Zapier Blog, Sidekick's initial permission system categorized actions by tool types—running read-only operations automatically while pausing to request user approval on write, edit, or delete actions. However, this early implementation suffered from major architectural flaws. Permission requests were tied to open browser tabs, disappearing if a tab was closed or refreshed, while failed actions repeatedly triggered redundant prompts. Routine read operations also generated cards, causing important prompts to get lost in noise.

More critically, Zapier uncovered an internal system split: Sidekick's built-in capabilities and the custom code scripts it wrote to interact with apps ran on two separate permission engines with inconsistent rules. Furthermore, rules were attached to tools rather than objects—asking permission to use a generic "write tool" rather than guarding specific documents, accounts, or directory paths.

To resolve this, Zapier rebuilt Sidekick's security around resource-based permissions. Rules now attach directly to files, connected apps, websites, or automations, maintaining enforcement regardless of how the agent attempts to execute an action. Zapier established a strict deterministic evaluation logic: explicit "Never" rules strictly override all actions, followed by "Ask first" prompts, allowing silent execution only when no blocking rule exists. Additionally, Zapier moved approval prompts out of the linear chat transcript into a dedicated input panel and persistent global inbox, while hardcoding guardrails that prevent the agent from proposing blanket permission grants.

Why it matters for agent builders and operations leads

For small teams building or deploying AI agents into production, Zapier's technical retro highlights a fundamental infrastructure challenge: human-in-the-loop (HITL) governance cannot be treated as a chat-level prompt, but must be architected as a stateful, resource-aware backend rule engine. Tool-level permissions offer weak operational boundaries because risk is defined by the target resource—such as messaging a global Slack channel versus DMing a single user.

Over-prompting users leads to reflex rubber-stamping, while zero-prompt architectures risk total loss of trust after a single bad execution. By decoupling approval state from active conversation threads and enforcing rigid, deterministic overrides where denying an action always wins, orchestrators can grant agents operational autonomy without risking critical company data.

What to do this week

1. Shift permission evaluation from tools to target resources: Refactor your agent orchestration layer so security boundaries evaluate the destination asset (e.g., a specific database table or folder path) rather than the function call itself.
2. Enforce hardcoded deterministic policy overrides: Implement an explicit rule engine outside the model's context window where block rules unconditionally reject execution before any LLM tool call occurs.
3. Decouple human-in-the-loop state from chat UI: Store approval requests in a persistent server queue so pending execution gates survive closed browser tabs and long-running background tasks.

Sources

• How much should an AI decide without asking you first? — Zapier Blog