Rules

Rules let you define policies that control what your agents are allowed to do. Instead of giving an agent unrestricted access to every service it has credentials for, you can set boundaries: block certain operations entirely, or rate-limit them so damage is contained.

​

Why rules matter

Credentials get an agent through the door. Rules decide what it can do once inside. Without rules, an agent with Gmail credentials can read, send, and delete emails with no limit. That’s useful, but it’s also how you get an agent mass-deleting an inbox before anyone can stop it. Rules let you say things like “this agent can access Gmail, but it can only delete 3 messages per hour.”

​

Deterministic enforcement, not prompts

You can tell an agent “never delete emails without my approval” in a system prompt. But a prompt is a suggestion, not a guarantee. Agents are non-deterministic. They can be manipulated through prompt injection, they can misinterpret instructions, or they can simply be too eager to please and take actions you didn’t intend. Writing “please don’t do that” in a prompt gives you no certainty that it won’t happen. Rules are different. They’re enforced outside the agent, at the gateway level, before the request ever reaches the external service. No amount of prompt manipulation, jailbreaking, or overly helpful behavior can bypass a rule. If a rule says “block DELETE requests to Gmail,” that request is blocked. Every time, deterministically, regardless of what the agent was told or tricked into doing. This is the difference: rules move security boundaries from a place the agent controls (its own context) to a place it can’t touch (the proxy layer). That’s what makes them a real safety mechanism instead of a best-effort instruction.

​

Creating a rule

From the dashboard, go to Rules and click + New Rule. A rule has two parts:

​

Step 1: Endpoint

Define which requests the rule applies to.

​

Step 2: Action

Choose what happens when a request matches.

​

Rate limit options

When you select Rate Limit, you configure:

• Request count: How many requests to allow (e.g., 20)
• Time window: The period over which the count resets (minute, hour, day)

Each agent has its own counter. If you set 20 requests per hour, each agent gets its own 20.

​

Examples

​

Block all email deletions

A rule that prevents any agent from deleting Gmail messages:

​

Rate-limit Slack messages

Allow agents to post to Slack, but cap it at 10 messages per hour:

​

Block a specific agent from accessing a service

Prevent your “research-agent” from touching your GitHub repos:

​

How rules interact with credentials

Rules and credentials are independent. An agent needs matching credentials to authenticate with a service, and rules add a policy layer on top. If an agent has Gmail credentials but a rule blocks DELETE requests to Gmail, the request is blocked before credentials are ever injected. The evaluation order is:

1. Request comes in from the agent
2. Rules are checked. If a rule blocks or rate-limits the request, it’s denied immediately
3. Credentials are matched by host and path
4. Credentials are injected and the request is forwarded

​

Coming soon

• Monitor action: Log matching requests without blocking, useful for auditing before enforcing
• Approval action: Pause the request and send a notification for human approval
• Time-bound access: Grant access only during specific time windows
• Organization-level rules: Set outer boundaries that individual users can’t override