Agentic AI Security Guide / Orchestration & Tool Security

Orchestration & Tool Security

This is where most agentic risk is controlled or allowed through.

7.1 Policy Enforcement in the Orchestrator

Centralized policy engine should enforce:

  • User and agent authentication
  • Authorization:
    • Which agent can act on behalf of which user/tenant?
    • Which tools can be used in this context?
  • Data access rules:
    • Document/row-level filters (tenant_id, region, department)
    • Classification-based constraints
  • Guardrails: Pre-input, mid-execution, and post-output checks
  • Rate limits and quotas: Per-user, per-tenant, per-agent, per-tool

Policies must be code/config, not just English in prompts.

7.2 Tool Design: Atomic, Schema-Constrained, Safe-by-Default

Design tools so they are:

Atomic

Single-purpose, narrow scope (e.g., get_order_status vs run_sql).

Versioned

With documented inputs, outputs, and risk level.

Schema-Constrained

JSON schema for parameters, enforced server-side:

  • Types, ranges, enums
  • Regexes and patterns
  • additionalProperties: false

Bad example:

  • run_python(code: string)
  • http_request(url, headers, body) as general tools

Better example:

  • get_stock_price(ticker: string)
  • create_support_ticket(title, description, priority)

7.3 Tool Invocation Mediation Layer

Never execute raw model output directly.

The model should output structured tool calls, e.g.:

{
  "tool": "send_email",
  "parameters": {
    "to": ["user@internal.domain.com"],
    "subject": "Status update",
    "body": "Here is your update..."
  }
}

A mediation layer must:

  • Validate the tool name against the agent's allowlist.
  • Validate parameters against JSON schema.
  • Apply business logic checks (e.g., sending only to internal domains).
  • Apply rate limits and quotas.
  • Enforce impact-aware behavior:
    • Propose + confirm for medium risk.
    • Breakpoints/human approval for high risk.

7.4 Network and External Integration Controls

Because tools are the "hands" of the agent, you must control where they can reach.

  • Restrict outbound network traffic from:
    • Agent runtimes
    • Tool and MCP servers
  • Allowlist:
    • Internal APIs
    • Specific external domains (with known risk posture)
  • Avoid generic HTTP tools. If unavoidable:
    • Restrict them to specific domains/paths at the infrastructure layer.
    • Add logic to classify and sanitize fetched content before passing to models.

7.5 MCP / Plugin Governance

Treat MCP servers and plugins like microservices:

Require Security Review for Each

  • AuthN and authZ model
  • Data access patterns
  • Network access policies
  • Tool schemas and validation

Maintain a Registry

For each tool/MCP:

  • Owner, environment, risk rating
  • Allowed agents and tenants
  • Data domains touched

Default Deny

Agents cannot use arbitrary MCP servers; they must be explicitly allowlisted per environment.