COMMENTARY: AI risk is not just another problem to point out. It also creates real work for MSSPs around assessment, design, and fixes. Breaking it into three gaps: input validation, access control, and containment makes the conversation clearer. That matters because many customer discussions are still too broad, and many partner services are too.
Between mid-2025 and April 2026, security researchers disclosed six critical AI vulnerabilities across platforms most enterprises rely on daily:
EchoLeak and
Reprompt in Microsoft Copilot,
ForcedLeak in Salesforce Agentforce,
GeminiJack in Google Gemini Enterprise,
GrafanaGhost in Grafana, and a
supply chain attack on the OpenAI plugin ecosystem that ran undetected for six months across 47 enterprises.
The industry has lumped these together under a single narrative: AI needs better guardrails and data access controls. That framing is incomplete, and the gap it creates is where the next incident will live. For service providers and security teams, this creates a dangerous mismatch between how AI risk is being sold and how it actually manifests. These six disclosures contain three distinct failure patterns. Most organizations are addressing one. Almost none are addressing all three.
Pattern one: untrusted input processed as trusted AI context
Every vulnerability in this series starts the same way. External data enters a system through a legitimate channel — an email, a shared document, a web form submission, URL query parameters, Docker image metadata — and an AI component later processes it without treating it as adversarial.
EchoLeak's payload was a crafted email that Copilot ingested as context during a routine query. GeminiJack's was a poisoned Google Doc indexed by Gemini's RAG system. ForcedLeak's was text hidden in a 42,000-character Web-to-Lead form field. GrafanaGhost's was URL query parameters stored in Grafana's event monitoring logs. In every case, external data that had been stored internally was subsequently treated as trustworthy by an AI component.
The principle that external input must be validated before any system processes it is foundational to web application security. We build WAFs around it. We train developers on it. Nobody applied it to AI-processed data — because nobody thought of emails, shared documents, and event logs as input channels for AI prompt injection.
This is the most consistent failure across all six vulnerabilities, and it is the one the industry is largely ignoring. Data access controls do not address it. Model-level guardrails do not address it. It requires input validation discipline extended to every data source AI touches.
Pattern two: overly broad AI data access without per-operation enforcement
Five of these vulnerabilities — EchoLeak, Reprompt, GeminiJack, ForcedLeak, and the OpenAI plugin attack — involve AI systems operating on behalf of a user with broad, implicit data access and no per-operation policy enforcement. The AI authenticated once at session or connection level, then accessed whatever it could reach.
Copilot accessed everything in OneDrive, SharePoint, and Teams. Gemini swept across all Workspace data sources. Agentforce queried the entire CRM. The OpenAI plugin attack used compromised credentials across 47 environments for six months. In each case, the injected instructions caused the AI to retrieve data far beyond what any user intended — and nothing evaluated each individual retrieval against policy.
Per-operation access control — authenticating each request independently, evaluating attribute-based policy on every operation, isolating credentials from the AI's accessible context, and logging every access with complete attribution — would have constrained the blast radius in each of these five cases. This is the data access governance gap, and it is the pattern the industry has been discussing. It is real and urgent.
But it applies to five of the six. Not all of them.
Pattern three: process containment and functional scoping failures
GrafanaGhost is architecturally different from the other five, and treating it as another data access control problem misreads the vulnerability.
Grafana has RBAC on user-facing data access. GrafanaGhost never triggered it. The attack never operated on behalf of any user.
The attack hid AI instructions in URL query parameters that Grafana's event monitoring logged as routine traffic. Trusted back-end enrichment processes — running with system-level privileges, designed to correlate and prepare data for dashboards — later analyzed those events and unknowingly executed the hidden prompt. The AI built a dashboard nobody requested, embedded sensitive data in image tags, and made them externally accessible.
Noma's researchers found that the keyword "INTENT" collapsed the AI's guardrails entirely.
The back-end process needed broad data read access to do its job. What it did not need was the ability to call routines that render dashboards, generate image tags, or make outbound requests to external servers. Those are output capabilities the process was never designed to use — but nobody actively prevented it from accessing them.
The OpenAI plugin attack is also a pattern-three failure: agent credentials were accessible to compromised plugin code because authentication tokens were not stored outside the AI's accessible context.
Least privilege must apply to functional scope — which APIs, rendering routines, and output channels a process can invoke — and to credential storage, not just to data access. This is the containment gap, and it requires a different architectural response than data access governance.
Model-level guardrails failed across the board — but that is the symptom, not the cause
Grafana's guardrails were defeated by a single keyword. Salesforce's content security policy was bypassed with a five-dollar expired domain. Google Gemini could not distinguish a poisoned document from a legitimate one. Microsoft Copilot's safety features could not prevent a crafted email from hijacking its context window.
Model-level guardrails are configuration settings inside the system being attacked. They are a useful defense layer. They do not substitute for input validation (pattern one), per-operation access enforcement (pattern two), or process containment (pattern three).
What security leaders should do — all three patterns
For input trust boundaries: audit every data source AI processes. Emails, shared documents, form submissions, event logs, API responses, metadata fields. If external data feeds into any system where an AI component processes it, treat that input as adversarial — regardless of how deep inside the system it has been stored. Apply the same validation discipline you apply to web-facing user input.
For data access scoping: require per-operation authentication and attribute-based access control for every AI data request operating on behalf of a user. Store credentials outside the AI's accessible context. Produce tamper-evident audit trails with complete attribution feeding your SIEM. This directly addresses EchoLeak, Reprompt, GeminiJack, ForcedLeak, and the OpenAI plugin attack.
For process containment: scope back-end AI processes to only the functional capabilities they require. Broad data read access may be necessary. The ability to render content, generate outbound requests, or build user-facing dashboards is not. Constrain what processes can
do, not just what data they can
access. This directly addresses GrafanaGhost.
For all three: red-team your AI integrations for all three patterns — not just prompt injection through user-facing channels, but injection through event data, log entries, and metadata consumed by back-end processes. The
Agents of Chaos study from February 2026 documented AI agents destroying infrastructure and disclosing personal data in live environments. Both failure modes are present in production systems today.
The patches are in. The three architectural gaps are not. The next variant will exploit whichever pattern you left unaddressed.
What this means for MSPs and MSSPs
AI risk is being mis-scoped as a guardrail problem. For managed and security service providers, this creates both a business opportunity and a responsibility to reframe what customers are actually buying. These three failure patterns map to three service gaps that most customers are not filling — and most partners are not offering.
AI input validation audits. Identifying every data source an AI component processes and applying adversarial-input discipline is foundational — and almost universally absent. Most customers have no inventory of which inputs feed their AI systems, let alone a validation posture for them. This is a repeatable audit and remediation service for MSPs with application security practices.
Per-operation access governance design. Broad AI data access is the default configuration across major enterprise platforms. Designing and implementing per-operation enforcement — attribute-based controls, credential isolation, tamper-evident audit trails feeding a SIEM — requires architectural work that most customers lack the internal capacity to perform. This is a high-value design and deployment service opportunity.
AI process containment architecture. Scoping back-end AI processes to the minimum functional footprint they require is a design problem, not a configuration toggle. It requires evaluating what each process needs to do — not just what data it can access — and constraining its output and API surface accordingly. Partners who can deliver this are addressing risk that customers will not recognize until they are breached.
Most customers are currently buying controls that address one of these three patterns. Partners who can scope and deliver all three are addressing risk their customers don’t yet know they have — which is where the most durable service relationships are built.
MSSP Alert Perspectives columns are written by trusted members of the managed security services, value-added reseller and solution provider channels or MSSP Alert's staff. Do you have a unique perspective you want to share? Check out our guidelines here and send a pitch to [email protected].
