If you have deployed an AI agent inside your organisation in the last six months, there is a very high chance that agent is talking to at least one Model Context Protocol server right now. If it is a Copilot Studio agent, a Claude for Work workflow, an internal build sitting on top of Amazon Q, or anything from the Cloudflare AgentSDK line, MCP is the transport. The Australian security conversation up to May was about whether agents were safe to put into production. That question has moved on. The July 2026 question is whether the MCP layer beneath them is safe, because a growing pile of public evidence says the default configuration is not.
The disclosures stacked up quickly. On 30 June, Microsoft's incident response team published a walk-through of a tool-poisoning attack chain executed against a Copilot Studio finance agent, showing how a malicious tool description could exfiltrate finance data before Prompt Shields and Entra Agent ID caught it. Two days earlier, Wiz had disclosed a CVSS 8.5 vulnerability in Amazon Q Developer where MCP configurations auto-loaded from any workspace directory, allowing a crafted repository to run arbitrary code and lift AWS credentials the moment the developer opened it. The NSA had already released Cybersecurity Information Sheet U/OO/6030316-26 in late May, treating MCP as a distinct enterprise security problem and setting hardening requirements for signed tool provenance, filtering egress proxies, and hardware-anchored token binding. Independent research from Tenet Security separately demonstrated an 85 percent success rate poisoning Sentry MCP telemetry to trick coding agents into executing attacker commands across production estates.
Now stack that against what is happening inside Australian enterprises. Delinea's 2026 Identity Security Report put 90 percent of Australian security teams under active pressure to loosen identity controls to keep AI projects moving, with 51 percent operating without a viable alternative to standing privileged access for non-human identities. One in ten said they never validate their non-human identity inventory against actual usage. This is the environment in which MCP servers are being spun up.
What MCP tool poisoning actually is
Because this term is going to appear repeatedly in board papers between now and the August reporting season, it is worth defining precisely. Every MCP server exposes a set of tools that the agent can call. Each tool ships with a description written in natural language, and the agent reads that description as part of its instructions. Tool poisoning is the class of attack where an adversary controls or modifies the description, embeds prompt-level instructions inside it, and the agent follows those embedded instructions as if they came from its principal.
The Microsoft finance agent proof of concept was clean. A tool description carried a hidden instruction telling the agent to package sensitive transaction records and post them to an attacker-controlled endpoint before responding to the user. The agent obeyed. The user saw an ordinary response. The exfiltration happened silently. Microsoft's mitigation stack, Prompt Shields at the model layer and Entra Agent ID at the identity layer, blocked it in their test environment. In an environment that had deployed Copilot Studio without either, it would not have.
The pattern generalises. Any surface where an agent reads text that could carry instructions is an injection surface. Tool descriptions are one. Data returned by a tool call is another. Documents ingested by a retrieval step are another. The Sentry incident showed how ordinary observability data can be weaponised: telemetry the agent trusts as diagnostic input becomes the injection payload. MCP does not create this class of attack, but it centralises it into the tool description field where a supply-chain compromise of a single popular MCP server can reach across every organisation that connects to it.
Why the NSA CSI matters more than the average agency paper
The NSA guidance is unusual in two ways. It treats MCP as an infrastructure protocol worth naming and analysing directly, not as an incidental artefact of an AI system. And it reads like a hardening checklist written by someone who has already done incident response on this technology. The seventeen pages come down to four ideas that a CIO or CISO can act on without waiting for a broader regulatory response.
The first is provenance. The CSI wants every tool an agent can discover to carry a signed identity anchored, where possible, in a hardware root. Discovery without signature checks is the Amazon Q pattern, and it is how a poisoned tool ends up in the agent's context in the first place.
The second is egress control. The recommendation is a filtering outbound proxy for every external MCP connection, with resource URLs pinned tightly enough that even a compromised tool cannot post to a novel destination. In Australian terms, this is the same architectural discipline the ACSC's Essential Eight expects around outbound network flows, applied to an interface almost no organisation has an outbound policy for yet.
The third is least-privilege token binding. Every tool call should ride a token scoped to the specific action, not a long-lived credential that grants the agent everything the user can do. This directly addresses the Delinea finding on standing privileged access. If your MCP tools currently run on a service principal that inherits the identity of the human operator, you are one tool poisoning event away from an incident that spans everything that identity can touch.
The fourth is observability. Every tool invocation, every parameter, every returned payload, and where feasible a hash of the result, needs to be logged in a way you can query in a post-incident review. This is not aspirational. If your MCP servers today do not emit invocation logs the SIEM can ingest, you will not be able to investigate the first agent incident you experience.
The July 28 specification revision and why it matters this month
The MCP protocol itself is moving. The 2026-07-28 revision, in candidate release status through July, is the largest rewrite since the protocol launched. Two changes will shape enterprise deployment.
The protocol goes stateless. Sessions are removed at the transport layer. Any server instance can service any request, and the whole class of session-hijacking issues associated with sticky sessions and shared session stores disappears. For an enterprise, this is a positive change. It also means the identity assertion travelling with each request has to carry more weight, because there is no longer a session context on the server side to bind to.
Elicitation becomes formal. Servers can now pause execution and prompt the calling user for input, including through URL-mode elicitation that punts high-risk interactions (OAuth flows, credential entry, payment authorisation) out of the agent context into a trusted external browser session. This is the mechanism that makes it safe to let an agent initiate an action that requires human authorisation without giving the agent the credentials to complete it. If your Copilot Studio and Claude deployments are still doing OAuth inside the agent conversation, you will want to plan the migration to URL-mode elicitation before your legacy servers hit the twelve-month deprecation window.
Enterprise-managed authorization went stable on 18 June. Here is why to move now.
Alongside the specification rewrite, MCP's Enterprise Managed Authorization extension went stable on 18 June. This is the piece that lets your identity provider (Okta, Entra, Ping) issue a signed identity assertion, the ID-JAG, that an MCP server verifies in a single round trip. The end user experience is zero-touch single sign-on. The security benefit is that you stop scattering per-user OAuth consent grants across every MCP server your workforce touches, and you regain the ability to revoke access centrally.
For an Australian enterprise juggling a Microsoft-anchored fleet and a growing set of third-party MCP servers built by internal engineering teams and external partners, ID-JAG is the connective tissue that lets governance survive contact with the actual production estate. Without it, every new MCP server is a new consent surface, and the OAIC-facing question of "who granted this agent access to that record store, when, and with what scope" does not have a clean answer.
What Australian enterprises should be doing before the end of Q1 FY27
The technical calendar and the fiscal calendar have converged uncomfortably. FY27 is now live. The June 30 Microsoft disclosure and the Wiz Amazon Q disclosure landed inside the same fortnight that most Australian enterprise IT teams sign off their FY27 security roadmap. Six moves put the estate in a defensible position without a six-figure procurement cycle.
Build an MCP inventory. Not "we have Copilot Studio and Claude for Work". A tool-level inventory: every MCP server your workforce or your agents are connected to, who owns it, whether it is vendor-native, third-party, or internally built, what identity it authenticates under, and what egress destinations it can reach. Ninety percent of Australian organisations do not have this today.
Pin egress. Every internal MCP server should sit behind a filtering proxy with an allow list. External MCP connections should be explicitly allow-listed at the same layer. The ACSC guidance on agentic AI already treats this as a baseline expectation. The NSA CSI treats it as a control. Between the two, there is enough external air cover to fund the work.
Move to Entra Agent ID (or its Okta equivalent) for every production agent. The Microsoft Copilot Studio finance agent proof-of-concept mitigation depended on an Entra Agent ID token pinning the agent's identity to a specific workload. If your agents currently borrow the human user's identity to call MCP tools, you inherit every permission that human has, and every audit log records the human as the actor. Neither of those is the position a CISO wants to explain to ASIC after an incident.
Roll enterprise-managed authorization. Once ID-JAG is live in your identity provider, migrate MCP servers off per-user OAuth. The migration is not trivial, but the payoff is that the OAIC-facing question about scope, consent, and revocation gets a straight answer.
Instrument tool poisoning detection. Detection is possible. Anomalous tool descriptions, unexpected data-exfiltration destinations in tool response payloads, and mismatches between the tool description and the tool's actual behaviour are all detectable. Vendor tooling is beginning to ship for this (Prompt Shields, Palo Alto's agent firewall, Wiz's runtime agent coverage). Pick one and integrate it now, ahead of a wave of similar disclosures in Q3.
Rehearse the incident. Assume tomorrow you learn a popular MCP server your engineering team connected to Claude for Work was compromised for the last four weeks. Which repositories are affected? What data left the environment? Which staff were logged in via which principal? If you cannot answer these questions in a tabletop exercise, you cannot answer them under pressure. The MCP tool invocation log is the artefact you need. The first tabletop is the cheapest place to discover you do not have it.
Where this leaves the Australian security conversation
The July 6 ACSC-anchored conversation about agentic AI security was correct at the level it operated on. Australian enterprises are advancing agents faster than they are hardening the environment around them. What the last two weeks of disclosures have added is a specific place to point. The gap is not diffuse. It is concentrated at the MCP layer. That is where tool poisoning happens, where auto-execution vulnerabilities land, where per-user OAuth grants proliferate, and where the next Australian enterprise incident is most likely to originate.
Wai's ARC platform is one of the layers organisations use to make the MCP estate discoverable and governable, both to the security team and to the AI systems that need to reason about it. The broader point stands regardless of what tooling an organisation chooses. Every AI agent in production runs through MCP. The July 28 spec revision is going to change how it authenticates, how it maintains context, and how it elicits authorisation from a human. The organisations that build governance around the protocol now will spend FY27 shipping agents. The ones that do not will spend FY27 explaining incidents.
FAQ
What is MCP tool poisoning? Tool poisoning is an attack where an adversary controls the text description of a Model Context Protocol tool that an AI agent will read. The description carries hidden instructions the agent obeys as if they came from its principal, typically to exfiltrate data or execute actions the user did not authorise. Microsoft demonstrated this attack chain against a Copilot Studio finance agent on 30 June 2026.
Is Model Context Protocol secure for enterprise use? MCP is safe to deploy in an enterprise if it is hardened. Out of the box it is not. The NSA Cybersecurity Information Sheet U/OO/6030316-26 sets baseline controls (signed tool provenance, filtering egress proxies, least-privilege token binding, invocation logging) that need to be in place before a production deployment.
What does the NSA say about MCP security? The NSA CSI, released in May 2026, treats MCP as a distinct enterprise security surface and prescribes four control families: provenance for tool discovery, controlled outbound network flows, per-action tokens rather than long-lived credentials, and comprehensive invocation logging.
How do I harden MCP servers in production? Inventory every MCP server. Pin egress destinations behind a filtering proxy. Bind every tool call to a per-action token issued by an identity provider that supports agent identity (Entra Agent ID or its Okta equivalent). Migrate to enterprise-managed authorization once ID-JAG is available in your IdP. Log every tool invocation to a SIEM you can query.
What changed in the MCP 2026-07-28 specification? The protocol became stateless at the transport layer, removing sessions and eliminating a class of session-hijacking vulnerabilities. Elicitation was formalised, including URL-mode elicitation that pushes OAuth and credential entry outside the agent conversation into a trusted external browser context. Legacy versions receive a twelve-month deprecation window.
How does MCP enterprise-managed authorization work? The identity provider (Okta, Entra, Ping) issues a signed identity assertion known as an ID-JAG. The MCP server verifies the assertion in a single round trip, granting the agent access without the per-user OAuth consent screen. The extension reached stable status on 18 June 2026.
What is the Amazon Q MCP vulnerability? Amazon Q Developer auto-loaded MCP configurations from any workspace directory without user consent, allowing a crafted repository to inject a malicious MCP server, execute arbitrary code, and exfiltrate AWS credentials the moment the developer opened the workspace. Wiz disclosed the issue at CVSS 8.5 in late June 2026, and the vulnerability was patched shortly after.
Should we let AI agents use MCP servers? Yes, once the environment is hardened. MCP is now the default transport for enterprise AI agents. Blocking it entirely is not a viable strategy for an organisation that intends to run agents in production. Deploying it without the NSA control set is the higher risk position.
How do you audit AI agents using MCP? Every tool invocation, every parameter, every returned payload, and a hash of the response should be logged in a format your SIEM can ingest. Without this artefact, incident investigation on an agent estate is not possible.
What is the difference between vendor-native and third-party MCP servers? Vendor-native MCP servers (Salesforce, Microsoft, ServiceNow) are built and maintained by the platform vendor and typically integrate with the vendor's own identity and audit stack. Third-party MCP servers are built by internal engineering teams, partners, or open-source communities. Third-party servers are where most of the disclosed vulnerabilities have originated, and they need tighter provenance and egress controls than the vendor-native equivalents.
How should Australian enterprises govern MCP servers? Treat the MCP estate as regulated infrastructure. Maintain a tool-level inventory. Apply the NSA CSI control set. Move to Entra Agent ID or its Okta equivalent for every production agent. Rehearse the tool poisoning incident tabletop before Q3 FY27, when disclosure volume in this area is expected to rise.