Mend.io、AI エージェントと MCP サーバーの生産環境セキュリティガイドを公開

Agents, MCP integrations, and LLM-powered applications are entering codebases faster than most security programs can track them. Mend.io’s new practitioner guide, ‘Securing AI agents, MCP servers & LLM apps: A practical framework’, targets that gap. It is organized around three moves: see what matters, fix what matters faster, protect AI in production and ships seven reusable artifacts.

Why traditional AppSec breaks

AppSec was built on one assumption: applications do what their code says. Agentic AI breaks it. Agent behavior emerges from a model, a system prompt, retrieved context, user input, and the tools it may call. Two identical deployments can behave differently.

The failure modes are new too. Prompt injection arrives through data, not code. An over-permissioned agent can take harmful actions without any vulnerability being exploited. A deprecated model keeps serving predictions after its maintainer stops patching it. A poisoned tool description on an MCP server can redirect an agent’s behavior without touching the application. None appear in a CVE feed. The mandate is two-sided: shift left, and protect right.

Artifact 1.1: the five-layer attack surface map

Interaction: user inputs, retrieved documents, inter-agent messages → prompt injection, context poisoning, data exfiltration

Agent: system prompts, configs, memory, autonomy settings → over-permissioned tools, unsafe defaults, goal hijacking

Integration: MCP servers, tool definitions, plugins, APIs → poisoned tool descriptions, unscoped credentials, shadow servers

Model: foundation and fine-tuned models, embeddings → EOL models, supply chain risk, unsafe generations

Code: AI-generated code, AI frameworks, SDKs → vulnerable code, framework CVEs, malicious packages

See: agent and MCP discovery

Agents rarely arrive through procurement. Three categories to hunt: shadow agents, unregistered MCP servers, and embedded AI frameworks. Every MCP server needs an owner, an access scope, and a review.

There are five discovery methods. First, scan repositories for agentic signatures. Second, watch network egress for calls to model API endpoints. Third, audit service accounts and API keys. Fourth, make declaration cheap via lightweight registration. Finally, automate continuously, since point-in-time discovery goes stale fast.

Artifact 2.1 extends the AI-BOM with nine fields per agent or MCP server: identity, model dependency, autonomy level, tool permissions, credential scope, data reach, MCP endpoints, prompt location, last review.

Artifact 2.2 is a 12-point misconfiguration checklist: credentials scoped to specific resources, not broad service-level access; no shared credentials between agents; high-impact tools requiring human approval; system prompts in version control, not editable in production; MCP servers authenticating clients; tool descriptions reviewed for injection-bearing content before adoption (tool poisoning); model versions pinned with EOL monitoring and an owner.

Fix: prioritization and triage

AI expanded the finding surface, not just the attack surface. The pipeline is enrich → prioritize → triage. Prioritization signals, in order of value: reachability, exploitability context, business context, agentic amplification, fix availability.

Artifact 3.1 draws the automation line:

DecisionDisposition

Reachability/dataflow, well-understood classesAutomate

FP/TP assessment with evidence trailsAutomate, with sampling

Tier-3/high-risk applicationsAI-assist, human decides

Novel classes, AI behaviors, no evidenceHuman only

Accepting risk or deferring a fixHuman only, documented

Two rules govern it. Every automated closure carries evidence; if the system cannot show why something is a false positive, it goes to a human. Error rates get sampled review, with thresholds triggering retraining.

Protect: runtime security

Runtime protection involves guardrails, prompt hardening, policy enforcement, and monitoring. Operating as a loop with AI red teaming, red team discoveries improve guardrails, while guardrail logs guide subsequent red teaming.

Guardrails deploy in two ways: via an in-app Python SDK (supporting Online or isolated Offline modes) or as a standalone API Server (Docker) requiring no code changes or Python dependencies. The minimal viable setup includes inbound guardrails catching prompt injections, out-of-policy requests, and jailbreaks, alongside outbound guardrails catching credentials, PII, proprietary code, unsafe content, and policy violations.

System prompt hardening follows five patterns: assuming disclosure, separating instructions from data, constraining the blast radius, versioning/reviewing, and adversarial testing. Setting strict permissions is more effective than prompt instructions—preventing tool access removes the need to instruct against dangerous actions. Artifact 4.1 contains seven validation checks.

The maturity roadmap

Four stages: Emerging, Developing, Controlling, Leading. It is aligned to NIST AI RMF, OWASP AIMA, ISO/IEC 42001, and the EU AI Act. Artifact 5.1 is a 15-question self-assessment: 0–5 Emerging, 6–10 Developing, 11–13 Controlling, 14–15 Leading.

Key takeaways

Agent behavior emerges from model, prompt, context, input, and tools — not code alone.

Five risk layers: interaction, agent, integration, model, code.

Hunt shadow agents, unregistered MCP servers, embedded AI frameworks.

Automate evidence-backed triage; keep risk acceptance and novel findings human-only.

Guardrails ship as an embedded Python SDK or a standalone Docker API Server.

Check out the full guide here.

Thanks to the Mend.io team for the thought leadership / resources for this article. This article is sponsored by Mend.io.

The post How to Secure AI Agents, MCP Servers, and LLM Apps in Production appeared first on MarkTechPost.