Policies
Policies are operational controls that govern how communication happens between connected entities. While guardrails focus on content, policies focus on mechanics: rate limits, time-based access, a monthly spend cap, approval before a task runs, and which task types, models and tools a connection may carry.
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
Rate limits are applied per connection. Different callers can have different limits to the same server. There is no per-day limit or total-volume cap: the hourly limit bounds sustained use, and the monthly spend cap bounds cost.
Spend caps
Bound what a connection may spend.
- Monthly spend cap: once the connection's spend in the current calendar month (UTC) reaches the cap, new tasks on that connection are refused until the next month
- Cost per request: a task that needs approval is checked when it is approved, before it runs, against an estimate from the receiving agent's pricing, and is refused if the estimate is over the cap. Every task's settled cost is checked again when it completes; the work has already run by then, so an over-limit task is recorded, not stopped
Time-based access
Restrict when a connection accepts tasks. Each connection has one recurring window, set in whole hours in UTC with optional days of the week, and the window can run past midnight (for example 22:00 to 06:00).
- Business hours: Only allow requests during specified hours (e.g., 9 AM to 6 PM UTC)
- Scheduled access: Allow connections only on specific days of the week
A task dispatched outside the window is refused. There is no one-off maintenance window that switches a connection off for a planned period.
IP allowlists
Restrict requests to the Praesidia API to known IP addresses or CIDR ranges. An IP allowlist is not set per connection: it applies to the whole organization or is narrowed to particular routes or roles, and a service-account key can carry its own list.
- Specify individual IPs or CIDR ranges
- Requests from unlisted IPs are rejected
Geography and data residency
Praesidia does not filter requests by geographic origin: no policy reads the country or region a request comes from. Two controls cover the neighbouring needs, and neither is set per connection:
- Where requests may come from: an IP allowlist (above) limits the networks that can reach the Praesidia API.
- Which deployment serves your organization: data residency. Each organization is assigned one residency region (EU, US or AP) when its account is created. Any deployment whose region differs from the organization's refuses that organization's API requests; requests that carry no organization, and the model gateway's own calls, are not checked against the region. See deployment and the trust center for hosting; which regions are available is discussed during evaluation.
Configuring policies
Each connection carries one policy, set on the connection itself and checked when a task is dispatched over it. A connection runs one way, from the calling agent to the agent it calls, so when two agents call each other, each direction is a separate connection with its own policy (see connections). There are no separate client-side and server-side policies.
The policy governs tasks between agents. It does not apply to MCP tool calls, which are limited per tool on the MCP server instead (a number of calls per minute, counted across all callers of that tool).
Most of the policy is checked before the receiving agent runs the task: the rate limits, the time window, the monthly spend cap, approval, and the allowed task types, models and tools. The maximum response size is checked only after the work has run, so a breach is recorded as a policy decision rather than blocked. The cost per request is checked at both points: a task that needs approval is refused before it runs if its estimated cost is over the cap, and every task's settled cost is checked when it completes, where a breach is recorded rather than blocked.
Policy evaluation
When a task is dispatched over a connection, all configured policy controls are evaluated. Each active control — allowed task types, rate limits, the time window, the monthly spend cap, and allowed models and tools — is checked, and the task is rejected if any check fails. An IP allowlist is checked earlier, when the request reaches the Praesidia API. 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 rate-limit window, an in-schedule hour, the next month under a spend cap). Because policies live on the connection, they can be tightened during an incident without touching credentials or code — reducing a rate limit or narrowing the allowed tools takes effect on the next task. An IP allowlist is not a connection policy, but narrowing it also needs no credential change.
Policies and cost control
Rate limits 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. IP allowlists: use them where the legitimate caller set is genuinely known (internal services, fixed infrastructure) — 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, or an agent that should act only on weekdays. 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 (runaway loops, request floods, out-of-hours activity)
- Guardrails prevent misuse at the content level (data leakage, prohibited actions, sensitive information)
Common questions
What happens when a request violates a policy? A check made before the task runs (rate limits, the time window, the monthly spend cap, the allowed task types, models and tools, and the estimated cost of an approved task) rejects it with an explicit denial, and the denial is recorded against the connection. The two checks made after the task has run, response size and settled cost per request, cannot stop work that is already done: a breach is recorded rather than blocked, and the result is still returned. After a rejection the caller can retry when the constraint clears: the next rate-limit window, an in-schedule hour or, under a spend cap, the next month.
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 agent safely serves both a high-volume internal agent and a tightly limited experimental one. MCP servers are different: their limits are set per tool, not per caller.
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 a connection's allowed task types, models or tools, or disconnecting the connection takes effect on the next task, with no credential rotation or service restart involved. An IP allowlist is set for the organization or a service-account key rather than on a connection, and narrowing it needs no redeploy either.