Your AI agents, your rules

Your agents are connected to your company's most important tools: Salesforce, BigQuery, Gmail, HubSpot. With App Policies, you can set organization-wide constraints on what any agent is allowed to do with those tools, and describe those constraints in natural language. Like:

• Don't let any agent send emails outside of @examplecompany.com and @examplecontractors.com
• Block Salesforce account deletions if the account has an active owner
• Don't allow “delete” queries in BigQuery

Write your rule in plain English, and Gumloop converts it into an enforceable policy that will run on every tool call, across every agent in your organization. If an agent tries to do something that would violate a policy, the action is blocked and the user will see exactly what policy stopped it (and why). This means you can give your agents broad capabilities while also maintaining the exact level of control your team needs.

Different guardrails for different agents

Different agents and teams need different levels of access to tools. A sales agent might be allowed to send external emails but blocked from modifying billing records. An internal ops agent might have broad database access but no ability to send messages externally.

To ensure every agent gets exactly the capabilities it needs and nothing more, policies can live at the organization, team, or agent level. Org-level policies apply across every agent in an organization, while team- and agent-level policies add further specificity.

How policies work

To create a policy, describe the constraint you want to apply, and Gumloop's AI will translate it into lightweight enforcement logic that evaluates every outgoing MCP tool call in real time. When an agent attempts to take an action that matches a policy, the policy can either block or tag the tool call.

When a policy blocks an action:

• The action is stopped before it reaches the external tool
• The user who triggered it sees the name and description of the policy that blocked them
• The blocked attempt is logged for audit

If an action is tagged, the action still runs, but the tool call is logged for audit in the admin panel. Tagging is useful for monitoring or auditing existing workflows, or testing out a policy before committing to a full block. 

You can also test any policy against historical tool calls before activating it, so you can see exactly what would have been blocked, without affecting anything in production.

What you can control

If an agent can call it, you can write a policy for it. Anything your agents do through any of Gumloop's 100+ connected apps can be governed:

• Data operations: Block destructive queries, restrict write access to specific tables or databases
• CRM actions: Prevent deletions or modifications to records that meet certain criteria
• Communications: Restrict which domains agents can email, or which Slack channels they can post to
• File operations: Control what agents can create, modify, or share
• Scheduling: Control when and how agents create or modify calendar events

Under the hood

Policies are defined in natural language but enforced as generated logic (like regex patterns and conditional checks) that can evaluate at scale without adding latency to tool calls.

This is a deliberate architectural choice so that policies can't be prompt-engineered around: policies are hard constraints enforced at the infrastructure level. No agent can talk its way past a policy, regardless of what model it's running or what its instructions say.

App Policies are available now for Enterprise organizations using Gumstack. Gumstack is a complete AI observability platform that allows security teams to monitor and control data use across all their organizations' AI agents, both on and off Gumloop.

For more detailed information on App Policies, check out our support documentation.