Notifications
Clear all
Topic starter
02/08/2026 12:31 pm
TL;DR: Model Context Protocol context poisoning can redirect an autonomous AI agent from legitimate work to data export, tool misuse, and role drift without triggering traditional API alarms because the calls still look valid, according to Salt. The real governance gap is that security teams often review actions after execution, while agent context can change the action plan before anyone sees it.
NHIMG editorial — based on content published by Salt: LLMs, MCP, and how attackers can hijack AI agents using compromised NHIs
Questions worth separating out
Q: How should security teams govern AI agents that can change actions at runtime?
A: Security teams should govern runtime AI by correlating identity, data, and intent before trusting an action path.
Q: Why do valid API calls not guarantee that an AI agent is behaving safely?
A: Because each call can be individually authorised while the overall sequence is malicious.
Q: What breaks when an AI agent’s role can be rewritten during a session?
A: Static privilege models break because they assume the actor’s purpose is known at provisioning time and remains stable.
Practitioner guidance
- Protect agent context as a governed asset Classify the agent’s goal, tools, role, memory, and constraints as part of the control surface and track changes to those attributes as you would identity privilege changes.
- Baseline normal agent behaviour Record expected tool sequences, data destinations, and role boundaries for each agent so that deviations such as new databases, new export paths, or unfamiliar destinations are detectable.
- Limit the blast radius of each agent Scope each autonomous agent to the minimum viable dataset and tool set, and separate read, transform, and export functions so that a poisoned context cannot immediately exfiltrate records.
What's in the full article
Salt's full article covers the operational detail this post intentionally leaves for the source:
- How the article maps agent context into goal, tools, role, memory, and constraints.
- The practical logic behind detecting role drift and behaviour change in autonomous systems.
- The article’s framing of API baselining as a way to connect actions back to intent.
- Salt’s own discussion of discovery, posture governance, and run-time threat protection for AI and MCP environments.
👉 Read Salt's analysis of MCP context poisoning and AI agent risk →
MCP context poisoning for AI agents: are your controls keeping up?
Explore further
02/08/2026 1:29 pm
Context integrity is now an identity control, not an application detail. When an autonomous agent can change from one business role to another through poisoned instructions, the real attack surface is the decision context that precedes each action. IAM teams that only govern authenticated access miss the fact that the agent’s purpose can be rewritten while permissions remain valid. The implication is that agent context must be governed as part of the identity state, not treated as disposable prompt text.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: What is the difference between API security monitoring and agent governance?
A: API security monitoring focuses on the requests that reach systems, while agent governance also evaluates the intent, role, and tool use that produced those requests. For autonomous systems, that difference matters because a clean API log does not prove the mission was legitimate.
👉 Read our full editorial: MCP context poisoning is the new attack surface for AI agents
