Rules

Documentation Index

Fetch the complete documentation index at: https://onecli.sh/docs/llms.txt

Use this file to discover all available pages before exploring further.

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:

​

Require approval before sending emails

Require human sign-off before any agent sends a Gmail message: When an agent tries to send an email, the gateway holds the request and waits for someone to approve or deny it. The request body (the email content) is available in the approval metadata, so the reviewer can see exactly what the agent is trying to send.

​

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 in priority order: Block > Manual Approval > Rate Limit
3. If blocked → 403. If rate-limited → 429. If manual approval → held until approved or denied.
4. Credentials are matched by host and path
5. Credentials are injected and the request is forwarded

​

Manual Approval

Manual Approval lets a human review and approve or deny agent requests before they reach the external service. When a request matches a manual approval rule, the gateway holds the agent’s connection open (up to 5 minutes) while it waits for a decision.

​

How it works

1. An agent makes a request that matches a manual approval rule
2. The gateway holds the request. The agent’s HTTP connection stays open, waiting for a response.
3. Your application polls the gateway for pending approvals via the Node.js SDK
4. A human reviews the request details (method, URL, headers, body preview) and approves or denies
5. The gateway either forwards the request to the upstream service (approve) or returns a 403 (deny)

If nobody responds within 5 minutes, the request is automatically denied.

​

What the reviewer sees

The approval metadata includes:

• Method and URL: what the agent is trying to do (e.g., POST https://gmail.googleapis.com/.../send)
• Headers: sanitized request headers (credentials are stripped)
• Body preview: the first 4KB of the request body, so reviewers can see the actual content (e.g., the email being sent)
• Agent identity: which agent made the request

​

Integrating with the SDK

Manual approval requires an application that polls for pending approvals and submits decisions. The Node.js SDK provides configureManualApproval() for this. See the SDK docs for the full integration guide.

​

Coming soon

• Monitor action: Log matching requests without blocking, useful for auditing before enforcing
• Time-bound access: Grant access only during specific time windows
• Organization-level rules: Set outer boundaries that individual users can’t override