待翻译：How to Secure AI Agents, MCP Servers, and LLM Apps in Production

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

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.