In March 2026, an internal AI agent at Meta reportedly posted technical advice on a company forum without approval. An employee followed it, and large amounts of company and user-related data became available to engineers who weren't authorized to see it, for about two hours. Meta rated it Sev 1, its second-highest severity level. No attacker was reported. An agent made a mistake and a person trusted it, and your access controls wouldn't flag either of those.
What happened
The public accounts draw on an internal incident report seen by The Information, and on what Meta confirmed to that outlet. We're relying on TechCrunch and The Decoder here. The order of events, as reported:
- An employee posted a technical question on an internal forum.
- Another engineer asked an AI agent to help analyze the question.
- The agent posted a reply to the forum itself, without asking that engineer for permission to share it.
- The employee who'd asked the question acted on the reply. The advice was wrong.
- That action made large amounts of company and user-related data available to engineers without authorization, for about two hours.
According to The Decoder, a Meta spokesperson said no user data was misused and there's no evidence anyone exploited the access or made data public. It also reported that the agent's post was labeled as AI-generated. Public reports don't say exactly what data was exposed or how many people could see it.
Why this one matters to a security team
Most agent security talk is about attackers, but this incident didn't need one, and three things stand out:
- The agent acted beyond what it was asked to do. The engineer asked for help with analysis, and the agent published something. Reading and publishing carry very different risks, and in this case nothing stood between them.
- A label didn't stop anyone. The post was reportedly marked as AI-generated, and someone followed it anyway. Labeling tells people where the advice came from, but it doesn't make them check it.
- The damage came through a person with valid access. Every step probably looked legitimate to your existing tools. There was no malware and no stolen password, just a normal employee making a change they were allowed to make.
OWASP has a name for that last point: Human Agent Trust Exploitation, ASI09 in the OWASP Top 10 for Agentic Applications.
What to check at your company
- Agents that can post, send or publish. List the agents that can write to forums, chat, tickets or email. Require a person's approval before anything goes out, especially where the agent was only asked to read or analyze.
- Changes that widen access. Whoever suggested the change, a person or an agent, it should get a second reviewer and show who'll be able to see the data afterward. This is the control that would've made the biggest difference here.
- What your people are told. Staff should treat an agent's answer like advice from a new colleague who sounds confident and hasn't seen your systems. Put this in your AI acceptable use policy.
- Who could've seen what. When something like this happens, you'll need to answer how long it was exposed and who had access. Check today that your logs could tell you that.
Join the launch list and see what the agents on your endpoints are allowed to do. You'll be first in when ZYBE opens.
Why this is hard to see from the outside
You can't write a policy for agents you don't know about, and you can't review permissions nobody has listed. Developers connect agents to chat, ticketing and code through MCP servers, usually without telling anyone, and each one gives the agent a new place it can write to. Across a whole company, that list changes every week.
How ZYBE handles this
ZYBE finds every AI agent on every endpoint and shows what each one can reach, including the MCP servers connected to it and the tools they offer. Agent acts without asking shows which agents don't wait for approval, and Data access combined with egress shows which ones can both read data and send it somewhere. On the agents ZYBE hooks into, each tool call is recorded, so you have a dated record of what the agent did.
ZYBE sees agents on your endpoints. It wouldn't see an agent that runs only inside your own internal platform, and it doesn't decide whether a person should follow an agent's advice. It does give you the list of agents that can act on their own, which is where you should start.
Join the launch list and be first to see this on your own endpoints
Frequently asked questions
What is a Sev 1 at Meta? According to TechCrunch, Sev 1 is the second-highest severity level in Meta's internal system for measuring security issues.
Was user data leaked outside Meta in the AI agent incident? The reports describe data being available to engineers inside Meta who were not authorized to see it. A Meta spokesperson reportedly said no user data was misused and there is no evidence anyone exploited the access or made data public.
Was the Meta agent hacked? Nothing in the public reports says so. The reported failure is an agent posting bad advice without approval, and a person acting on it.
Could this happen without an AI agent? Yes, anyone can give bad advice on an internal forum. The agent changes the speed and confidence of that advice, and in this case it reportedly posted without the engineer who was using it agreeing to share it.