Mend.io has released a new practitioner guide titled ‘Securing AI agents, MCP servers & LLM apps: A practical framework’. The document addresses the speed at which agentic workflows are entering production codebases. It is structured around three actions: see what matters, fix what matters faster, and protect AI in production. The guide provides seven reusable artifacts for implementation.
Why traditional AppSec breaks
Application security 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, prioritise, triage. Prioritisation signals, in order of value: reachability, exploitability context, business context, agentic amplification, fix availability.
Artifact 3.1 draws the automation line:
| Decision | Disposition |
| Reachability/dataflow, well-understood classes | Automate |
| FP/TP assessment with evidence trails | Automate, with sampling |
| Tier-3/high-risk applications | AI-assist, human decides |
| Novel classes, AI behaviors, no evidence | Human only |
| Accepting risk or deferring a fix | Human 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.
What it means
For teams building agentic systems, the shift is from auditing static code to managing dynamic behaviour. Security must now track shadow agents and unregistered servers that appear without procurement. The practical change is a move towards automated triage for known risks while reserving human judgment for novel AI behaviours. Guardrails are no longer optional add-ons; they function as embedded SDKs or standalone API servers to catch injections and policy violations at runtime. The maturity model aligns these efforts with existing standards like NIST and the EU AI Act.
