Source-led article
Securing AI agents in production: practical checks from a new Mend.io framework

Security teams can no longer assume that applications do what their code says. With AI agents, Model Context Protocol (MCP) servers and LLM-powered applications, behaviour emerges from a model, a system prompt, retrieved context, user input and the tools an agent may call. Two identical deployments can behave differently. 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 without touching the application. None of these appear in a CVE feed.
A new practitioner guide from Mend.io, published through MarkTechPost on 3 August 2026, argues that the mandate is two-sided: shift left and protect right. The article is sponsored by Mend.io, so the material reflects its vendor guidance rather than independent research.
| Item | Details |
|---|---|
| Framework | See, fix, protect; seven reusable artifacts |
| Primary discovery targets | Shadow agents, unregistered MCP servers, embedded AI frameworks |
| Inventory artifact | AI-BOM extended with nine fields per agent or MCP server |
| Configuration | 12-point misconfiguration checklist with prioritisation signals |
| Maturity scoring | Four stages, 15-question self-assessment linked to NIST AI RMF, OWASP AIMA, ISO/IEC 42001 and the EU AI Act |
| Caveat | Sponsored guide; no independent benchmark data |
Why the old AppSec assumption fails
The guide points out that agents rarely arrive through procurement. Security teams should hunt for three categories in particular: shadow agents, unregistered MCP servers and embedded AI frameworks. Every MCP server, it says, needs an owner, an access scope and a review.
Five discovery methods are recommended. 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 through lightweight registration. Fifth, automate continuously, because point-in-time discovery goes stale fast.
See, fix, protect: inventorying and prioritising
The guide’s first move, “see”, centres on extending 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 and last review. That gives teams a concrete record of what an agent can access and who last checked it.
The “fix” stage uses a 12-point misconfiguration checklist. Among the points: credentials should be scoped to specific resources rather than broad service-level access; no shared credentials should exist between agents; high-impact tools should require human approval; system prompts should be in version control and not editable directly in production; MCP servers should authenticate clients; tool descriptions should be reviewed for injection-bearing content before adoption; and model versions should be pinned with end-of-life monitoring and a named owner.
Prioritisation follows an enrich, prioritise, triage pipeline. The signals, in order of value, are reachability, exploitability context, business context, agentic amplification and fix availability. This ordering is designed to stop teams from chasing issues that look serious in a report but cannot actually be reached or exploited.
Automation with evidence
The guide also draws a line on automation. Two rules govern it: every automated closure must carry evidence, and if the system cannot show why something is a false positive, it goes to a human. Error rates should get sampled review, with thresholds triggering retraining.
Runtime protection is meant to operate as a loop with AI red teaming. Red team discoveries improve guardrails, while guardrail logs guide subsequent red teaming. The loop is not a one-time audit; it is designed to keep responding to new injection techniques and policy changes.
Guardrails and prompt hardening
Guardrails can be deployed in two ways: through an in-app Python SDK with Online or isolated Offline modes, or as a standalone API Server running in Docker, which requires no code changes or Python dependencies.
The minimal viable setup includes inbound guardrails that catch prompt injections, out-of-policy requests and jailbreaks, alongside outbound guardrails that catch credentials, personally identifiable information, proprietary code, unsafe content and policy violations.
System prompt hardening follows five patterns: assuming disclosure, separating instructions from data, constraining the blast radius, versioning and reviewing prompts, and adversarial testing. The guide is explicit that setting strict permissions is more effective than prompt instructions. Preventing tool access removes the need to instruct an agent against dangerous actions.
Four maturity stages, mapped to regulation
The guide’s final move, “protect”, includes a maturity self-assessment with four stages: Emerging, Developing, Controlling and Leading. Artifact 5.1 is a 15-question assessment: 0–5 places an organisation at Emerging, 6–10 at Developing, 11–13 at Controlling, and 14–15 at Leading.
The framework is aligned with NIST AI RMF, OWASP AIMA, ISO/IEC 42001 and the EU AI Act. Separately, Artifact 4.1 contains seven validation checks for runtime protection. Teams using the framework can benchmark themselves against these global standards, although the guide does not provide independent evidence of how organisations typically score.
What remains unclear
Because the article is a sponsored resource from Mend.io, its coverage claims have not been independently verified. The 12 checklist items are described, but the guide does not say how often each misconfiguration appears in real deployments or which ones cause the most damage. The seven validation checks are also listed without a detailed scoring method.
Security teams should treat the framework as a useful starting point for inventorying agents and MCP servers, not as a certification or a guarantee of compliance. The core value is the structure: a named owner, an access scope, a review date, and guardrails that produce evidence.
Source: https://www.marktechpost.com/2026/08/03/how-to-secure-ai-agents-mcp-servers-and-llm-apps-in-production/