Skip to main content
App Policies let organization admins put guardrails around every third-party app that runs through Gumloop. You can block risky tool calls, require corporate email domains when people connect their accounts, and claim a specific provider workspace (a Slack workspace, Salesforce org, Notion workspace, etc.) for your organization.
App Policies page showing the App Rules tab with enforcement stats, an activity histogram, and a list of rules grouped by server

​
Where to find it

Go to Settings → Organization → App Policies at gumloop.com/settings/organization/app-policies. The page has three tabs that map to the three policy types:

App Rules

Block or tag specific tool calls before or after they run.

Domain Restrictions

Require new OAuth connections to use a corporate email domain.

App Claims

Claim a provider workspace so only your org members can connect to it.

​
Who can use it

App Policies is an Enterprise feature, and the page is only visible to organization admins. Everyone else in your workspace will not see it in settings.

​
How it works end-to-end

At a high level, App Policies hook into three different moments:
MomentPolicy type that firesWhat Gumloop checks
A user connects a new OAuth accountDomain RestrictionsDoes the user’s email domain match the allowlist for this app?
A user connects a new OAuth accountApp ClaimsIs this provider workspace claimed by a different organization?
An agent or pipeline invokes a toolApp Rules (phase before)Does any enabled rule for this app and tool say “block”?
A tool call finishesApp Rules (phase after)Does any enabled rule want to block or tag based on the output?
All three policy types live behind the same page, share the same target model (see Target scope below), and follow the same fail-closed rule: if Gumloop cannot evaluate a policy cleanly, the request is treated as blocked.

​
Evaluation pipeline for a tool call

When any tool call runs inside Gumloop (from an agent, a pipeline operator, a user chatting with a Gummie, or a Gumstack-hosted MCP server), the platform calls an internal check_rules step both before the tool executes and again after the result comes back. That check walks every enabled App Rule for the organization in priority order and applies these steps per rule:
1

Phase match

Skip the rule unless its check_type matches the current phase (before vs. after).
2

Target match

Skip the rule unless its target matches the caller. The target can be the whole organization, a permission group the user is in, a specific user, or a specific Gummie (for App Rules, Gummie targets are supported).
3

Scope match

Skip the rule if its scope restricts it to specific tool names and the current tool isn’t in that list.
4

Condition match

Evaluate the rule’s CEL condition against the call context (see the next section for what’s available). If the expression returns false, skip the rule. If the expression errors, treat it as a match (fail-closed).
5

Apply the action

  • tag: record the rule name against this tool call and keep evaluating the remaining rules.
  • block: stop evaluation immediately and return a blocked decision. The tool call is denied with the reason “This action has been restricted by your organization’s security policy.”
If no rule matches, the call is allowed and any accumulated tags are attached to it. Every evaluation (allowed, tagged, or blocked) is recorded and shows up in the Enforcement Activity histogram and the per-rule Activity tab.

​
How natural language maps to code

You don’t have to write CEL or JSON by hand. The AI rule builder on the App Rules tab takes a plain-English description of what you want and produces a structured rule with:
  • check_type — "before" (pre-flight) or "after" (post-flight). “Stop people from sending …” becomes "before"; “Flag calls that returned sensitive fields” becomes "after".
  • action — "block" or "tag". “Don’t allow …” becomes "block"; “Just monitor …” becomes "tag".
  • tool_names — specific tools on the app the rule applies to, if the prompt named any (e.g. “sending messages” on Slack becomes ["send_message"]). Omitted means “any tool on this app”.
  • conditions — a CEL expression evaluated with these variables:
    • args — the arguments passed to the tool (e.g. args.channel, args.query, args.to).
    • tool_name — the tool the caller invoked.
    • server_id — the app the tool belongs to.
    • output — the tool’s return value (available only on after rules).
For example, “Do not allow users to send messages in the #general channel (ID C05QG7RF30A)” compiles to: 
{
  "check_type": "before",
  "action": "block",
  "tool_names": ["send_message"],
  "conditions": "args.channel == \"C05QG7RF30A\""
}
Every time you edit the prompt, the builder re-renders this JSON and re-runs it against the most recent real tool calls on that app, so you can see exactly which past calls the rule would have caught before you save it. See App Rules for the full flow.

​
How agents and pipelines see a policy decision

Policies are enforced inside Gumloop — an agent or pipeline can’t bypass them from its own runtime. Here’s what each side sees:
  • Allowed: the tool runs normally and returns its result. The caller has no idea a check happened.
  • Tagged: the tool still runs and returns its result normally. The tags show up in audit views and in the Activity tab of each tagging rule, but they don’t change what the caller sees.
  • Blocked: the tool doesn’t run. The caller (agent, Gummie, or pipeline operator) receives an error carrying the reason “This action has been restricted by your organization’s security policy.” Gummies handle this the same way they handle any other tool error — they surface the failure in the conversation and can decide whether to try a different tool, ask the user for clarification, or abort the task. Pipeline operators fail their step with the same message.
End users never see which rule blocked them, just that the action was denied. Admins can see the full context — including the rule name, the matched condition, and the arguments — in the rule’s Activity tab.

​
Target scope

Every policy is created against a target that decides who the policy applies to. From most to least broad:
TargetApplies to
OrganizationEveryone in your organization (the default)
Permission groupMembers of a specific permission group
UserA single user
GummieA single AI agent (App Rules only)
The target is set when the policy is created. Org-wide policies cover all users in your workspace; more-specific policies layer on top of them.

​
Enabled vs. disabled

Every policy has an Enabled toggle. Only enabled policies are enforced. Disabling a policy pauses it without deleting it, so you can re-enable it later without re-doing the configuration.

​
Fail-closed by default

If Gumloop can’t evaluate a policy for any reason — a CEL expression errors out, a scope check fails, an unknown action shows up — the request is denied, not allowed. This keeps a misconfigured policy from silently letting traffic through. The evaluation errors are still attached to the call so admins can see what went wrong.

​
What end users see when a policy blocks them

  • App Rules: the tool call fails with the fixed message “This action has been restricted by your organization’s security policy.” The agent or pipeline sees the same error and stops that step.
  • Domain Restrictions: if someone tries to connect an account whose email domain isn’t on the allowlist, the OAuth flow ends with an error explaining which domain is required.
  • App Claims: if someone outside your organization tries to connect to a provider workspace you’ve claimed, their connection is rejected with a message saying the workspace is claimed by another organization.
Only admins see which specific policy blocked a call. End users only see the fact that it was blocked.

Custom User Roles

Grant granular permissions to non-admin users.

Audit Logs

Track every policy create, update, enable/disable, and enforcement event.