Skip to main content
App Rules let you intercept individual tool calls for any third-party app your organization uses and either block them or tag them. Rules are written as a plain-English intent in the AI rule builder, which turns it into a structured condition and shows you exactly which past tool calls it would have affected before you save.
App Rules tab with Search and time range filter, Rule matches / Allowed / Tagged / Blocked stat cards, an Enforcement Activity histogram, and a Rules by Server list

​
What you get on the App Rules tab

  • Stat cards for the selected time range: Rule matches, Allowed, Tagged, Blocked.
  • Enforcement Activity histogram: allowed vs. blocked tool calls over time.
  • Rules by Server: every app that has rules (or could have rules), with its rules listed underneath. You can toggle each rule on or off from here.
  • Search + time range filter to narrow down the view.
  • + App Rule button to create a new rule.

​
How a rule works

A rule is evaluated every time a user or agent invokes a tool on the app it targets. Each rule has four core pieces of configuration:
1

Phase (check_type)

Pick before to check the call before it runs, or after to check it once the result comes back. Use before to block risky actions and after to tag calls based on what was returned (for example, a search that came back with sensitive data).
2

Action

Pick block to deny the call, or tag to let it through while labeling the call with your rule’s name so you can find it later in activity views.
3

Scope

Limit the rule to specific tool names on the app (for example, only send_message in Slack, or only create_event in Google Calendar). Leaving it empty applies the rule to every tool on that app.
4

Condition

A CEL expression that decides whether the rule fires. You have access to:
  • args — the arguments the caller passed to the tool
  • tool_name — the tool being called
  • server_id — the app the tool belongs to
  • output — the tool’s return value (only in after rules)
Example: args.channel == "C05QG7RF30A" fires whenever Slack’s send_message targets that specific channel.
Rules also have a target (see Target scope) that decides who the rule applies to: everyone in the org, a permission group, a single user, or a specific Gummie.

​
Building a rule with the AI rule builder

Clicking + App Rule opens a prompt to choose which app the rule is for, and then takes you into the rule builder. The left panel is a chat with the Gumstack Assistant, and the right panel shows the live rule configuration and simulation results.
Rule builder: left side is a chat with the Gumstack Assistant describing the rule, right side shows the generated Rule Configuration JSON and a Simulation tab listing recent Send Message tool calls with verdicts
1

Describe the rule in plain English

For example: “Do not allow users to send messages in the general channel. Channel ID: C05QG7RF30A.”The assistant will ask for any missing details it needs (channel IDs, tool names, thresholds, etc.). You can @mention tools on the app to pull them directly into the conversation.
2

Review the generated configuration

The top-right panel shows the check_type, action, tool_names, and conditions that the assistant produced. This is what will actually be enforced.
3

Check the simulation

Every time the assistant changes the rule, it re-runs the rule against the most recent tool calls for that app and shows the verdict for each. This lets you confirm it catches what you want (no false negatives) and doesn’t catch anything you didn’t expect (no false positives) before the rule ever goes live.
4

Save

When you’re happy, click Save in the top right. The rule starts enforcing immediately once it’s enabled.
The assistant also accepts follow-ups like “Change this to block before execution instead of tagging after” or “Expand the conditions to cover more edge cases.” You don’t have to edit the JSON by hand.

​
Suggested prompts

If you aren’t sure where to start, the builder offers prompts like:
  • Help me create a new rule for this server
  • What types of rules can I create?
  • Show me examples of common security rules
  • Help me set up a rule to block sensitive operations
  • Explain how MCP rules work

​
Active rules

Rules appear under their app in the Rules by Server list. Each entry shows the rule name and description, a toggle to enable or disable it, and click-through to the rule’s detail page.
Rules by Server panel for Slack showing a rule named Block Messages to Restricted Slack Channel with a description and an enabled toggle

​
Editing a rule

Opening a rule takes you back into the rule builder. The right panel has three tabs:
  • Simulation — re-runs the rule against recent tool calls so you can see the impact of any in-flight edit before saving.
  • Activity — shows the actual tool calls this rule has evaluated since it was enabled, with their verdict (allowed, tagged, or blocked), the user who made the call, and where the call came from.
  • Settings — the read-only/edit panel shown below.
Rule Settings tab showing the editable Name and Description, an Enabled toggle, Created by/Created/Last updated metadata, and a destructive Delete Rule button
On the Settings tab you can:
  • Rename the rule or change its description (changes save on blur).
  • Toggle Enabled on or off.
  • See who created the rule, when it was created, and when it was last updated.
  • Delete the rule (this cannot be undone).

​
Enforcement activity

Every evaluated tool call is recorded so you can audit what the rule has been doing. You can view it in two places:
  • The App Rules tab at the top of the App Policies page shows enforcement across every rule in the organization, with stat cards and a histogram.
  • The Activity tab inside a specific rule shows only that rule’s history.
Tool calls appear with one of three statuses:
  • Allowed — the call ran normally and no rule matched it.
  • Tagged — the call ran, but one or more tag-action rules matched it. The matched rule names are shown in the Rule column.
  • Blocked — a block-action rule matched and the call was denied.
You can click any tool call to expand it and inspect the arguments and output.

​
What end users see

When a rule blocks a tool call, the call fails with an error explaining that the action was blocked by an organization policy. The user doesn’t see the rule’s name, its condition, or which field tripped it — only that the action was denied. Admins can see the full context in the rule’s Activity tab.