Policies
Policies are operational controls that govern how communication happens between connected entities. While guardrails focus on content, policies focus on mechanics: rate limits, geographic restrictions, volume caps, and time-based access.
Available policy types
Rate limiting
Control the number of requests per time window for a connection.
- Per-minute limits: Prevent burst traffic from overwhelming a server
- Per-hour limits: Cap sustained usage over longer periods
- Per-day limits: Set daily usage quotas
Rate limits are applied per connection. Different callers can have different limits to the same server.
Geographic restrictions
Restrict connections based on the geographic origin of requests.
- Allow list: Only accept requests from specified regions
- Block list: Block requests from specified regions
This is useful for compliance with data residency requirements or for limiting exposure to specific markets.
Volume caps
Set absolute limits on the total number of requests over a period.
- Daily volume: Maximum requests per 24-hour period
- Monthly volume: Maximum requests per billing cycle
When a volume cap is reached, subsequent requests are rejected until the next period.
Time-based access
Restrict when connections are active.
- Business hours: Only allow requests during specified hours (e.g., 9 AM to 6 PM UTC)
- Maintenance windows: Temporarily disable connections during planned maintenance
- Scheduled access: Allow connections only on specific days of the week
IP allowlists
Restrict connections to requests originating from known IP addresses or CIDR ranges.
- Specify individual IPs or IP ranges
- Requests from unlisted IPs are rejected
Configuring policies
Policies are set per connection, per direction, similar to guardrails:
Client-side policies
- Outgoing requests: Rate limits on how often the client can call the server
- Incoming responses: Can cap response frequency from the server
Server-side policies
- Incoming requests: Rate limits and access controls on what the server accepts
- Outgoing responses: Volume caps on data returned
Policy evaluation
When a request arrives, all configured policy controls are evaluated. Each active control — IP allowlist, geographic restriction, time-based access, rate limit, and volume cap — is checked, and the request is rejected if any check fails. Content guardrails are also applied as part of the overall evaluation.
Evaluation is fail-closed and deterministic: there is no "advisory" mode where a request over its rate limit proceeds with a warning. The rejected request receives an explicit denial, the denial is recorded, and the caller can retry when the constraint clears (the next time window, an allowed region, an in-schedule hour). Because policies live on the connection, they can be tightened during an incident without touching credentials or code — reducing a rate limit or narrowing an IP allowlist takes effect on the next request.
Policies and cost control
Rate limits and volume caps bound how often an entity can call; for entities that spend money — agents calling paid model APIs — the platform's budget layer bounds how much. Budget policies define spend caps per scope with enforcement that reserves estimated cost before work is dispatched, and spend alert rules notify on thresholds and unusual patterns. The two layers complement each other: a rate limit stops a fast loop in seconds, a budget cap stops a slow-but-expensive drift over days. Connection policies are the right first line because they are cheapest to evaluate and narrowest to scope; budgets are the financial backstop behind them.
Choosing sensible defaults
Three practical calibration rules. Rate limits: set them from observed traffic plus headroom (2–3x the honest peak), not from guesses — a limit nobody ever hits is decoration, and one set too tight trains people to raise limits reflexively. Geographic and IP restrictions: use them where the legitimate caller set is genuinely known (internal services, fixed infrastructure), and prefer allowlists to blocklists — the failure mode of an allowlist is a support ticket, the failure mode of a blocklist is a breach. Time-based access: best for entities with well-defined operating windows — a batch agent that should only run overnight, a maintenance window where a connection should be quiet. Any request outside the expected window is then a signal, not just a rejection.
Policies vs guardrails
Use policies for operational boundaries and guardrails for content control. Together, they provide comprehensive security:
- Policies prevent abuse at the infrastructure level (DDoS, runaway loops, unauthorized regions)
- Guardrails prevent misuse at the content level (data leakage, prohibited actions, sensitive information)
Common questions
What happens when a request violates a policy? It is rejected with an explicit denial and the rejection is recorded against the connection. Nothing proceeds "with a warning" — policy evaluation is fail-closed. The caller can retry when the constraint clears: the next rate-limit window, an allowed region, an in-schedule hour.
Can different clients have different limits on the same server? Yes — policies attach to the connection, not the server, so each client relationship carries its own rate limits, caps, and restrictions. This is how one MCP server safely serves both a high-volume internal application and a tightly limited experimental agent.
How do rate limits relate to budgets? Rate limits bound frequency; budgets bound spend. A fast loop is stopped by the rate limit within seconds; a slow accumulation of expensive calls is stopped by the budget cap. Production deployments of paying entities want both — the rate limit as the fast reflex, the budget as the financial backstop.
Can I change policies during an incident without redeploying? Yes — that is the design point. Policies are enforced by the platform at request time, so tightening a rate limit, narrowing an allowlist, or disabling a connection takes effect on the next request, with no credential rotation or service restart involved.