Security Controls

Every request that reaches the AI Gateway passes through a series of controls before it is allowed through to your applications or AI providers. Each control answers one question — where is this coming from?, how often?, what is this agent allowed to be told? — and any one of them can stop the request.

Knowing the order matters most when something is blocked and you need to find out which control did it.

Quick Start: What do you want to do?

I want to...	Go to
Restrict which networks can reach a server	Network policies
Limit how often an agent can call something	Rate limiting
Stop an agent rewriting its own instructions	System prompt lock
Work out why a request was blocked	What each control returns (below)
Control what data can leave	Data Governance
Cap what agents can spend	Budgets and AI Spend

---

The order controls run in

Controls run in a fixed order, and the first one to refuse ends the request — nothing after it runs.

Order	Control	Decides
1	Network policy	Whether the caller's network is allowed to reach this server at all
2	Authentication	Whether the caller's credential is valid
3	Authorization	Whether this caller may use this persona, server or tool
4	Rate limiting	Whether the caller has made too many requests
5	Circuit breaker	Whether the upstream application is currently healthy enough to call
6	Content controls	Data Governance, Prompt Guard, the system prompt lock and budgets
7	Upstream call	The request reaches your application or AI provider

Two consequences of this order are worth knowing:

• Network policy runs before authentication. A caller from a blocked network is refused before the gateway looks at who they are. They do not need a valid credential to be blocked, and an invalid one will not change the outcome.
• Content controls run last. Data Governance and the system prompt lock only see requests that already passed network, identity and rate checks, so a request blocked earlier never appears in their findings.

What each control returns

When a request is refused, the status code tells you which control did it.

You see	Which control	What to check
403 with a network policy message	Network policy	The policy assigned to the server, and the caller's address
401	Authentication	The credential the agent is sending
403 on a tool or persona	Authorization	Whether that tool is granted to this persona, and the team it belongs to
429	Rate limiting	The limit on the persona and on the MCP server — both apply
502 or 503	Circuit breaker or upstream	The health of the upstream application
403 naming a budget	Budgets	Budgets and AI Spend
403 about a system prompt	System prompt lock	System prompt lock

Every decision, including the ones that allow a request through, is recorded. See Observability for how to find them.

Where each control is configured

The controls do not all live in the same place, because they protect different things.

Control	Where you set it	Applies to
Network policies	Security Guardrails → Network Policies, then assign on each MCP server	The servers you assign it to, plus a tenant-wide default
Rate limiting (server and per tool)	The MCP server's Risk-based throttling tab	That MCP server
Rate limiting (persona)	The persona's Configuration → Policy → Risk-Based Throttling	That persona
System prompt lock	The persona's Configuration → Policy → System Prompt Lock	Every model call that persona makes

Tips

• Start in monitoring mode where it is offered. The system prompt lock and Data Governance policies both let you watch the effect before anything is refused. Use it — the first run almost always surprises someone.
• When a request is blocked, read the status code first. It narrows the cause to one control before you start looking at configuration.
• Check the tenant default before assuming a server is unprotected. A server with no network policy of its own still falls back to the tenant default policy.
• Controls are independent. Turning off rate limiting does not relax network policy, and a persona passing its own checks still has to pass the MCP server's.