Limit the blast radius: prompt injection, MCP and agent permissions

Adapted from three posts first published on the Novaeon Studio LinkedIn page (15, 16 and 29 October 2026).

Your agent's inbox is untrusted input

An AI agent that reads your inbox also reads every email a stranger sends you.

That is the core of prompt injection: instructions hidden in an email, a web page or a PDF can steer the agent that processes them. OWASP ranks it #1 in its Top 10 for LLM Applications and says it is unclear whether fool-proof prevention exists. The UK's NCSC explains why: current LLMs do not enforce a boundary between instructions and data.

In agent-hijacking tests NIST published in 2025, the strongest attack tailored to one of the top-performing models of the time succeeded 81% of the time in a simulated office setting, against 11% for the strongest baseline attack.

So the useful question is not "can we block it?" but "what could a hijacked agent do?" Our design rules:

1. Every input is untrusted data. Emails, web pages, documents, tool results. Label them as data, never as instructions.
2. Least privilege. An agent gets only the tools its task needs. One that summarises supplier emails does not need to send payments.
3. Human approval for side effects. Sending, booking, paying, deleting: a person confirms first.
4. Separate read and act. The part that reads outside content should not hold the keys that change your systems.
5. Log everything. Inputs, tool calls, approvals. Failed tool calls can reveal an attacker still testing.

We apply this to our own agents. Content they fetch from the web arrives labelled as untrusted data, and they must not follow instructions in it. Tools with side effects need approval.

None of this makes an agent immune. It limits the blast radius, and that part you control.

MCP: one plug for AI agents. Secure it.

Your next AI project will probably ask for "MCP access". Here is what that means.

MCP, the Model Context Protocol, is an open standard for connecting AI agents to tools and data. The official site compares it to a USB-C port for AI: build a connector once, any compatible agent can use it.

Why it matters: it is becoming the common plug. Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation in December 2025. Microsoft Copilot Studio agents can use tools from MCP servers. SAP's reference architecture names MCP as its standard for tool connectivity, with an MCP gateway in Integration Suite.

The flip side: every MCP server you connect is code your agent will trust. The specification itself says tools represent arbitrary code execution and must be treated with caution. Five things to get right before go-live:

1. Tool permissions. Only the tools the agent needs. Human approval for anything that writes, sends or deletes.
2. Untrusted servers. Vet and pin third-party servers. Researchers showed hidden instructions in tool descriptions steering an agent to leak files. In SAP's reference architecture, only verified MCP servers can be called in production (AI Agent Hub).
3. Token scopes. Narrow scopes, tokens issued for that server only. The MCP security guide forbids passing tokens through.
4. Logging. Record every tool call: which agent, which tool, which arguments, on whose behalf.
5. Tool output is untrusted input. In one published exploit, a malicious GitHub issue made an agent leak private repository data into a public pull request.

None of this is exotic. It is the discipline you already apply to service accounts and interfaces.

An agent never gets more rights than its user

When your AI agent changes a record, whose permissions does it use?

A common shortcut is a technical account with far more rights than any single user has. It is quick to set up, and every call works.

OWASP names this pattern in its Top 10 for LLM Applications (LLM06:2025, Excessive Agency). Its example: an extension meant to read one user's documents connects with a privileged account that can see everyone's files. The root causes it lists are excessive functionality, excessive permissions and excessive autonomy.

Two of OWASP's mitigations matter most for enterprise systems:

1. Execute in the user's context. An action taken on behalf of a person runs with that person's authorisation and the minimum scope needed. The agent never gets more rights than the person it acts for.
2. Complete mediation. The downstream system decides whether an action is allowed, not the model. Your ERP's role concept, approval limits and segregation of duties keep working, because the agent goes through them instead of around them.

I spent 22+ years in enterprise IT, SAP release and change management. Authorisation concepts are core to that world. An agent on a broad technical user quietly bypasses all of it.

How we design it:

• One clear role per agent, with only the tools that role needs.
• Write actions run under the requesting user's identity.
• Hard limits enforced in the target system, not in the prompt.
• An escalation path to a person when the agent hits a limit.

Least privilege is old advice. Agents just make it easy to forget.

How we build agents with scoped tools, MCP integrations and guardrails: AI Agent Engineering at Novaeon Studio.

Maik Buchenau, co-founder of Novaeon Studio