MCP Gateway Policies
Control which apps, and which actions of each app, your members' AI assistants can use through the Stacksync MCP
MCP Gateway Policies let workspace owners decide which apps their members' AI assistants can use directly through Stacksync MCP Gateway, which actions of each app they can run, and the guardrails that limit what assistants can see and change in each app.

How MCP Gateway Policies work
- Default Policy. Every workspace has a Default Policy. It allows all apps until a workspace owner restricts it, and it is always active.
- Custom policies. Workspace owners can create policies for specific users and groups. Members included in an active custom policy follow that policy instead of the Default Policy.
- Multiple policies. Every policy that includes a member, directly or through one of their groups, is evaluated on each call, one by one. The most permissive verdict sets the outcome: a call one policy allows runs, even when another policy refuses it. See How a call is decided.
- Workspace owners. Policies apply to workspace owners as well. Owners can always change the policies on the MCP page, which policies never limit.
- Guardrails. Each app a policy allows can carry guardrails: rules in plain language that limit what assistants can see in that app and every change through it. See Guardrails.
- Apps only. MCP Gateway Policies limit direct use of apps: running an app's actions and reading its forms. Workflows, Genies and syncs continue to follow workspace roles, and Stacksync's built-in apps, such as Stacksync AI, email, variables and queues, are always available.
How a call is decided
When an AI assistant calls an app directly, Stacksync evaluates every MCP Gateway Policy that reaches the member, one by one, and records each verdict:
- Which policies apply. The active custom policies that include the member, directly or through their groups. A member no custom policy includes follows the Default Policy.
- Apps and actions. Each policy says whether it allows the app and the action: allowed or blocked.
- Guardrails. For a change, each policy that allows the action is checked against its own guardrails: allowed, blocked, or confirmation needed. A policy without guardrails allows the change. For a read, the fields a policy's guardrails hide are removed from the result before the assistant sees it.
- The most permissive verdict wins. If any policy allows the call, it runs. Otherwise, if any policy needs the member's confirmation, the member sees a preview. Otherwise the call is blocked, and the assistant names the policy that blocked it.
Every verdict is kept with the call in the MCP Activity Log, where workspace owners see each policy evaluated, its result and the reason.
Change the Default Policy
Only workspace owners can change the Default Policy. It can't be renamed, paused or deleted, and it always applies to all workspace users.
- In the Stacksync app, open the MCP page and select the MCP Gateway Policies tab.
- Select Default Policy, the first row of the list.
- Under What can members access?, choose All apps, Only selected apps, or No apps. With No apps, members can use only Stacksync's built-in apps.
- Select Save MCP Gateway Policy.
Create an MCP Gateway Policy


Only workspace owners can create, change and delete MCP Gateway Policies.
- In the Stacksync app, open the MCP page and select the MCP Gateway Policies tab.
- Select Create MCP Gateway Policy.
- Under What is the name of this policy?, enter a Name and, optionally, a Description.
- Under Who does this policy apply to?, add the users and groups it applies to.
- Under What can members access?, choose All apps, or Only selected apps and add them. Expand an app to turn each of its actions on or off. An app with every action on also allows the actions the app gains later.
- Optionally, expand an app and add its Guardrails: the rules every change through that app must follow, in plain language. See Guardrails.
- Select Save MCP Gateway Policy.
Pause or delete a policy

- Pause: turn off the policy's Status switch in the list. A paused policy is saved but not enforced. Turn the switch back on to enforce it again.
- Delete: select the delete icon in the policy's row. The members it applied to follow their other policies, or the Default Policy when no other policy includes them. Deleting a policy can't be undone.
The Default Policy can't be paused or deleted.
Guardrails
Guardrails are rules written in plain language for one app of a policy. They can limit what assistants see and what they change, for example:
Marketing cannot see deal amounts or revenue.
Never change a deal's amount.
Don't delete or archive records.
Discounts above 20% need approval.How guardrails are applied
When a policy is saved, Stacksync turns each app's guardrails into rules. Expand the app in the policy to see how the Stacksync AI Guardrail check applies them:

| Rule | What happens on every direct call of the app |
|---|---|
| Hidden from what AI clients read | These fields are removed from what the app returns, with the free-text fields that could repeat them. |
| Never changed | A change writing these fields is blocked, including the related records they are computed from, such as a deal's line items. |
| Only these can change | A change writing any other field is blocked. |
| Not allowed | The action is blocked. Deleting includes archiving, inactivating or emptying a record. |
| No change allowed | Every change through the app is blocked. |
| Checked by Stacksync AI on each change | Stacksync AI decides from the values of each change, such as a discount above a threshold. |
| The person confirms each change | The rule depends on facts a single change doesn't carry, such as who owns the record, so the member confirms each change first. |
When you edit the guardrails, the rules are updated on the next save. If Stacksync can't read the guardrails at that moment, the policy isn't saved and you are asked to save it again, so a policy never runs with guardrails that weren't applied.
What assistants read
When a policy's guardrails hide fields, they are removed from what an app action returns before the assistant sees it. The rest of each record is still returned, and the assistant tells the member which fields were hidden and that a workspace owner can change the policy:

A field Stacksync hasn't seen before, such as a custom field, is checked by its name the first time it appears and remembered after that. Stacksync AI reads field names only, never their values. A value typed into another field, such as an amount written in a deal's name, is not detected.
How a change ends
| Outcome | What happens |
|---|---|
| Allowed | The change runs. |
| Blocked | Nothing runs or changes. The assistant tells the member which guardrail blocked the change. |
| Confirmation needed | The member sees a preview of the change with the reason, and it runs only after they select Accept, like Ask before every change. |
To set guardrails, open the policy in the MCP Gateway Policies tab, expand the app under What can members access?, and write the rules under Guardrails. Each app has its own guardrails. A member covered by several policies has the guardrails of every policy checked, and gets the most permissive outcome: a change one of their policies allows runs, and a field stays visible when one of their policies shows it. The verdict of each policy, with the guardrail it applied, is recorded in the MCP Activity Log.
For a change, only the change itself is checked: the action, the app and the values the assistant sends. Stacksync never reads other records of the app for the check.
What your members see
When an MCP Gateway Policy blocks a request, nothing runs or changes. The AI assistant tells the member which policy blocked it and to ask a workspace owner, for example:
Blocked by the MCP Gateway Policy "Sales team": the Update record action of hubspot is not allowed. Nothing was changed. Ask a workspace owner to change it.A change a guardrail blocks names the guardrail and the reason from the Stacksync AI Guardrail check:
Blocked by the MCP Gateway Policy "Marketing Team": this change with Update Records of hubspot, under the guardrail "Never change a deal's amount." (Stacksync AI Guardrail check: The change writes amount, which may not be changed) is not allowed. Nothing was changed. Ask a workspace owner to change it.A read whose guardrails hide fields returns the rest of the result and names what was hidden:
Hidden by the Stacksync AI Guardrail check of the workspace's MCP Gateway Policy: amount, total. To see them, ask a workspace owner to change the policy.Every call an MCP Gateway Policy decides is recorded in the MCP Activity Log, with the verdict of every policy evaluated and its reason.
Members who are not owners see the Default Policy and the policies that apply to them in the MCP Gateway Policies tab.
Good to know
- API keys. A workspace API key follows the Default Policy. A user API key follows the policies of its user. Learn more about API keys.
- When changes apply. A saved policy applies right away. A change of group membership applies within 5 minutes.