Notifications
Clear all
Topic starter
05/07/2026 6:55 pm
TL;DR: MCP connects AI applications to tools and data, but Lakera’s guide shows that prompt injection, data leaks, and unsafe outputs can still pass through unless inputs and outputs are screened at the tool boundary. The governance gap is not access alone, but what the model is allowed to do with access once context becomes executable.
NHIMG editorial — based on content published by Lakera: How to Secure MCPs with Lakera Guard Engineering
Questions worth separating out
Q: How should security teams govern MCP servers used by AI applications?
A: Security teams should govern MCP servers as delegated non-human identity pathways, not just as APIs.
Q: Why do MCP-based AI systems increase prompt injection risk?
A: MCP-based AI systems increase prompt injection risk because they connect models directly to tools and external context that may contain hidden instructions.
Q: What breaks when AI tool permissions are too broad in MCP environments?
A: When AI tool permissions are too broad, a model can turn a small content manipulation into a large operational action.
Practitioner guidance
- Separate tool, prompt, and resource controls Apply distinct validation rules to MCP tools, prompts, and resources so that each primitive is checked at the point of use, not only at the perimeter.
- Add content screening to model-facing paths Screen inbound and outbound text for prompt injection, unsafe instructions, and data leakage before the model can act on the content.
- Scope MCP permissions narrowly Limit each MCP server to the minimum tools and resources needed for its task, and review those permissions as part of identity governance.
What's in the full article
Lakera's full engineering guide covers the operational detail this post intentionally leaves for the source:
- The exact Python decorator pattern used to screen MCP input and output before a tool response is returned.
- Code-level examples for securing MCP tools, prompts, and resources separately in a working server.
- The latency and implementation trade-offs of adding a guard layer to model-facing content flows.
- The source gist referenced by the author for practitioners who want to test the pattern directly.
👉 Read Lakera’s engineering guide on securing MCP servers with Guard →
MCP security and AI tool controls: what changes for IAM teams?
Explore further
05/07/2026 7:17 pm
Control what the model does, not only what it can reach: MCP makes access control incomplete if governance stops at connection approval. The article shows that a model can be allowed to reach a tool or resource and still be unsafe because the content it processes can alter behavior at runtime. That means the effective security boundary has moved from identity issuance to content interpretation. Practitioners should treat model-facing execution paths as governed surfaces, not just authenticated integrations.
A few things that frame the scale:
- 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
- Another finding from the same research shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which helps explain why tool governance remains weak.
A question worth separating out:
Q: How can teams reduce the impact of unsafe model output in MCP workflows?
A: Teams can reduce impact by combining output screening, narrow tool scoping, and reviewable ownership for each MCP integration. The goal is to stop unsafe content before it becomes a tool action or user-facing result. If the model has already crossed the content boundary, the next control should limit what it can still change.
👉 Read our full editorial: MCP security shows why AI tools need content controls
