Permissions and approvals
An AI connection can act only within its selected workspace, app grants, capabilities, current member role, and product entitlements. OAuth establishes the connection; it does not bypass UserGist's business rules.
Grants and execution mode
| Grant or control | What it permits |
|---|---|
| Domain read | Read that product area's permitted records and previews. |
| Domain manage | Author or edit within that area; separate publication and sending restrictions still apply. |
| Publish | Explicit public-content or experience lifecycle actions. Live experience edits also require this capability. |
| Send | Native push activation/test sends or integration test events, in their respective domains. |
| Administrative access | App, branding, portal, and integration settings remain subject to existing admin/owner role requirements. |
| Read-only mode | Blocks product mutations even when saved grants include manage/publish/send. |
| Server rollout controls | Can disable the workspace, the endpoint, or writes independently of saved grants. |
Default consent selects an app and Approve changes. Publishing, native push sending, integrations, and administrative capabilities are visible opt-ins. Only the connection owner can expand grants or enable automatic execution through authenticated settings; no MCP tool can do that for itself.
Approval inside the conversation
In Approve changes, the first mutation call validates its schema and targets and prepares an immutable proposal without changing product state. The preview names the action, normalized arguments, timestamp, side effects, and available impact information. It expires after ten minutes.
When the negotiated client supports the server's native form flow, the assistant presents an approval form. Accepting the exact change permits execution; declining or cancelling leaves it unexecuted. Large previews can use the client-managed flow so the full content can be read in slices.
Otherwise, the assistant shows the preview and asks you to confirm in the conversation. Only then should it repeat the same tool with the same arguments and idempotency key, adding the returned proposalId.
A proposal ID proves which preview execution refers to, not whether a human approved it. In the fallback flow, your AI client enforces confirmation. Native form acceptance and client-managed confirmation are recorded separately; neither is cryptographic proof of human involvement.
There are no external per-action review pages. Your AI client may ask for its own confirmation before either call, including in Automatic mode. UserGist cannot disable that client policy.
Example: preview and update a request
After reading the request and choosing its exact IDs, the assistant calls update_request. Replace these illustrative UUIDs and generate a fresh key for a new operation:
{
"appId": "11111111-1111-4111-8111-111111111111",
"requestId": "22222222-2222-4222-8222-222222222222",
"input": { "status": "planned" },
"idempotencyKey": "33333333-3333-4333-8333-333333333333"
}Review the returned preview, including possible follower notifications. After your confirmation, the client-managed execution call adds only the proposal ID:
{
"appId": "11111111-1111-4111-8111-111111111111",
"requestId": "22222222-2222-4222-8222-222222222222",
"input": { "status": "planned" },
"idempotencyKey": "33333333-3333-4333-8333-333333333333",
"proposalId": "44444444-4444-4444-8444-444444444444"
}The server rechecks authorization, target revisions or state fingerprints, billing, and domain rules immediately before committing. If any relevant state changed, it rejects the proposal instead of silently applying it to new content.
Status and safe retries
| Status | Meaning and next step |
|---|---|
needs_approval | Read the whole preview and confirm or decline. Nothing has changed yet. |
queued / running | Work remains. Read get_operation; do not submit another mutation. |
succeeded | The operation completed. Provider acceptance does not itself prove a device displayed a notification. |
failed | Inspect the operation and current target; an action with failed deferred work can already have committed its database changes. |
indeterminate | A delivery outcome could not be established. Inspect delivery evidence; never blindly resend. |
cancelled / expired | An unexecuted proposal cannot execute. Prepare a new preview only if you still want the change. |
Reusing an idempotency key with different arguments is rejected. For a lost response, reuse the original key and arguments or retrieve the known operation; a new key means a new logical action. After a stale or expired proposal is confirmed unexecuted, fetch current state and prepare a new proposal with a new key.
Declining in a client-managed conversation means the client must not submit the execution call. An abandoned proposal expires automatically; there is no general-purpose cancellation tool in the current catalogue. Cancelling an unexecuted proposal cannot recall work already published or dispatched.
Live changes and deferred delivery
Draft document edits do not change the published snapshot. Updates to already active experiences or scheduled push campaigns can affect future delivery immediately and require the relevant publish/send privilege. Segment or brand-default changes can affect other live consumers.
Audience counts include a calculation timestamp. Approval covers the targeting rule and schedule, not a permanently frozen set of people. Audience-join activation waits for queued initialization; users already matching when initialization runs are suppressed under the no-backfill behavior.
Connection policy changes or revocation can prevent queued work and future server-authorized delivery of MCP-activated experiences. Review and reactivate intended work under current permissions when necessary. Content already published and instructions or notifications already dispatched cannot be recalled.
Activity, revocation, and privacy
In Workspace settings → AI connections, members manage their own connection grants and mode. Owners/admins may revoke other workspace connections, but cannot expand them. Activity lists the latest 50 operation records without raw customer content.
Unexecuted proposals expire after ten minutes. Background maintenance purges encrypted temporary operation content after 24 hours and retains operation metadata and target references for 30 days, subject to source-deletion cleanup. Revoked app or capability access also restricts earlier operation results.
Returned records become available to the connected AI client. Choose a client and organization policy appropriate for your workspace data. Existing integration/provider secrets and server credentials are never intended as tool output; app creation explicitly distinguishes its publishable SDK key.
The initial limits are 120 tool invocations and 30 mutation executions per minute, enforced per connection and across its workspace. Preview calls consume the invocation allowance. On RATE_LIMITED, wait for the next minute; retrying aggressively does not advance the operation.