How Zapier Handles Access Control
Zapier is an automation platform connecting 8,000+ apps through event-driven workflows called Zaps. Its access control model is built around human users managing automations, not around governing autonomous agents.
Account-Level Roles
Zapier uses a simple role hierarchy:
- Account Owner — Full control. Manages billing, users, all Zaps, and all connected app accounts. Can transfer ownership.
- Admin — Can manage team members, create and edit any Zap in the account, manage shared app connections, and view usage.
- Member — Can create and edit their own Zaps, use shared connections, and work within assigned folders.
- Restricted Member (Enterprise) — Limited to specific folders. Can only see and edit Zaps within their assigned scope.
That’s the entire role model. There’s no custom role builder — you pick from these tiers.
Connection Sharing
When a user connects an app (e.g., authenticates with HubSpot OAuth), that connection can be:
- Private — Only the user who created it can use it in their Zaps
- Shared — Any team member can use the connection in their Zaps
This is binary. There’s no way to say “share this connection with Marketing but not Sales” or “allow reads but not writes through this connection.” If a HubSpot connection is shared, anyone on the team can build a Zap that deletes contacts through it.
Folder-Based Organization
Enterprise accounts get folder-based access control:
- Zaps are organized into folders
- Restricted members can be scoped to specific folders
- Folder permissions are view/edit — no finer granularity
App Connection Permissions
Zapier inherits whatever OAuth scopes or API permissions the connected app grants. If your Salesforce connection has full admin access, every Zap using that connection has full admin access. Zapier itself doesn’t filter or restrict what operations a Zap can perform through a connection — it passes requests straight through.
Audit and Compliance
- Zap History — Logs each Zap run with input/output data, success/failure status. Retained based on plan tier (limited on Free, longer on Enterprise).
- SOC 2 Type II — Zapier holds this certification.
- SSO/SAML — Available on Enterprise plans for centralized authentication.
- Data retention controls — Enterprise can configure how long task data is stored.
What Zapier Doesn’t Do
Zapier’s access control has significant gaps when AI agents enter the picture:
- No per-Zap operation restrictions — A Zap using a shared connection can perform any operation the connection allows. You can’t say “this Zap can read contacts but never delete them.”
- No agent identity — Zapier’s new AI Agents and MCP features let AI trigger Zaps, but Zapier doesn’t distinguish which AI agent triggered it or enforce per-agent limits.
- No behavioral guardrails — No rate limiting per Zap or per user beyond global account task limits. No content validation. No approval workflows before a Zap executes a destructive action.
- No conditional or temporal permissions — You can’t grant “access to this Zap only during business hours” or “for the next 4 hours.”
- No cross-platform governance — Zapier sees individual Zap runs. It doesn’t know the broader context — what the same agent did in Slack before triggering a HubSpot update via Zapier.
- Connection over-sharing — A shared connection is all-or-nothing. The person who authenticated may have admin-level access, and that full privilege is available to every team member’s Zaps.
How The Orchestrator Differs
The Orchestrator and Zapier solve fundamentally different problems. Zapier answers “how do I connect App A to App B?” The Orchestrator answers “who is allowed to do what, through which tool, under what conditions?”
Agent-First Identity
The Orchestrator knows exactly which agent is making a request. Not just “a Zap ran” but “Agent X, owned by User Y, with permission key Z, is attempting operation W.” Every action is attributed to a specific identity with a specific permission scope.
Operation-Level Granularity
Where Zapier inherits the full privilege of whatever OAuth connection it uses, The Orchestrator defines permissions per tool, per operation. A zapier_read_contacts tool can exist separately from zapier_create_deal, each with its own permission key. An agent gets exactly the operations it needs and nothing more.
Credential Isolation
In Zapier, shared connections mean shared privileges. In The Orchestrator, credentials never leave the server process. An agent requests an action — The Orchestrator checks permissions, executes the API call with the stored credentials, and returns only the result. The agent never sees the OAuth token, API key, or connection details.
Behavioral Guardrails
The Orchestrator enforces policies Zapier can’t:
- Per-agent rate limiting — “This agent can trigger at most 20 Zapier actions per hour”
- Content validation — Inspect payloads before they reach Zapier
- Approval workflows — Queue destructive actions for human review
- Volume caps — “No more than 50 contact updates per day through this tool”
Temporal Permissions
TTL-based grants let you give an agent Zapier access for a defined window. Campaign launch? Grant the marketing agent 8 hours of access to the email trigger Zap. It expires automatically — no manual cleanup.
Cross-System Audit
Zapier logs its own Zap runs. The Orchestrator logs the full chain: the agent read from the CRM, queried HubSpot, triggered a Zapier Zap, then posted to Slack. One audit trail across all systems, tied to a single agent identity.
Complementary, Not Redundant
| Concern | Zapier | The Orchestrator |
|---|---|---|
| Connect App A to App B | Core strength — 8,000+ integrations | Not an integration platform |
| Who can build automations? | Role-based (Owner/Admin/Member) | Not involved in Zap creation |
| Which apps can a Zap use? | Whatever connections are shared | Not involved |
| Which AI agent can trigger which automation? | No agent-level distinction | Per-agent, per-tool permissions |
| Can an agent delete data vs. only read it? | Inherits full connection privileges | Fine-grained per operation |
| Rate limits per agent? | Only global account task limits | Per agent, per tool |
| Temporary access grants? | No | TTL-based permissions |
| Cross-system audit trail? | Only Zapier runs | Full multi-system trail |
| Credential visibility | Shared connections visible to team | Credentials never leave server |
| Approval before destructive actions? | No | Configurable workflows |
They operate at different layers:
- Zapier’s layer — Connects apps, runs automations, manages team access to Zap-building. Great at what it does.
- The Orchestrator’s layer — Sits in front of Zapier (and every other system), governing which AI agents can trigger which automations, with what limits, for how long, and logging everything.
A Practical Example
Your company uses Zapier to sync HubSpot deals to Salesforce. A sales AI agent needs to trigger this sync when it qualifies a lead. Without The Orchestrator:
- The agent needs access to the Zapier webhook URL
- Anyone with that URL can trigger unlimited syncs
- No per-agent throttling, no approval for large batches, no audit linking the trigger back to the agent’s lead qualification reasoning
With The Orchestrator:
-
The agent calls
zapier_trigger_deal_sync— an MCP tool with its own permission key - The Orchestrator verifies the agent has this permission, checks rate limits, logs the action with full context
- The webhook URL stays inside The Orchestrator — the agent never sees it
- If the agent tries to trigger 500 syncs in a minute, the guardrail stops it
Zapier remains the execution engine. The Orchestrator is the governance layer. They’re complementary — and together they give enterprises the confidence to let AI agents operate autonomously without losing control.