Mend’s Five-Layer Security Guide Targets Production AI Risks Beyond Prompt Guardrails

Mend.io published a five-layer security approach that reached Google News, yet its central message challenges how many teams protect production AI. Prompt guardrails alone cannot secure agents that hold credentials, call tools, retain memory, and change external systems.

The guide, covered by MarkTechPost on August 3, organizes the attack surface across interaction, agent, integration, model, and code layers. Its practical value lies in treating an AI application as an executable system, not merely a chatbot with unusual input risks.

That distinction creates the real conflict. Developers want agents to complete more work with fewer interruptions. Security teams need deterministic limits when those agents encounter hostile documents, poisoned tools, excessive permissions, or unexpected execution paths.

MCP, short for Model Context Protocol, gives AI applications a standard interface for discovering and calling external tools. It can connect a model to databases, file systems, APIs, business applications, and developer environments.

The protocol improves interoperability, but that convenience expands the number of trust boundaries inside each workflow. An agent can now transform untrusted text into a consequential action within seconds.

The question is no longer whether a model produces an inappropriate answer. It is whether a manipulated model can use an authorized tool for an unauthorized purpose.

Google News Puts Production AI Security in Focus

The important event is the shift from discussing model behavior to securing the entire path between input and execution.

The production security guide highlighted through Google News presents agent security as a five-layer engineering problem. The interaction layer covers prompts, retrieved documents, user files, and other information entering the application.

The agent layer includes planning, memory, tool selection, and delegated tasks. The integration layer covers MCP servers, APIs, databases, plugins, and other connections carrying the agent’s decisions into external systems.

The model layer includes the language model, its configuration, and its behavioral limitations. The code layer includes application logic, dependencies, infrastructure, credentials, and deployment pipelines.

This framing matters because failures often cross several layers. A malicious instruction can enter through a document, influence the model’s reasoning, trigger a permitted MCP tool, and expose data through an ordinary API request.

Each component can appear to work as designed. The security failure emerges from their composition.

Traditional application security still matters within this stack. Teams must patch dependencies, protect secrets, validate inputs, isolate workloads, and review code. However, those controls do not fully describe why an agent selected a valid tool at the wrong time.

The model operates on instructions and data expressed through the same basic medium. A retrieved page can contain information that answers a user’s question, instructions that redirect the agent, or both.

This creates indirect prompt injection, where malicious directions arrive through external content instead of the user’s visible prompt. An agent reading email, web pages, support tickets, or internal documents can encounter such content during normal work.

The attack can remain invisible to the person who initiated the task. The agent might summarize the expected document while quietly calling another tool or incorporating poisoned information into memory.

Mend.io’s five-layer framing therefore serves as an inventory method. It asks teams to identify every place where instructions, authority, code, data, and state can enter or leave the system.

That inventory should include more than deployed models. It should record agent configurations, system prompts, MCP servers, available tools, permission scopes, memory stores, model providers, dependencies, and responsible owners.

Without that map, teams cannot determine whether one compromised component can reach another. They also cannot revoke access confidently when an integration changes behavior.

The event is not a new protocol release or a single disclosed vulnerability. It is a clearer production boundary: agent security must follow the complete execution chain.

That boundary pressures developers, platform teams, security engineers, and AI vendors simultaneously. Each group controls only part of the system, while the most serious failures move across those organizational divisions.

AI Agents Turn Language Into Privileged Actions

An LLM becomes a materially different security problem when its output controls software with real authority.

A conventional chatbot produces text for a person to review. An agent can interpret a goal, select a tool, construct arguments, inspect the result, and continue acting without another human decision.

That loop changes the consequence of a bad model response. A fabricated sentence is inconvenient, but a fabricated instruction passed into a database or deployment tool can become an operational incident.

Consider an internal research agent asked to compare vendor proposals. It reads uploaded documents, searches shared storage, queries procurement records, and drafts a recommendation.

A malicious proposal can hide instructions telling the agent to retrieve confidential pricing from another folder. If the storage tool has broad permissions, the model’s mistaken decision becomes a real disclosure path.

A coding agent creates a similar problem. It may read repositories, install dependencies, execute tests, modify files, and open pull requests. Untrusted issue text or package documentation can influence the same model that holds those capabilities.

MCP makes these connections easier to build consistently. That benefits developers, but it also means a tool description, tool response, or remote server can influence an agent’s later choices.

OWASP’s agent security guidance identifies prompt injection, tool abuse, data exfiltration, memory poisoning, excessive autonomy, and cascading failures among the primary risks. These categories are connected, not isolated.

Memory is especially important. Persistent agent memory stores information for future sessions, allowing an application to remember preferences, prior work, or accumulated knowledge.

If untrusted content enters that store without validation, one attack can survive after the original conversation ends. Later users may receive poisoned facts or trigger behavior influenced by an earlier document.

Multi-agent systems increase the possible blast radius. One agent can pass instructions, summaries, credentials, or tool results to another agent with different permissions.

A compromised research agent might not have database write access. However, it could provide manipulated findings to an operations agent that does.

Teams cannot solve this problem by telling every model to ignore malicious instructions. Models must process natural language to perform their jobs, and attackers can vary wording, context, encoding, and delivery channels.

The security target must therefore be the action boundary. Before a tool executes, deterministic software should decide whether the agent, user, resource, operation, and parameters form an allowed combination.

A read operation should not silently become a write. Access to one repository should not grant access to every repository. Permission to draft an email should not automatically permit sending it.

High-impact operations need stronger treatment. Financial transfers, production changes, account administration, data deletion, external publication, and credential access should require explicit authorization or human approval.

The approval must bind to the actual action. A vague confirmation such as “continue” is weaker than an approval displaying the destination, operation, affected resource, and material parameters.

Short-lived credentials also reduce exposure. An agent should receive the minimum authority required for the current task and lose that authority when the task ends.

This approach can add friction, particularly when developers measure success by task completion and speed. Yet the alternative is allowing probabilistic reasoning to function as an access-control system.

Language models can propose actions. They should not unilaterally define their own authority.

MCP Standardizes Connections, Not Complete Governance

MCP solves a compatibility problem, while production teams must still build the policy and accountability layer around it.

An MCP client can retrieve a server’s available tool definitions and present them to a model. The model uses those descriptions and parameter schemas to select and invoke a tool.

This structure reduces custom integration work. A compatible client can connect with many servers through a shared protocol instead of learning a separate interface for every service.

However, standard discovery does not make every discovered tool trustworthy. A server can be compromised, impersonated, misconfigured, or updated after an initial security review.

Tool poisoning exploits this trust. Malicious instructions placed inside a tool description can influence the model while remaining hidden from the user’s ordinary interaction.

A tool response can carry similar instructions. The agent might treat the response as data, but the language model can interpret embedded text as a direction affecting later actions.

The latest MCP authorization rules include requirements addressing token validation, audience binding, token theft, communication security, redirect risks, and confused-deputy attacks.

Those requirements strengthen authentication and authorization plumbing. They do not decide whether a particular business action is appropriate for the user’s current goal.

A valid access token establishes recognized authority within its scope. It does not prove that a model reached the right decision after reading untrusted content.

Production systems need a control point between model intent and tool execution. That layer can evaluate identity, requested operation, resource, parameters, session risk, data classification, and prior actions.

Microsoft described this gap while introducing an open-source runtime governance approach. Its internal governance benchmark tested 60 prompts, including 45 adversarial cases and 15 valid cases.

Microsoft reported a 26.67 percent policy-violation rate when the system relied on prompt-only safety instructions. The company supplied methodology and reproduction materials, but the result remains its own evaluation.

The finding still illustrates an important design principle. Instruction-following performance should not be treated as a deterministic security boundary.

A runtime control plane can allow, deny, or escalate each tool request. It can also inspect tool definitions before exposing them to the model and analyze responses before returning them to the agent.

Such a layer should enforce schemas, parameter constraints, resource allowlists, rate limits, cost limits, and maximum chain depth. It should stop repeated failures rather than letting an agent enter an uncontrolled retry loop.

For example, a customer-support agent might need to read an account record and prepare a refund recommendation. It does not need unrestricted database access or immediate permission to issue every refund it proposes.

The policy layer can restrict reads to the current customer, hide sensitive fields, cap the refund amount, and require human approval before payment. The model remains useful without receiving broad operational authority.

Isolation matters too. High-privilege tools should not share the same agent context as arbitrary external MCP servers.

An agent that reads public web content should not automatically gain a path to internal administration tools. Separating these capabilities reduces the chance that hostile external content reaches sensitive execution surfaces.

Security teams should also maintain an approved server registry. Each entry should identify the server owner, code source, deployment location, authentication method, available tools, data access, version, and review status.

Updates must trigger review when they change tool descriptions, schemas, dependencies, permissions, or network destinations. A server that passed review months earlier should not receive permanent trust.

MCP servers also require conventional service protection. Teams need secure transport, authentication, patching, dependency management, input validation, secret isolation, logging, and incident response.

The protocol does not replace those controls. It creates another place where they must be applied consistently.

The Real Tradeoff Is Autonomy Versus Containment

Every additional capability improves an agent’s usefulness while increasing the damage available to a successful manipulation.

This tradeoff explains why agent security cannot become a checklist attached just before deployment. Product design determines the system’s maximum authority long before a security scanner examines it.

An agent with no tools can produce harmful or inaccurate text. An agent with file access can expose documents. An agent with shell access can execute commands, while one connected to production systems can modify live infrastructure.

Broad permissions often enter prototypes for convenience. Developers want to test whether an agent can complete an end-to-end workflow before investing in detailed authorization.

Those prototypes can move toward production faster than expected. Temporary credentials remain in configuration, experimental MCP servers become shared infrastructure, and permissive tool schemas turn into undocumented dependencies.

The five-layer model helps expose those shortcuts. However, an inventory alone does not contain them.

Each agent needs a defined trust boundary. That boundary should state who can invoke it, what data it can receive, which tools it can use, what resources it can reach, and which outcomes require approval.

Teams should distinguish between read, draft, recommend, and execute modes. These labels must map to enforceable permissions, not merely prompt wording.

A research agent can read approved sources and draft findings. An operations agent can prepare a deployment plan. A separate controlled process can verify and execute that plan.

This separation reduces autonomy, but it also creates reviewable transitions. Investigators can see when information became a recommendation and when that recommendation became an action.

Observability supports the same goal. Logs should capture the initiating user, agent identity, model version, prompt or policy version, MCP server, tool name, arguments, response classification, approval record, and final outcome.

Sensitive data should not be copied carelessly into those logs. Security telemetry needs enough context for investigation without creating another repository of exposed secrets.

Agent identity deserves particular attention. Sharing a service account across many agents makes it difficult to assign responsibility or revoke one compromised workflow.

Separate identities allow per-agent permissions and clearer audit trails. They also help security teams identify abnormal behavior, such as a research agent suddenly requesting write access.

Government guidance now treats MCP as infrastructure requiring deliberate security design. The NSA’s May 2026 MCP security guidance discusses authentication, authorization, isolation, server validation, lifecycle management, and risks spanning the protocol’s components.

That attention signals a change in maturity. MCP is no longer only a developer convenience discussed through local demos. Organizations are evaluating it for environments where compromised tools can affect sensitive data and operations.

Google Cloud’s agent security controls make a similar point. The guidance recommends a distinct agent identity, least-privilege roles, and restrictions preventing read-write tool access to production resources.

These are familiar security principles. Their application becomes harder because agents select actions dynamically and combine individually valid tools into workflows developers did not enumerate.

Insecure tool chaining occurs when the result of one allowed operation enables a harmful sequence. A search tool, file reader, and outbound messaging tool may each appear low risk when reviewed separately.

Together, they can create a data-exfiltration path. The agent searches for sensitive information, reads it, and transmits it outside the organization.

Policy must therefore examine sequences as well as individual calls. A request can be valid alone but suspicious after another event in the same session.

Context-aware controls can block combinations involving untrusted input and privileged output. They can also require reauthorization when an agent crosses from information gathering into external action.

This design is more demanding than adding a filter around the user prompt. It requires coordination among product, platform, identity, application security, and operations teams.

That organizational cost is part of the tradeoff. Companies cannot claim broad autonomous capability while assigning security responsibility only to the model provider.

What Production Security Still Cannot Guarantee

Layered controls reduce exposure, but no current framework proves that an agent will remain safe across every model, tool, and context combination.

The first uncertainty is evaluation quality. Security tests can measure known attacks, but production inputs change continuously and adversaries adapt to published defenses.

A red-team suite should include direct and indirect prompt injection, unauthorized tool use, privilege escalation, memory poisoning, data exfiltration, approval bypass, recursive execution, and multi-agent propagation.

Teams should run these tests before deployment and after material changes. A new model, system prompt, memory design, MCP server, tool schema, retrieval source, or policy can alter the attack surface.

Passing a test does not establish permanent safety. It shows that defined controls resisted defined attacks under specific conditions.

False positives create another problem. If controls interrupt too many legitimate tasks, users seek workarounds or demand broader permissions.

False negatives are more dangerous but harder to observe. An agent can complete the requested task while also leaking data, saving poisoned memory, or taking an unnecessary action.

Human approval is not a complete solution. Users can become habituated to confirmations, especially when an application presents frequent or unclear prompts.

Attackers may also manipulate the information shown to the approver. Approval interfaces must obtain action details from trusted execution data, not from the model’s explanation alone.

Supply-chain risk remains unresolved as well. MCP deployments can include servers, SDKs, registries, packages, models, containers, and hosted services maintained by different parties.

A signed package can establish origin and integrity. It cannot guarantee that the signed behavior is safe or that a remote service will remain unchanged.

Organizations should prefer reproducible deployments, pinned versions, reviewed source code, controlled registries, and documented update processes. Remote servers need ongoing validation, not a one-time approval.

Emergency revocation must be practical. Teams should be able to disable an agent, server, tool, credential, or permission without waiting for an application release.

Memory systems need equivalent controls. Operators require methods to inspect, quarantine, expire, and remove suspicious entries while preserving evidence for investigation.

The skepticism also applies to vendor claims. Security products increasingly promise prompt protection, automated red teaming, agent discovery, posture management, or runtime enforcement.

These capabilities can contribute to defense, but buyers should ask where each control sits and what happens when it fails. A detector that only flags suspicious text cannot replace authorization on the resulting action.

Teams should request measurable evidence. Useful questions include which attack classes were tested, whether evaluation data is available, how bypasses are handled, and whether enforcement fails closed.

They should also examine latency and availability. A policy service positioned before every tool call becomes critical infrastructure.

If that service fails open, agents can act without controls. If it fails closed, dependent workflows stop. Production design must address both outcomes explicitly.

The five-layer approach is therefore a foundation, not a guarantee. It helps teams locate risks that a model-only review would miss.

Its success depends on converting the layers into ownership, enforceable policy, repeatable testing, and operational response. Without those steps, the framework becomes another diagram that documents exposure without reducing it.

Three Signals Will Show Whether Agent Security Is Maturing

The next phase will be measured by enforceable defaults, independent testing, and evidence from real deployments.

The first signal is whether MCP clients and servers adopt narrower authorization by default. Support for modern authorization standards matters, but safe deployments also require resource-specific scopes and clear separation between read and write operations.

A stronger ecosystem would make broad permissions visibly exceptional. Clients would show users what each server can access, while servers would reject tokens intended for another resource.

Default restrictions would strengthen the argument that standardized connectivity can coexist with containment. Continued reliance on ambient credentials and oversized scopes would weaken it.

The second signal is independent evaluation of runtime governance. Vendor benchmarks provide useful starting points, but buyers need repeatable tests across multiple models, tools, and attack styles.

Evaluators should report both attack prevention and legitimate task completion. A system that blocks every tool call is secure in a narrow sense but fails its operational purpose.

Results should also separate prompt detection from action enforcement. Detecting suspicious language is different from preventing a prohibited file read, database update, or outbound request.

The third signal is whether enterprises can produce complete agent inventories and incident records. Organizations should know which agents are deployed, who owns them, which models they use, and which MCP servers they can reach.

They should also be able to reconstruct consequential actions from authenticated logs. Missing identities, incomplete tool records, or unexplained permission changes indicate that adoption has moved faster than governance.

This is where knowledge management intersects with security operations. Teams need searchable records connecting requirements, agent configurations, test results, approvals, incidents, and remediation decisions.

A controlled technical knowledge base can help engineers retrieve those records, but it must respect the same access and data-handling boundaries.

The Google News appearance gives the five-layer security model broader visibility. Its lasting importance depends on whether teams turn that visibility into smaller permissions and stronger execution controls.

Developers should begin with one production workflow and map every input, model decision, memory write, integration, credential, tool call, and output. Then they should identify where deterministic policy interrupts unsafe movement between those points.

Can your organization explain what every production agent can do, which identity authorizes it, and how one compromised document would be contained? If the answer is incomplete, the next action is not another prompt rule. It is a narrower execution boundary, a tested approval path, and an audit trail that survives the agent’s reasoning.