How rules apply to MCP tool calls
The order in which access rules, usage limits and redaction check each MCP tool call, and how labels help
Several kinds of rules can touch one MCP tool call: an access rule, a usage limit, and a data protection filter. When a call is blocked, slowed, or comes back redacted, knowing which runs when tells you which rule to change.
The order of checks
- The gateway authenticates the agent and resolves the person it acts for.
- Agent Access rules decide the call. Active rules run top to bottom, and the first rule that matches decides: allow, deny, or require approval when approvals are turned on. A call that matches no rule is denied.
- Usage Limits count the call when the gateway forwards it to the MCP server, and refuse it once the budget is spent. A call an access rule denied never reaches this step, so it costs no budget.
- The gateway forwards the call with the person's own connection, or the shared credential an admin set for the server.
- Data Protection filters rewrite the response before the agent reads it. A filter never allows or blocks a call; it only changes what comes back.
- Agent Trail records the call and its decision, and for a blocked call, the rule that blocked it.
Labels let one rule cover many tools
Writing a rule per tool doesn't scale once you add a few servers. Labels group tools, servers and agents, and a rule can match a label instead of naming each tool.
- Built-in labels are applied for you.
Every catalog tool carries one of
read-only,write, ordestructive, plusexternalwhen it reaches outside your organization. For a tool on a custom server, SecureAuth assigns them from the tool's own MCP annotations when it first discovers the tool. See Tool labels. - Your own labels mark what matters to you, such as
financeon the servers that move money, orprodon the ones that touch production.
For example, one deny rule that matches the destructive label in its Tools pill stops every agent from deleting or overwriting data on every catalog server, including ones you add later, and on custom servers whose tools declare it or that you label yourself.
Where to set each one
| To | Use | In the console |
|---|---|---|
| Allow or deny a tool, server or label | Agent Access | Controls › Agent Access |
| Cap how many calls an agent, user or tool can make | Usage Limits | Controls › Usage Limits |
| Redact sensitive data from responses | Data Protection | Controls › Data Protection |
| Group tools so one rule covers them | Tool labels | Inventory › Labels |
Next steps
You now know which rule checks an MCP tool call at each step, and how labels let one rule cover many tools. Next, write the access rule that decides which tools each agent can call.
- Control MCP tool access – allow or deny tools by server, tool and label
- Labels – built-in labels, your own labels, and how rules match them
- Rug pull (tool changes) – the MCP Security side: catch a server changing its tools after you allowed them