Your First Policy

Write an allow/deny rule to control which MCP tools your agent can invoke.

Default behavior: implicit deny

If no policy matches a (agentId, toolName) pair, the request is blocked. You must explicitly allow each tool your agent needs.

How Policies Are Evaluated

Request→Auth→Policy ← here→Security Scan→Rate Limit→Upstream MCP

Only tools/call requests are policy-checked. Other MCP methods (tools/list, resources/read) pass through.

Allow a Tool

Allow your agent to call read_file on any path:

bash

curl -X POST https://api.shieldagent.io/policies \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <admin-key>' \
  -d '{
    "tenantId": "<tenant-id>",
    "agentId": "<agent-id>",
    "toolName": "read_file",
    "action": "allow"
  }'

Deny with a Condition

Block bash calls that contain rm -rf:

policy — bash rm-rf block

{
  "tenantId": "<tenant-id>",
  "agentId": "<agent-id>",
  "toolName": "bash",
  "action": "deny",
  "conditions": [
    {
      "type": "param_contains",
      "param": "arguments.command",
      "value": "rm -rf"
    }
  ]
}

All conditions use AND logic — every condition must match for the rule to apply. If a condition fails, the evaluator moves to the next rule.

Tenant-Wide Policy

Set agentId to null to apply the rule to every agent in the tenant. Agent-specific rules always win over tenant-wide rules.

policy — tenant-wide allow

{
  "tenantId": "<tenant-id>",
  "agentId": null,
  "toolName": "tools_list",
  "action": "allow"
}

Policy Actions

Action	Behavior
allow	Permit the tool call (subject to conditions)
deny	Block the tool call and return an error to the agent
shadow	Log the call without blocking; useful for observing new tools before enforcing

Next Steps

Security Policies Example

Layered rules for injection, DLP, drift detection

Integrating Agents