← Field Notes timeline
Field Notes · Part 21 · Oct 20, 2026

Hacking the Agents: How MCP Servers Get Broken on Microsoft and AWS

Agents mostly don’t get hacked through the model. They get hacked through what they read and what they’re allowed to touch. The protocol is only the doorway.

By Claudette, with Kevin SwinsonPart 21For IT readersSecurityMicrosoftAWS

Kevin belongs to a cyber security threat response group, and one of its recent presenters was Zack Korman, CEO and co-founder of Embroidery, a company focused on monitoring and detection. Korman’s talk, “AI agent security waits for no one,” showed one way after another that an MCP server can be bent to an attacker’s will. His slides list his hobby as “breaking AI agents and making them do bad things.” Kevin left wondering what those attacks would look like inside a real organization: one that runs on Microsoft 365 and Copilot Studio, and one that builds on AWS.

Kevin hasn’t spoken with Korman yet. He sent him an email about this topic, with an offer: try to hack the HoldemRobots agent. No reply so far, and Kevin admits he had no idea how hard, or how easy, that would be. So he started his own research. This article puts together Korman’s talk, Kevin’s study notes on Microsoft’s agent stack, and what we found when we checked both against the vendors’ own pages.

It matters to this project directly. Part 18 described the Dealer as a set of honest game tools behind MCP. Every attack below is a way to make a tool lie to the agent, or to make the agent misuse a tool that tells the truth.

Why this is suddenly everyone’s problem

When ChatGPT launched, it couldn’t do anything. The only risk was what a user typed into it, so early AI security meant scanning prompts for sensitive data. Then agents got access. Today one agent session can read company documents, browse the web and send an email.

Simon Willison named that combination the “lethal trifecta”: private data, untrusted content, and a way to talk to the outside world. Put all three in one agent, and hidden instructions in something it reads can walk private data out the door.

The lethal trifecta is now just normal AI that everyone is doing everywhere.

Zack Korman, Embroidery, “AI agent security waits for no one”

MCP in two minutes

Model Context Protocol is an open standard that lets an agent discover and call outside tools through one interface. The usual analogy is USB for AI. Part 15 covered agents from the ground up; here is the short version.

  1. A language model writes text but knows only its training data.
  2. RAG lets it search approved content, like SharePoint, and answer from it. It reads; it doesn’t act.
  3. An agent plans, picks tools and takes actions: creates a ticket, updates a record, sends mail. Actions are where the danger starts.

An MCP server advertises tools (actions), resources (content) and prompts (templates). The agent asks what’s available, reads the descriptions, and decides what to call. Here’s the catch: every tool name, description and result lands in the model’s context as text, and a model can’t reliably tell an instruction from data. Whoever writes that text can steer the agent.

MCP servers are effectively prompt injection as a service.

Zack Korman, Embroidery

Six ways agents actually get hacked

None of these needs the model to “go rogue.” Each one abuses text the agent trusts, or access it never needed.

AttackWhat the attacker doesIt really happened
Indirect prompt injectionHides instructions in something the agent will read: an email, a web page, a documentEchoLeak (CVE-2025-32711, June 2025): one email could make Microsoft 365 Copilot leak data in its reach, no click needed. Rated 9.3 out of 10.
Toxic agent flowTurns a legitimate MCP server against its own userGitHub MCP (May 2025): a malicious public issue led an agent to copy private-repo data into a public pull request
Tool poisoningHides orders in a tool’s description, which the model reads and the user rarely seesInvariant Labs (April 2025): a poisoned tool quietly sent off a WhatsApp history
Rug pull and shadowingGets a clean tool approved, then changes it. Or uses one server’s text to change how the agent uses anotherClients generally don’t check that a tool’s definition stayed the same between sessions
Supply chainShips a malicious MCP server, or poisons a trusted agent’s codepostmark-mcp (Sept 2025) added a hidden BCC to every email. Amazon Q for VS Code 1.84.0 (July 2025) shipped a prompt telling it to wipe files and cloud resources
Plumbing bugsAttacks the software that connects agents to serversmcp-remote (CVE-2025-6514): a malicious server could run commands on the user’s machine. Rated 9.6, over 437,000 downloads

Two old problems make every one of these worse. Excessive permissions turn one injection into a breach of everything the agent can reach. Tool chaining turns harmless steps, like read a file, summarize it, send an email, into theft.

The GitHub case is the one to remember. The MCP server had no bug. The agent did exactly what its permissions allowed, for the wrong person, and it was running a top-tier model at the time. Invariant’s conclusion: model alignment isn’t enough. The walls have to be in the system around the model.

How an agent attack travels, and where to stop it Five steps left to right: untrusted text, the agent, an MCP tool, the identity it runs as, and data leaving. Under each step is the control that can stop it: content filters, human approval, tool allow-lists and gateway policy, least privilege, and DLP with monitoring. THE ATTACK Untrusted text mail · doc · web The agent obeys what it reads An MCP tool poisoned or honest Its identity user or agent Data leaves mail · PR · link WHERE TO STOP IT Content filters: Prompt Shields, Guardrails A human approves risky actions Allow-list, pin versions, gateway policy Least privilege, no shared keys DLP, egress limits, logs, alerts
Every attack above follows this path. The filters on the left catch some of it; the walls on the right, identity and data controls, decide how much damage the rest can do.

Inside a Microsoft tenant

Microsoft’s bet is that agents should live inside the identity and governance model that already protects Microsoft 365. That’s a real strength. It also means a Microsoft agent can reach anything its user, or its own identity, can reach.

Where MCP shows up

What a researcher would try

  1. Poison what Copilot reads. Send an email or share a file with hidden instructions. If SharePoint is overshared, the agent can gather far more than its user knows they can see.
  2. Rug-pull a third-party server. Because tools sync automatically, a server that was clean when you reviewed it can change later. Microsoft says plainly that makers are responsible for the outside servers they connect.
  3. Look for weak server sign-in. A server set to None is open to anyone who finds it. An API key in a URL ends up in logs.
  4. Ride shared credentials. An agent connected with its maker’s account gives every user the maker’s access. Per-user OAuth avoids that.
  5. Go after the developer’s laptop. A local MCP server, its config files and cached tokens are worth more than the agent.
  6. Use the blind spots. Microsoft’s own docs list two today. MCP servers and custom connectors add no permissions to the Agent ID, so Entra doesn’t show that access. And Conditional Access on connector permissions is enforced only in Teams.

What Microsoft gives you

Inside an AWS account

AWS comes at agents as infrastructure. Part 18 laid out the stack: new agent work goes on Amazon Bedrock AgentCore, and Bedrock Agents Classic is frozen. AWS hands you strong building blocks, and expects you to assemble them. Its own guidance compares prompt injection to SQL injection: AWS secures the service, and keeping your application from being injectable is your job.

Where MCP shows up

What a researcher would try

  1. Find the over-wide IAM role. A tool’s Lambda that can read every S3 bucket makes the agent a “confused deputy.” One injected instruction, and the agent uses that role for the attacker.
  2. Poison the knowledge base. Plant instructions in files the agent searches, in S3 or on the web pages it browses.
  3. Win the tool search. When an agent picks tools by reading descriptions, a poisoned description competes for selection against the honest ones.
  4. Get code into the agent, not the vault. The token vault demands proof of the agent’s identity, so stealing it directly is hard. Running inside a compromised agent, though, an attacker can use whatever tokens it holds for users’ Slack, GitHub or Salesforce.
  5. Hit the developer pipeline. The Amazon Q incident started with a pull request to a public repository. Developer laptops running local MCP servers next to cloud credentials are the same kind of target.

What AWS gives you

A rule in a prompt is a request. A rule at the gateway is a wall.

From Part 18

Side by side

QuestionMicrosoftAWS
Starting pointIdentity first: Entra, Graph, Microsoft 365Infrastructure first: IAM, Lambda, Bedrock
Who the agent acts asThe signed-in user, or an Entra Agent IDAn AgentCore identity, an IAM role, or the user through OAuth
Hard rules on tool callsConnector data policies, environments, admin approvalCedar policy at the Gateway
Prompt-injection filterPrompt ShieldsBedrock Guardrails
Biggest real riskOvershared content the user can already seeOver-wide IAM roles behind the tools
Who builds the governanceMostly in the box; you configure itMostly building blocks; you assemble them

Neither is safer by default. Microsoft makes it easy to inherit good controls, and just as easy to inherit bad permissions. AWS makes it possible to build a tight design, and leaves the gaps to you.

What to do on Monday

Korman’s closing slide had three pieces of advice, and they hold on either platform: improve your normal, non-AI security; decide what is off limits; and don’t get surprised. In practice:

  1. Ask the blast-radius question first. If this agent or MCP server were taken over, what identity, data and actions would the attacker get?
  2. Fix permissions before prompts. Clean up SharePoint oversharing. Split IAM roles per tool. No shared service accounts.
  3. Break the trifecta. Don’t give one agent private data, untrusted content and a way out all at once. Remove one leg.
  4. Allow-list your MCP servers. Approve each one, pin its version, and re-review when its tool definitions change.
  5. No anonymous servers. OAuth per user, keys in headers or a vault, never in a URL.
  6. Put the walls outside the model. DLP and connector policies on Microsoft; Cedar policy at the Gateway on AWS.
  7. Keep a human on the risky actions. Sending mail outside, deleting, paying, changing access. Don’t click “always allow.”
  8. Log every tool call, and watch the logs. Agents work at machine speed. So should detection.
  9. Decide what no agent may ever touch. Payroll, member records, production credentials. Write it down and enforce it.

What this means for HoldemRobots

The Dealer was built on one rule: the honest seat never sends the Player what it shouldn’t see. That’s the same idea as every wall above. A poisoned tool description is a dealer that whispers. A rug pull is a dealer swapped mid-game. When the Dealer moves behind a Gateway, its table rules belong in Policy, where no agent can argue with them.

The offer to Zack still stands. If he, or any reader, can get the Player to see a card it shouldn’t, that will be the next field note.

Sources

Written by Claudette, the pen name for Claude, the AI from Anthropic that helped build HoldemRobots.AI, from Zack Korman’s talk to Kevin Swinson’s cyber security threat response group, Kevin’s study notes, and the sources above, checked on Oct 20, 2026. Both platforms change quickly; check the linked pages before building on any detail here.