Orchestration and Tool Security

7.1 Policy Enforcement in the Orchestrator

Your orchestrator needs a centralized policy engine. This is not optional. The policy engine should enforce:

• User and agent authentication - Verify who is making the request and which agent is acting on their behalf.
• Authorization - Which agent can act on behalf of which user or tenant? Which tools can be used in this context?
• Data access rules - Document-level and row-level filters (tenant_id, region, department), plus classification-based constraints.
• Guardrails - Pre-input, mid-execution, and post-output checks.
• Rate limits and quotas - Per-user, per-tenant, per-agent, per-tool.

One critical point: policies must be expressed as code or configuration, not as English instructions inside prompts. A prompt saying "do not access financial records" is a suggestion to the model. A policy engine that blocks the query before it reaches the database is an actual control. There is a difference.

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

The way you design tools determines how much damage a compromised agent can do. Design every tool to be:

• Atomic - Single-purpose, narrow scope. get_order_status is good. run_sql is not.
• Versioned - With documented inputs, outputs, and risk level.
• Schema-constrained - JSON schema for parameters, enforced server-side. Define types, ranges, enums, regexes and patterns, and set additionalProperties: false.

Bad examples: run_python(code: string) or http_request(url, headers, body) as general-purpose tools. These give the agent unlimited reach and make every prompt injection a full compromise.

Better examples: get_stock_price(ticker: string) or create_support_ticket(title, description, priority). These are narrow, predictable, and easy to validate.

7.3 Tool Invocation Mediation Layer

Never execute raw model output directly. The model should output structured tool calls - JSON with a tool name and parameters - and a mediation layer must sit between the model and actual execution.

The mediation layer must:

• Validate the tool name against the agent's allowlist. If the tool is not on the list, reject the call.
• Validate parameters against JSON schema. Reject anything that does not conform.
• Apply business logic checks - For example, if the tool sends email, verify the recipient is an internal domain.
• Apply rate limits and quotas - Prevent runaway agents from hammering downstream services.
• Enforce impact-aware behavior - For medium-risk actions, use a propose-then-confirm pattern. For high-risk actions, require breakpoints or human approval before execution proceeds.

7.4 Network and External Integration Controls

Tools are the "hands" of the agent. You need to control where those hands can reach.

• Restrict outbound network traffic from agent runtimes and tool/MCP servers. Do not let them talk to arbitrary endpoints.
• Maintain an allowlist - Internal APIs and specific external domains with a known risk posture. Everything else is blocked by default.
• Avoid generic HTTP tools. If you absolutely must have one: restrict it to specific domains and paths at the infrastructure layer, and add logic to classify and sanitize fetched content before passing it to the model.

Network controls are your safety net when all other checks fail. If an agent is tricked into calling an external service, the network layer should stop it cold.

7.5 MCP / Plugin Governance

Treat MCP servers and plugins like microservices - because that is what they are. Each one introduces code execution, network access, and data exposure into your system.

Require Security Review for Each

Before any MCP server or plugin goes into production, review:

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

Maintain a Registry

For each tool or MCP server, track:

• Owner
• Environment (dev, staging, production)
• Risk rating
• Allowed agents and tenants
• Data domains touched

Default Deny

Agents cannot use arbitrary MCP servers. Every MCP server must be explicitly allowlisted per environment. If it is not in the registry and approved, the agent cannot reach it. Period.