The Policy Engine: How Granular Toggles Replace Blanket AI Trust
"AI has access to Gmail" is not a security policy. "AI can read messages and create drafts, but not send or delete" is. Here's how Stow's Policy Engine enforces the difference.
When you connect an AI to a service using a raw API token, the AI has whatever permissions that token has. Usually that's everything. The Stow Policy Engine replaces that blanket access model with per-operation toggles — your AI gets exactly the capabilities you've explicitly granted, and nothing else.
The Problem With Raw API Access
Most service integrations work by handing the AI an API key or OAuth token. That token grants access to a predefined scope — and for most services, the available scopes are broad. A Gmail OAuth token with "mail" scope lets the holder read, send, delete, and manage labels. There's no "read-only except for my inbox" scope in Gmail's OAuth system.
This leaves you with a binary choice: give the AI full Gmail access, or don't connect it at all. The Policy Engine exists to make that choice more granular.
How the Policy Engine Works
Stow holds your service credentials and proxies all requests through its own policy layer. When Claude requests to execute a Gmail operation, the Policy Engine checks that specific operation against your configuration before it ever reaches Google's API. The credentials never leave Stow.
Each operation in each service has an independent setting:
Allowed
The operation executes immediately without interruption. Use this for low-risk, read-only, or frequently needed actions.
Approval Required
The operation is paused in your approval queue. You review the request and confirm before it executes. Use this for write operations or anything with side effects.
Off
The operation is blocked outright regardless of what the AI requests. Use this for destructive or permanently impactful operations you never want AI to perform.
How Toggles Map to Real API Scopes
The Policy Engine translates your human-readable toggles into actual API call restrictions. When you set "Send messages" to Off for Gmail, Stow blocks any request that would reach the gmail.users.messages.send endpoint — regardless of what the AI agent requests.
This is enforced server-side, not by instructing the AI. Even if you prompt Claude to "send this email," Stow intercepts the tool call before it reaches Gmail and returns a policy violation response. The AI's intent doesn't override the policy.
Example Configurations by Service
Gmail
GitHub
Slack
The Pending Approval State
When a request hits an operation set to Approval Required, it enters pending_approval status in the Activity Log. The AI agent receives a holding response — it knows the request was received but not yet executed. The request sits in your approval queue until you act on it.
If you approve, the operation executes against the service API and the status updates to executed. If you deny, the request is cancelled and logged as denied. The AI receives the outcome and continues the conversation accordingly.
Which Permissions Should Require Approval
A good rule of thumb: anything with external effects should require approval. Specifically:
- Communications (send email, post Slack message) — visible to other people
- Financial operations (Stripe charges, subscription changes) — irreversible money movement
- Deployment triggers (Vercel builds, GitHub merges) — can break production
- Bulk operations (updating many Airtable records) — hard to audit and reverse
Read operations, draft creation, and data retrieval can generally flow freely — they have no external effects and are inherently reversible.
Stow Security Team
April 19, 2026