Documentation Index
Fetch the complete documentation index at: https://docs.igrisecurity.com/llms.txt
Use this file to discover all available pages before exploring further.
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 connection and contains:
- Name — human-readable label
- Connection — which connection (connection) this policy applies to
- Rules — ordered list of pattern/action/condition tuples
- 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
- Conditions (optional) — attribute-based conditions on user identity or metadata
- 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.
Conditions (Attribute-Based Access Control)
Rules can include conditions that match against user identity and request metadata. A rule with conditions only applies when all conditions are met.
Example: Block destructive ops for interns
{
"rules": [
{ "tool": "delete_*", "action": "deny", "conditions": { "metadata.role": "intern" } },
{ "tool": "drop_*", "action": "deny", "conditions": { "metadata.role": "intern" } },
{ "tool": "*", "action": "allow" }
]
}
delete_* and drop_* calls only when metadata.role is "intern". Admins and developers can still use these tools.
Condition Fields
Conditions can reference:
| Field | Source | Example |
|---|
user | X-Igris-User header | "user": "alice@company.com" |
metadata.* | X-Igris-Metadata header | "metadata.role": "admin" |
Condition Operators
| Operator | Example | Meaning |
|---|
| String (shorthand) | "metadata.role": "intern" | Equals “intern” |
eq | "metadata.role": { "eq": "intern" } | Equals “intern” |
neq | "metadata.role": { "neq": "admin" } | Not equals “admin” |
in | "metadata.role": { "in": ["dev", "admin"] } | Value in list |
nin | "metadata.role": { "nin": ["intern"] } | Value not in list |
Missing Fields
If a condition references a field that isn’t present in the request (e.g., the SDK didn’t pass metadata.role), the rule is skipped — it does not deny or allow. Evaluation continues to the next rule.
Pass user identity and metadata via the SDK’s connectHttp() options. See Identity & Metadata for details. 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 connection
- Add rules in priority order (with optional conditions)
- 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.
