TLDRocket
Sign in

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

MarkTechPost Asif Razzaq

Mend.io dropped a practical framework for securing AI agents, MCP servers, and LLM apps in production. Traditional AppSec assumes code determines behavior—agentic AI breaks that assumption entirely.

Security teams built their entire playbook on one assumption: applications behave the way their code says they will. Agentic AI just torched that assumption. An agent's behavior emerges from a stew of model weights, system prompts, retrieved documents, user input, and whatever tools it decides to call. Run the same deployment twice and you can get two different outcomes. Mend.io's new guide, aimed at practitioners rather than executives, tries to give security teams a map for a threat surface that barely existed two years ago.

The scariest part isn't the exotic stuff—it's how quiet these failures are. Prompt injection sneaks in through data, not code, so it never shows up in a vulnerability scanner. An agent with too many permissions can wreck something without any actual exploit occurring. A model that's past its end-of-life date keeps quietly generating predictions long after anyone stopped patching it. And a poisoned tool description sitting on an MCP server can hijack an agent's behavior without anyone touching the application itself. None of this trips a CVE alert, which is exactly the problem.

Mend.io splits its approach into five attack-surface layers—interaction, agent, integration, model, and code—each with its own failure modes, from context poisoning to unscoped credentials to malicious packages riding along in AI frameworks. The discovery piece is blunt about reality: agents rarely enter a company through procurement. They show up because a developer wired one into a repo, or spun up an MCP server nobody registered. The guide recommends five detection methods, including scanning repos for agentic code patterns and watching network egress for calls hitting model API endpoints, because point-in-time audits go stale almost immediately.

On the fix side, the framework draws a hard line about what AI should and shouldn't decide on its own. Automated closure is fine when there's a clear evidentiary trail—reachability data, dataflow analysis, well-understood vulnerability classes. But anything novel, any judgment call about accepting risk, or any behavior nobody's seen before goes straight to a human, full stop. That's a deliberately conservative stance in a space full of vendors promising to automate triage end to end.

Runtime protection gets treated as a continuous loop rather than a one-time setup: red-teaming feeds guardrail improvements, and guardrail logs feed back into what red teams test next. Mend.io pushes hard on permission scoping over prompt engineering—if a tool physically can't be called, you don't need to write a clever instruction telling the agent not to call it. The guide wraps with a four-stage maturity model, mapped to NIST's AI risk framework, OWASP's AI maturity assessment, ISO 42001, and the EU AI Act, plus a 15-question self-scoring checklist so teams can see where they actually stand instead of guessing.

My take

This is the security conversation the industry should've had before shipping agents into production, not after. I'll say the quiet part loud: 'shift left, protect right' is a nice slogan, but the real signal here is Mend.io insisting that risk acceptance and novel findings stay human-only—that's the correct, unfashionable answer in a market obsessed with full automation. Permission scoping beating prompt engineering is the one lesson every vendor selling 'safety through better prompts' should be forced to read twice.

Read more about this at: MarkTechPost

Related stories

The daily briefing

Every AI story that matters, in your inbox by 8am.

TLDRocket reads 60+ sources, removes duplicate coverage, and summarises the day in two minutes. Follow companies and topics for alerts, or get the briefing in Slack. Free, no spam, unsubscribe anytime.