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 for review. Each rule is a lightweight policy with a phase, an action, a scope, and a CEL condition that Gumloop evaluates automatically every time a tool call runs.

Organization Rules

Apply to every user and agent in your org. Manage at App Policies settings.

Agent Rules

Apply to a specific agent’s tool calls only. Manage via agent config or agent chat.

​
Rule Scopes

Organization-level rules are the default. They apply to every user and agent in your organization.

​
Where to find it

Go to Settings → Organization → App Policies at gumloop.com/settings/organization/app-policies and open the App Rules tab.
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 see

  • 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 with its rules listed. Toggle each rule on or off from here
  • + App Rule button to create a new rule

​
Creating a rule

Click + App Rule, pick the app, and the AI rule builder opens (see Building a rule below). The rule is scoped to the entire organization by default.

​
Active rules

Rules appear under their app in the Rules by Server list with a name, description, and toggle.
Rules by Server panel for Slack showing a rule named Block Messages to Restricted Slack Channel with a description and an enabled toggle

​
What users see when blocked

The tool call fails with: “This action has been restricted by your organization’s security policy.”The user doesn’t see the rule’s name, its condition, or which field tripped it. Admins can see the full context in the rule’s Activity tab.

​
How a Rule Works

Every 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.
2

Action

Pick block to deny the call, or tag to let it through while labeling it with your rule’s name for later review.
3

Scope

Limit the rule to specific tool names on the app (e.g. only send_message in Slack, or only create_event in Google Calendar). Leave empty to apply 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.

​
Building a Rule with the AI Rule Builder

Clicking + App Rule (from either scope) opens the rule builder. The left panel is a chat with the AI assistant, and the right panel shows the live rule configuration and simulation results.
Rule builder: left side is a chat with the AI assistant, right side shows the generated Rule Configuration JSON and a Simulation tab
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. You can @mention tools on the app to pull them into the conversation.
2

Review the generated configuration

The top-right panel shows the check_type, action, tool_names, and conditions the assistant produced.
3

Check the simulation

Every time the assistant changes the rule, it re-runs it against recent tool calls and shows the verdict for each. Confirm it catches what you want (no false negatives) and doesn’t catch anything unexpected (no false positives).
4

Save

Click Save in the top right. The rule starts enforcing immediately once 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.
  • 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

​
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 edit before saving.

Activity

Shows actual tool calls this rule has evaluated, with verdicts (allowed, tagged, blocked), the user, and the call source.

Settings

Rename, toggle enabled/disabled, view metadata, or delete the rule.
Rule Settings tab showing Name, Description, Enabled toggle, metadata, and 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, and last updated
  • Delete the rule (cannot be undone)

​
Enforcement Activity

Every evaluated tool call is recorded for auditing. You can view activity in two places:
  • App Rules tab at the top of the App Policies page: enforcement across every rule in the org, with stat cards and a histogram
  • Activity tab inside a specific rule: only that rule’s history
Tool calls appear with one of three statuses:
StatusMeaning
AllowedThe call ran normally, no rule matched.
TaggedThe call ran, but one or more tag-action rules matched. Matched rule names shown in the Rule column.
BlockedA block-action rule matched and the call was denied.
You can click any tool call to expand it and inspect the arguments and output.

​
How Overlapping Rules Interact

Rules at different scopes stack. When a tool call is evaluated, Gumloop checks all enabled rules across every scope that matches the caller:
  • An organization-wide rule is always checked for every caller
  • An agent-scoped rule is checked only if the caller is that specific agent
If any matching rule has action block and its condition fires, the call is blocked, regardless of what other rules say. There is no “allow” override.
Think of it as layering: organization rules set the baseline, and agent rules add agent-specific restrictions. Each layer can only make things more restrictive, never less.

​
App Rules & Human in the Loop

App Rules are one part of a broader Human in the Loop system that keeps humans in control of AI agent actions. While App Rules use CEL conditions to automatically block or tag tool calls, the approval system gives you the option to pause and ask before a tool call executes.

​
How they work together

App Rules and approval settings operate at different layers but complement each other:
LayerWhat it doesExample
Approval SettingsSimple toggles: always allow, ask each time, ask for writes/deletes, or custom per-tool. Based on the tool’s risk category.”Ask me before any Gmail write operation.”
App RulesConditional CEL-based policies that evaluate tool call arguments at runtime. Can block or tag.”Block emails to external domains” or “Tag any Slack message to #general.”
Both layers are evaluated for every tool call. Approval settings act as the baseline, and App Rules add conditional overrides on top. If an App Rule blocks a call, it is denied regardless of approval settings.

​
Using App Rules for conditional approvals

A common pattern is combining “Always allow” approval settings with App Rules that tag specific calls for review. This lets most tool calls flow freely while flagging the ones that match your conditions for later auditing. For example:
  • Set Gmail approval mode to Always allow
  • Create an App Rule that tags any email sent to recipients outside your company domain
  • Your agent sends internal emails without interruption, while external emails are tagged and visible in the enforcement activity view
For more granular approval controls (where the agent pauses and waits for you to approve or reject), see the Human in the Loop documentation.
You can ask your agent to create an App Rule in natural language. For instance: “Create a human approval rule for any email sent to users without the gumloop.com domain.”The agent translates this into a CEL condition and shows you a proposal card:
Agent creating an approval rule for non-gumloop.com email recipients via chat, showing the CEL condition
Once approved, the rule appears in the app’s config:
Gmail app configuration showing the Rules section with an active approval rule for external email recipients
When a tool call triggers an approval requirement, the agent pauses and shows an approval card directly in the conversation:
Approval card in the web chat showing an email send request with To, Subject, and Body fields, plus Reject and Approve buttons
You can review the tool name, intent, and arguments, then Approve or Reject. Check “Don’t ask again for this tool” to auto-approve future calls to the same tool.
To set up approval settings, the Ask Human ability, and notification channels for approvals, see the full Human in the Loop guide.

​
FAQ

No. Rules only add restrictions. If an org-wide rule blocks a tool call, an agent rule cannot un-block it. To allow the call, you would need to disable or modify the org-wide rule.
Yes. Agent-scoped rules are evaluated whenever that agent makes a tool call, regardless of whether the agent is running in a direct conversation, through Slack, or inside a pipeline.
Yes. Both block and tag actions are supported at every scope level. Tagged calls show up in the enforcement activity views just like org-wide tagged calls.
Approval settings are simple mode-based controls (always allow, ask each time, ask for writes/deletes, or custom per-tool). They apply based on the tool’s risk category.App Rules are conditional. They use CEL expressions to inspect the actual arguments of a tool call. For example, “only block when the email recipient is outside my domain” is something only App Rules can do. Both systems work together: approval settings set the baseline, App Rules add conditional overrides. See the Human in the Loop guide for the full picture.