Agentic AI in the wild and where the security gaps are showing

A support chatbot, designed to help people recover their accounts, got talked into helping attackers take over accounts instead. That’s the short version of what happened with Meta’s AI assistant. No zero-day. No clever memory corruption. Just a conversation, pointed in the wrong direction by someone who understood that the helpful thing in the middle had real authority and very fuzzy judgment.

Hear me out on why that small incident matters more than it looks. It isn’t a one-off embarrassment for one vendor. It’s an early, clean example of what “deployed agentic AI” actually exposes when it meets a determined human.

The shape of the attack surface right now

The Meta case isn’t a traditional exploit chain. It’s social engineering, but the mark isn’t a tier-one support rep having a rough Tuesday. The mark is a language model with tools wired into account systems. The attacker didn’t need to break the model. They needed to convince it.

That’s a different category of problem than most security programs are organized around.

Support and workflow agents are unusually attractive targets for a reason I keep coming back to: they sit in between users and privileged systems, and the trust boundary is fuzzy on purpose. The whole point of the agent is to be helpful across that boundary. The whole point of an attacker is to abuse exactly that helpfulness. The interests are structurally opposed in a way that a password reset form, for all its flaws, never quite was.

The pattern under all of this: agents tend to inherit the authority of the systems they’re wired into, but not the scrutiny. A human support agent has a manager, a QA process, a coaching loop, maybe a recorded call. An LLM agent has a system prompt and a hope.

So the question I want to sit with for the rest of this post is pretty simple. What does defense look like when the vulnerable component is a language model holding tools?

What attackers are starting to build

The Meta incident is the boring, expected end of the spectrum. The interesting end is what researchers are prototyping.

There’s already a proof of concept for an AI-powered worm that carries its own LLM and executes it on compromised hosts. Read that twice. The malware doesn’t phone home for instructions. It reasons about its environment locally. It can look at what it’s landed on and decide what to do next, in language, on the box.

Operationally, that breaks a few quiet assumptions. Signature-based detection assumes static logic. Behavioral detection assumes the behavior, while variable, comes from a relatively bounded decision tree the attacker wrote in advance. Adaptive on-host reasoning doesn’t really fit either bucket. The “behavior” is generated fresh, per host, by a model that’s been told what outcome to drive toward.

Now layer on the enterprise context. Long-running AI agents are becoming normal inside corporate networks. Codex deployments running for hours. Persistent cloud workspaces for agentic work, the kind that OpenAI’s Ona acquisition is meant to expand. This is not a complaint about those products. It’s an observation about the baseline. If LLM processes living inside your environment, making outbound calls to model endpoints, are now expected, then “an LLM process living inside your environment, making outbound calls” stops being a useful anomaly signal.

Let’s be honest: a prototype worm is not a widespread threat yet. It’s a research artifact. But research artifacts are how defenders get told, politely, where to look next. Pretending the direction isn’t real because the volume isn’t there yet is how teams end up surprised.

The same capability, pointed the other way

I want to balance this, because the picture isn’t only grim.

A critical vulnerability in Zcash’s Orchard privacy pool was surfaced with help from Claude Opus 4.8. That’s not “AI generated a plausible-sounding bug report.” That’s a capable model contributing to real vulnerability discovery in genuinely hard cryptographic code. On the smaller, almost charming end of the same capability curve, ML is being used to decrypt historical pencil-and-paper ciphers. Different stakes, same underlying thing: models are getting uncomfortably good at finding structure in adversarially designed systems.

Here’s the asymmetry to sit with. The same reasoning that finds bugs for a defender finds them for an attacker. The gap between the two uses is mostly intent and access. That’s it. There isn’t a separate “good model” and “bad model” sitting on a shelf somewhere. There’s the model, and the question of who’s holding the keyboard.

The practical implication, in my read, is that integrating capable models into review workflows is starting to look less like an experiment and more like table stakes. If you don’t have an LLM reviewing your code, configs, and threat models, someone else’s LLM is going to be reviewing them, eventually, from the outside.

Defensive moves that actually fit agentic systems

I’ll be upfront: there isn’t a mature playbook here. Most of what I’m about to suggest is older paradigms, adapted. That’s a feature of being early, not a sign anyone has this solved.

A few things that, in my experience, are reasonable starting points:

Treat agents as privileged service accounts, not as users and not as code. Scoped credentials per agent. Per-action authorization where the agent has to actually request the capability it’s about to use. Audit trails on tool calls, not just on the final outward effect. If you can’t reconstruct which tool calls the agent made and why, you don’t really have observability, you have logs.

Assume the model can be socially engineered. The Meta case is the existence proof. Put your real trust boundary at the tools and data the agent can reach, not at the prompt. Prompt hardening is fine, but it’s the seatbelt, not the brakes. The brakes are whether the account-recovery tool will actually do the dangerous thing when the agent asks nicely.

Start thinking about LLM-shaped processes on endpoints. Given where the worm prototypes are heading, outbound traffic to model endpoints from places it shouldn’t originate is probably worth a detection. So is the presence of model weights or runtime libraries on hosts that have no business running inference. I’d hedge this one heavily, because the baseline is moving fast and what’s suspicious today will be normal next quarter. But it’s worth at least naming the signal before it’s drowned in legitimate noise.

Use capable models in your review loop. Code review, config review, threat modeling, IAM policy review. Not as the decider. As the tireless first reader. In the small engagements I’ve done with this pattern, the value isn’t usually a dramatic catch. It’s the consistency. The model doesn’t get bored on page forty of a policy document.

And finally, the honest one: acknowledge what’s unsettled. I’d be skeptical of anyone selling you a finished “agentic AI security” program right now. The controls that exist are mostly thoughtful adaptations of identity, endpoint, and SDLC controls we already had. That’s not nothing. It’s also not a category that’s done evolving.

What I keep coming back to is that agentic systems are, at the same time, the new attack surface, the new attacker, and the new defender. The Meta chatbot is the surface. The prototyped worm is the attacker. The Zcash review is the defender. All three are the same underlying technology, deployed with different intent.

So the question I’d leave you with isn’t strategic, it’s specific. The agentic system you’ve already deployed, or the one your vendor quietly turned on inside a product you bought last year… which of those three roles is it playing in your environment today?

And are you sure?