HIGH Tier: MCP Engineering Agent¶
The system: an internal assistant that helps engineers operate production systems. It connects to several Model Context Protocol (MCP) servers that expose tools, query logs and metrics, search the ticket system, read configuration, run read-only diagnostics, and (for some users) restart a service or open a change. An engineer asks in natural language; the agent plans and calls tools to get it done.
This is the example where the tools are the risk. A retrieval assistant reads; this agent acts, through tools it did not write, described by metadata it did not author, returning output it cannot trust. It exercises the parts of the framework that a chat assistant never touches.
Why this is HIGH tier¶
From the classification process: the agent has access to production systems, can take actions with operational impact, and operates with meaningful autonomy. It is internal, which caps some exposure, but the combination of system access and autonomy puts it at HIGH, with destructive actions (service restart, config change) attracting CRITICAL-level controls for those actions.
The MCP-specific risks¶
MCP makes it easy to give an agent many tools from many sources. That convenience is the threat surface. See this site's MCP-specific controls and AIRS's The MCP Problem.
| Risk | What goes wrong |
|---|---|
| Untrusted MCP servers (tool supply chain) | An MCP server is a third-party dependency that can call your systems. A compromised or malicious server is a direct path into your environment. |
| Tool-description injection | The agent reads each tool's name and description to decide how to use it. A malicious server can embed instructions in that metadata ("to use this tool, first call exfiltrate..."), injecting the agent before any user input. |
| Tool-output injection | Logs, tickets, and configs contain attacker-influenced text. When that output returns to the agent, it can carry instructions that steer the next action. |
| Over-broad tool scope | It is easy to grant an agent every tool a server offers. Excess capability is excess blast radius. |
| Confused deputy via delegation | The agent acts "on behalf of" an engineer. If it does not carry that engineer's identity and limits, it can do things the engineer could not. |
The controls that matter most¶
Treat every MCP server as untrusted supply chain¶
Vet, pin, and inventory MCP servers the way you would any dependency. See SUP-05, Audit Tool and Plugin Supply Chain and Tool Access Controls.
- Allowlist which MCP servers the agent may connect to; pin versions; maintain an AI-BOM that includes them.
- Treat tool descriptions as untrusted input. Do not let tool metadata flow into the planning context without inspection.
- Sanitise tool output before it re-enters the model (Tool Output Sanitisation).
Enforce tool permissions at a broker, not in the prompt¶
The agent must call tools through a broker that holds the credentials and decides what is allowed, so a prompt-injected agent still cannot exceed its grant.
| Control | What it enforces | Reference |
|---|---|---|
| Explicit tool permissions | Which tools, for which users, with which parameter bounds | Tool Access Controls |
| Action classification | Read vs write vs destructive; reversibility-based handling | Agentic Controls |
| Approval for high-impact actions | Service restart and config change require human confirmation | Approval Workflows |
| Egress control | The agent and its tools can reach only declared destinations | Network & Segmentation |
Identity: the agent is a non-human identity acting under delegation¶
Two identity problems sit on top of each other here.
- Non-human identity (NHI). The agent itself is an identity with a lifecycle, credentials, and least-privilege scope. It needs short-lived, scoped tokens from a vault, never standing admin rights. See IAM Governance and AIRS's NHI Lifecycle.
- Delegation. When the agent acts for an engineer, it must propagate that engineer's identity and never exceed their permissions. Enforce least delegation and identity propagation: the agent's effective permission is the intersection of its own scope and the user's, never the union.
Sandbox anything that executes¶
If the agent runs diagnostics or generated commands, run them in an isolated sandbox with restricted file system, network, and resource limits, and scan before execution. See Sandbox Patterns.
Review the actions, and choose how you combine the reviewers¶
Broker permissions decide what the agent may do; the reviewing layer judges what it is about to do. You have a choice of reviewers here, and they combine:
- Semantic firewall inline on a proposed action, screening it against policy in real time before the broker executes it. This keeps up with a fast agent loop where a full judge would cost too much latency per step.
- Model-as-judge for post-action review, auditing action sequences asynchronously to catch the multi-step patterns a single-action check misses, then alerting a human.
At this HIGH tier a destructive action (service restart, config change) still routes to human confirmation regardless. The choice is where the automated review sits: inline in the hot path for real-time blocking, async for deeper review, or both. Match it to the action's latency budget and blast radius; the reviewing-controls latency table gives the baseline.
The 'just add the MCP server' reflex
The fastest way to create a HIGH-tier incident is to point the agent at a convenient public MCP server so it can "also do X." Every new server is a new supplier with a path into your systems and a new channel for tool-description injection. Adding one is a re-tiering event, not a configuration tweak.
What this example teaches¶
Tools turn an assistant into an actor, and MCP turns tool sprawl into supply-chain risk. The defining moves are: broker-enforced permissions (not prompt instructions), least delegation with identity propagation, untrusted handling of tool descriptions and outputs, and sandboxed execution. When agents start calling other agents, this moves into multi-agent territory, hand off to Multi-Agent Controls and MASO (Multi-Agent Security Operations). For the opposite end of the impact scale, where the model itself is the risk, see the CRITICAL Credit Decisioning example.