Policies
Policies are the core of Igris governance. Each policy contains an ordered list of rules that are evaluated against incoming tool calls. The first matching rule determines the action.
Concepts
A policy is attached to a specific MCP server and contains:
- Name — human-readable label
- Server ID — which server this policy applies to
- Rules — ordered list of pattern/action pairs
- Active — whether the policy is enabled
A rule specifies:
- Tool pattern — a glob pattern matched against the tool name
- Action — what to do when the pattern matches:
allow, deny, or alert
- Rate limit (optional) — maximum calls per time window
Glob Patterns
Rules use glob-style patterns to match tool names:
| Pattern | Matches |
|---|
* | Everything (catch-all) |
delete_* | delete_user, delete_record, delete_all |
*_sensitive | read_sensitive, export_sensitive |
db_* | db_query, db_insert, db_delete |
read_user | Exact match: only read_user |
Rule Evaluation: First Match Wins
Rules are evaluated top to bottom. The first rule whose pattern matches the tool name determines the action. Remaining rules are skipped.
{
"rules": [
{ "tool": "delete_*", "action": "deny" },
{ "tool": "drop_*", "action": "deny" },
{ "tool": "write_*", "action": "alert" },
{ "tool": "*", "action": "allow" }
]
}
delete_users → denied (matches rule 1)drop_table → denied (matches rule 2)write_record → allowed + alert sent (matches rule 3)read_data → allowed (matches catch-all rule 4)
If no rule matches, the tool call is denied by default. Always include a catch-all * rule at the end if you want a default-allow posture.
Actions
Allow
The tool call is forwarded to the upstream MCP server. An audit event is logged.
Deny
The tool call is blocked. The client receives an error response. An audit event is logged with the denial reason.
Alert
The tool call is forwarded to the upstream server (same as allow), but an additional anomaly event is emitted via SSE and logged. Use this for tool calls you want to monitor without blocking.
Rate Limits
Add rate limits to any rule to restrict call frequency:
{
"tool": "query_*",
"action": "allow",
"rateLimit": {
"max": 100,
"window": "1m"
}
}
1m, 5m, 15m, 1h, 1d.
When the rate limit is exceeded, the tool call is denied regardless of the action. Rate counters are tracked per organization in Redis using sliding windows.
Creating Policies
- Go to Governance → Policies
- Click Create Policy
- Select the target server
- Add rules in priority order
- Save
Policy Caching
Active policies are cached in Redis with a TTL. When you update a policy, the cache is invalidated immediately. On cache miss, policies are loaded from the database and re-cached.
This ensures low-latency policy evaluation on the proxy path while keeping changes responsive.
Best Practices
- Start restrictive — begin with deny-all, then add specific allows as needed.
- Use alert for new tools — when a new MCP tool appears, set it to alert before deciding on allow/deny.
- Group by risk — create separate policies for different risk levels (e.g., read-only vs. write operations).
- Use rate limits on expensive operations — protect against runaway agents with rate limits on write and delete operations.
- Review audit events — regularly check denied and alerted calls to refine your policies.
