Every agent runs inside a policy envelope. The envelope is the contract: this is what’s allowed, this is what isn’t, this is what asks first. Glide enforces it on every tool call, regardless of what the agent’s prompt says. Think of it like spending controls on a corporate card — but with sharper teeth, applied at the API layer instead of the network layer.Documentation Index
Fetch the complete documentation index at: https://glide-9da73dea.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
What the envelope controls
| Control | What it means | Example default |
|---|---|---|
| Per-transaction max | Largest single transaction the agent can propose | $2,500 |
| Daily cap | Maximum total transaction value in 24 hours | $10,000 |
| Counterparty allowlist | Who the agent can pay; everyone else is blocked | Your existing vendor list |
| Step-up threshold | Above this amount, you have to approve via Face ID / passkey | $0 (every transaction asks) |
| Time window | Hours of day or days of week the agent can transact | Business hours, weekdays |
| Velocity cap | Max number of transactions in a rolling time window | 20 / hour |
| Risk verdict gate | Block if the anomaly detector flags | Flag → block automatically |
How enforcement works
When the agent calls a Glide tool (e.g.,payments.initiate), the request goes to Glide’s MCP server. The server runs the request through:
- Grant validation — OAuth token is signature-verified and not expired.
- Fresh-read tenant check — we re-read your tenant from the database, so a stolen grant against a stale tenant fails.
- Policy evaluation — the request is checked against every axis above. Any failure blocks the call.
- Step-up check — if the request crosses a threshold, you get a step-up prompt; the agent waits for your approval.
- Anomaly check — the risk model evaluates the request against your account’s history. A
flagverdict pauses for review; ablockverdict rejects. - Receipt write — the call is logged with redacted input + output digests, the policy version that was in force, and the verdict.
Versioning the envelope
Every change to your policy envelope bumps thepolicy_version counter. Tool calls in flight when you make a change see a PolicyStaleError on their next attempt — they have to fetch the new envelope and retry. This guarantees your envelope changes take effect immediately, with no race window.
The version is also logged in every receipt. When you replay an old call later, you can see exactly which envelope was in force at the time.
What you cannot configure
A few defaults are immutable:- Sanctions screening always runs. You can’t disable it. Every counterparty and every on-chain destination is screened on every call.
- The append-only audit log. You can’t delete or modify receipts. Even Glide can’t modify them outside a strict DSAR redaction flow.
- Max grant TTL of 60 minutes. Beyond that, the agent has to refresh its OAuth grant.
Per-skill envelope templates
Each skill ships with a recommended envelope template. The template is a starting point that’s been tuned for the skill’s typical use:- AP agent — per-tx 10,000, allowlist = QBO/Xero vendors, step-up every payment.
- Treasury — per-tx 200,000, allocation min/max per strategy, step-up >$25k.
- Market research cap — per-tx 1,000, no allowlist (any merchant), step-up >$50.
Changing the envelope after install
Open Agents → pick the agent → Policy in your dashboard. Edit any axis. The change applies immediately on the next agent tool call (in-flight calls seePolicyStaleError and retry against the new envelope).
Big envelope loosenings (e.g., 10x bump on the daily cap) require step-up before they save. We don’t want a stolen session changing your envelope as a precursor to a malicious tool call.