How to Secure AI Agents, MCP Servers, and LLM Apps in Production

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: DecisionDispositionReachability/dataflow, well-understood classesAutomateFP/TP assessment with evidence trailsAutomate, with samplingTier-3/high-risk applicationsAI-assist, human decidesNovel classes, AI behaviors, no evidenceHuman onlyAccepting 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 monitori