Cybersecurity and AI: Is Our Data Safe?

So, is our data safe? A little less than we assumed. And the reason has nothing to do with rogue robots plotting against us. It has everything to do with the plumbing we are all rushing to install: the connections between AI agents and the systems that hold our data. 

That plumbing has a name: the Model Context Protocol, the standard that has quietly become the default way for agents to access tools, data, and entire company systems, which is exactly why it is also where the risk concentrates. 

But first, let's look at what happened when an AI actually broke out. 

What actually happened at OpenAI and Hugging Face

OpenAI disclosed its role in the breach on July 21, 2026. For a few days, both companies were quietly investigating the same incident from opposite ends, without realizing they were looking at the same crime scene.

The two models involved, GPT-5.6 Sol and a more capable unreleased system, were being evaluated on an internal benchmark designed to test whether an AI agent can develop working exploits for real software vulnerabilities. To measure the models' true offensive ceiling, researchers had switched off the classifiers that normally stop an agent from pursuing this kind of behavior. The models still ran within a restricted environment with no direct internet access, except for one small opening: an internally hosted package registry proxy.

That proxy was where things went wrong. According to OpenAI's incident disclosure, the models found a zero-day vulnerability in it, then chained stolen credentials with previously unknown flaws into a working remote code execution path on Hugging Face's servers. The story did not stop at one target either. OpenAI's updated disclosure confirmed that the agents broke into four accounts across four separate public services, including at least one company that had nothing to do with the original test.

Maybe the most unsettling detail is the timeline itself. Hugging Face's security team detected the anomaly and shut it down on July 16. OpenAI only connected the dots to its own internal testing days later, over the weekend of July 18 and 19, after employees started noticing signs that something had escaped its constraints. For a stretch of days, the organization best positioned to know its own AI was responsible for a live intrusion simply did not know it.

This story is not about malicious intent, but rather about a containment boundary that looked solid on paper and did not hold in practice. It illustrates how fast an evaluation sandbox can turn into a real security incident once an agent is capable enough to go looking for a way out.

The quieter risk of memory poisoning

The Hugging Face breach is loud, visible, and easy to write headlines about. A second risk, much quieter but arguably more corrosive over time, is building in parallel inside the same agents everyone is racing to deploy: memory poisoning.

Most AI agents used to reset after every session. Increasingly, they are not doing it anymore. Persistent memory, the ability for an agent to remember facts, preferences, and context across conversations, has moved from a nice-to-have to the default architecture across the industry. 

Think of it like a colleague who takes notes after every meeting and reads them before the next one. Useful, until someone starts slipping false notes into the pile. 

That is memory poisoning: an attacker writes malicious content into an agent's long-term memory, and the agent retrieves and acts on it as if it were legitimate, in every future session, until someone finds it. 

That shift opens a door nobody had really thought to lock. So much so that the global security community, after more than a year of research, has now formally classified memory poisoning as one of the top ten critical risks in agentic AI systems.

Here is why it is different, and worse, than the prompt injection everyone already worries about: prompt injection is session-scoped. An attacker slips malicious instructions into one conversation, and the damage ends when that conversation ends. Memory poisoning is not scoped to anything: an attacker writes something into an agent's long-term memory once, and the agent can act on it in every future session, for months, until someone notices and cleans it out. The write happens today; the damage can land whenever the attacker wants it to.

The research behind this is not comforting reading. The MINJA attack showed that an attacker doesn't even need privileged access to an agent's memory: ordinary, query-only conversations were enough to plant poisoned memories with an injection success rate above 95% under benchmark conditions. 

Translated into plain business terms: if you are letting an AI agent remember things about your customers, your records, or your internal processes, that memory is only as trustworthy as the door you left open for writing into it. Right now, for most systems, that door is wide open by default.

MCP: the protocol under the spotlight

Both incidents point back to the same underlying shift. AI agents are no longer isolated chatbots answering questions in a box. They reach out, connect, and act through tools, APIs, and live data connections. The Model Context Protocol (MCP) has become the standard way that reach happens. MCP is now simply how agents get to tools and data, which is exactly why it has become the attack surface that matters most going into the second half of 2026.

MCP itself is not the villain here. It is a specification, a set of rules for how a client and a server talk to each other. And by design, the protocol deliberately does not enforce security for you; it defines how clients and servers talk. That is a reasonable choice for an open standard, and also means that the real risk sits entirely in how carefully, or carelessly, an organization actually deploys it.

Where the risk concentrates

• Prompt injection and tool poisoning. An agent treats everything in its context window as trustworthy, tool descriptions included, since it was never meant to read those descriptions critically. Anyone who slips instructions inside a tool's description can steer the agent to quietly exfiltrate data through what looks, from the outside, like a completely legitimate tool call.
• Authorization and the confused deputy problem. A poorly scoped MCP server can end up acting with its own broad privileges on behalf of a user who was never entitled to that level of access, sometimes without the user approving anything at all. 
• Over-broad access and credential aggregation. Many MCP servers hold credentials for several connected systems at once and request far wider permissions than the task actually needs. One compromised server, or one leaked token, becomes a breach across everything it touches. Wide scope means wide blast radius.
• Supply chain and rug pulls. An MCP server is never just the server. It comes along with its dependencies and the infrastructure it runs on. A server may behave well during review, earning approval, and then quietly change once agents and workflows have become dependent on it, with no visible difference in how a routine call looks from the outside.
• Shadow MCP. The same story plays out with every powerful new tool: a developer stands up a server to unblock a demo, a team wires an agent to whatever endpoint is closest at hand, and nobody registers it formally. What you can't see, you can't govern, patch, or revoke.
• Command injection and sandbox escape. Plenty of MCP servers run locally, talking to the file system and spawning subprocesses. Unsanitized input passed into a shell is one of the largest classes of MCP vulnerabilities reported this year, and in the worst cases, it grants code execution with zero human approval anywhere in the chain.

The numbers behind the concern

The scale of the gap is not abstract, and it is not small. A security audit found that 25% of public MCP servers implement no authentication at all, while a further 53% still rely on long-lived static API keys, the kind of credentials that, once leaked, grant indefinite access with nothing built in to expire them. Over the same stretch, the public MCP server registry grew from roughly 1,200 entries in early 2025 to more than 9,400 by mid-2026, a sevenfold expansion of the attack surface in about fourteen months. It is no surprise, then, that 38% of organizations now name security concerns as an active blocker to their MCP adoption.

Where the protocol is genuinely getting better

None of this means MCP is something to avoid, and the picture is far from one-sided. The specification itself has hardened noticeably through 2026. In practice, this means that every agent connecting to an MCP server now has to prove its identity before doing anything, with short-lived credentials that expire and cannot be reused across different systems, instead of the static API keys anyone who intercepts can use forever.

The most recent release candidate goes further. Requests now carry what a gateway needs to inspect and enforce on every single call, instead of trusting a hidden session, and identity checks between clients and servers have tightened once again.

The direction is clear, even if the ecosystem hasn't caught up evenly yet. Dedicated identity platforms now offer purpose-built MCP authentication, dynamic client registration that allows AI clients to self-register with an authorization server rather than requiring manual provisioning for every new tool, and fine-grained, tool-level permissions instead of blanket access to everything a server can touch. This layer turns "we connected an agent to our systems" into "we connected an agent to our systems under the same identity and access rules that already govern our human users."

What Megaladata does about it

Data provenance and governance have never been side notes for Megaladata's platform, and we don’t treat MCP as an exception. For us, it is the newest version of the same familiar problem: an AI agent is only as trustworthy as the boundary drawn around what it can reach and what it can prove about what it touched along the way. The MCP server built into Megaladata Integrator ships with authentication and authorization controls by design. In practice, every connection between an agent and a Megaladata workflow gets identity-checked before a single tool call runs. 

Permissions are scoped to what a given integration actually needs rather than granted broadly by default, and access to sensitive nodes and data sources stays inside the same governed perimeter that covers the rest of the platform, from certificate validation policies down to socket-level permissions across Megaladata Server and Integrator.

That approach reflects something Megaladata has been saying for a while now: proving the origin, lineage, and integrity of data is not a technical luxury you add on top of AI adoption; it is the baseline infrastructure that makes agentic workflows safe to run at all. 

As agents move from suggesting actions to executing them with a free hand, the question is no longer just "Is this data accurate?" It is "who touched it, with what permissions, and how can we prove it?" 

The Hugging Face incident and the growing body of memory poisoning research point in the same direction from two very different angles: autonomy without governance is not innovation; it is exposure. At Megaladata, we don't see those two as opposed. Agentic AI can absolutely earn real reach into a company's data, as long as the identity, authorization, and audit layer wrapped around it is taken just as seriously as the AI itself.

Further reading:

• Data Breach 101: A Beginner's Guide
• MCP – The Model Context Protocol for AI
• Connecting to ChatGPT on the Megaladata Platform