Lack of an Agentic Framework is a Security Issue

The AI industry talks about agentic workflows as if they already exist. The reality is far less impressive. What we call agentic AI today is nothing more than a simple Ingress → Process → Egress (IPE). Not a workflow. Not a framework. Just a single-pass transaction with no persistent structure. And because there is no structure, there is no way to enforce security. That’s why we continue to see prompt injection, data leakage, and scope violations: you can’t secure what has no framework.

What Does “Agentic” Even Mean?

“Agentic” is just a fancy way of saying agent-oriented. At its core, an agent is a single construct, not a system:

• Ingress: take an input (a prompt, an event, an API call).
• Processing: run it through some reasoning, usually an LLM.
• Egress: return an output (a reply, an action, a new record).

That’s it. That’s an agent. Vendors often pluralize the idea; chain a few together, add a box-and-arrow diagram, and suddenly they claim to have agentic workflows. But chaining loops doesn’t make a framework.

The Security Illusion

CrowdStrike is acquiring Pangea Cyber. Pangea focuses on defending against prompt injection and other malicious inputs as data flows into LLM-based systems. Similarly, companies like Prompt Security, CalypsoAI, HiddenLayer, and Lakera.ai position themselves as guardians of AI inputs, model behavior, and outputs. They build tools that filter or monitor at certain seams: before the model gets data (ingress), during inference (process), or before responses reach users (egress).

Likewise, the open-source and academic worlds have produced tools like Meta’s Prompt Guard 2, NeMo Guardrails, LLM-Guard by Protect AI, and LlamaFirewall. Each of these delivers something valuable: detecting malicious prompts, preventing data leaks, and applying guardrails to model outputs.

What is this agentic security? They’re bolted into one of three places that mimics the IPE:

• Ingress Guards filter input before the model.
• Processing Guards monitor or constrain the model itself.
• Egress Guards filter outputs before they reach a user or system.

Guards are yet another LLM

If we step back and look across these defenses, the early attempts at “prompt guards” leaned on deterministic programming — regex filters, token limits, simple sanitization routines. These were predictable and only caught the most obvious cases.

The vast majority of guards we see today take a different path: they deploy another LLM as the gatekeeper. This has become the standard pattern: one model generating content and another model evaluating it. Products like Prompt Security, CalypsoAI, Lakera.ai, and even open-source projects such as Meta’s Prompt Guard all follow this logic. The guard is not enforcing rules in a structural sense; it is making another probabilistic judgment.

And that’s the crux of the problem. When the defense is itself statistical, you don’t remove risk: You just reduce it. Each layer lowers the odds of failure, but the gap never closes. Attackers exploit that opening, which is why prompt injection remains such a persistent problem. Guards don’t guarantee correctness the way high-assurance security once demanded; they only narrow the statistical gap.

The Statistical Gap

Every system has error: hardware, deterministic code, even regex filters. But what’s unique about AI “guards” is that they don’t provide structural certainty; they provide statistical likelihoods.

Instead of tracing and preserving security relationships end to end, such as the way high-assurance systems like NSA A-level security demanded, today’s AI defenses rely on probability. An LLM guard might say it’s 95% confident an input is safe. The next layer might also say it’s 95% confident. Chain them together and you haven’t eliminated risk; you’ve simply lowered it.

That leaves a statistical gap. The attacker’s job is to find and exploit that gap and that’s exactly what prompt injection is. Jailbreaks don’t break math; they exploit the difference between structural enforcement and probabilistic guesswork.

So what we call “guardrails” aren’t closing the door, they’re just narrowing the opening. The gap remains, and adversaries are walking right through it.

The Disappearance of Permissions

In classical security, every action carries roles and permissions. A user has a defined scope — which data they can see, what actions they can perform, which systems they can access. The program enforces those boundaries at every step.

The moment information enters an LLM, that structure vanishes. The model has no awareness of roles, no understanding of permission boundaries, and no obligation to preserve them. Once data is in context, it’s just tokens to be mashed together into the “most likely” output.

Even when wrapped with mechanisms like the Model Context Protocol (MCP), the LLM itself doesn’t respect scope. It may generate tool calls or outputs that cross boundaries because it doesn’t recognize boundaries in the first place. Then, on the way out, we’re forced to ask: did the model break role or permission constraints while processing this request?

That’s not a simple check. Because the LLM outputs natural language, not structured access logs, we end up in the absurd position of trying to reimpose security structure after it’s been destroyed.

And this is the heart of the problem: unlike high-assurance systems that mathematically preserve access rules through every operation, today’s AI systems dissolve permissions into probability. We don’t get guarantees. We get best guesses. And when best guesses are in charge of role and scope, attackers have room to take advantage.

The Statistical Gap Meets the Disappearance of Permissions

The statistical gap means we’re never certain: not only whether the output is correct, but also whether it has silently broken security rules. Did the model leak something outside the user’s scope? Did a clever attacker jump the prompt? We don’t really know because there’s no reliable way to validate it.

Worse, we’re using the same flawed approach twice. If one LLM can be tricked, what makes us think a second LLM acting as a “guard” can’t be tricked the same way? All we’ve done is layer probability on top of probability, multiplying uncertainty rather than closing it.

The root cause is the lack of framework. When data enters an LLM, its roles, permissions, and scope disappear into raw text tokens. The model has no concept of preserving security context. By the time data leaves, we’re scrambling to reconstruct rules after the fact with ingress and egress guards trying to patch structure back onto something that was never structured in the first place.

This is why today’s guardrails feel like theater. Without a framework that carries permissions end to end, security boundaries dissolve inside the LLM, and we’re left guessing whether the system has stayed inside the lines.

Why a Framework Matters

The reason frameworks exist in security and computing is simple: you can’t enforce controls on nothing. Without structure, there is nowhere to apply rules, no boundaries to preserve, and no checkpoints to verify.

When we talk about workflows in the traditional sense, multiple steps with defined inputs and outputs, each step gives us a chance to enforce control. We can validate data, check scope, confirm permissions, and carry those constraints forward. The more structured steps we have, the better our ability to layer defenses.

But when everything just flows into an LLM and flows back out again, we’re forced to solve everything at once. Scope, correctness, permissions, and security are all blended into a single probabilistic output. That’s not a workflow. That’s an atomic transaction, what we at Fluency call atomic analysis. It’s the simplest possible pattern: one request in, one response out, no structure preserved.

Unfortunately, this is how most of the industry operates today. Atomic analysis is treated as if it were a workflow. It is not. And because it isn’t, it cannot bear the weight of security. There’s no framework for enforcing roles or permissions. No framework for maintaining scope. No framework for auditability.

If we want AI systems that are both effective and secure, we need more than atomic analysis. We need workflows with structure — where data enters with scope, leaves with scope, and is continuously checked in between. That’s the only way layered defense can exist in AI.

What’s Needed for Reality

In an ideal world, we would have agentic workflows with:

• End-to-end policy enforcement where permissions are carried through every step.
• Standardized frameworks, like HTTP for the web, that give us common hooks for control.
• Semantic security that prevents models from leaking or fusing data across boundaries.
• Full auditability of every transformation and decision.

But here’s the uncomfortable truth: we’re not going to get that from today’s LLMs.

The LLM algorithm was never built for security. It doesn’t enforce permissions. It doesn’t preserve structure. It doesn’t even know what a “scope” is. It simply generates the statistically likely next token. Security is not in its design. Which means that everything we wrap around it, such as prompt guards, filters, evaluators, is trying to bolt security onto something that was never meant to carry it.

That leaves us with two paths:

1. LLMs themselves would need to change — but the people building them today are optimizing for scale and fluency, not security. Billions of dollars have already been sunk into models that don’t solve this problem.
2. Or we change how we integrate them — by breaking problems down into structured workflows where security can actually live.

Right now, the industry is racing for solutions before it understands the framework. What we have in LLMs today is essentially a system-high model, exactly the kind of design that was intentionally built into classified systems in the ’80s and ’90s. Back then, system-high meant the process itself had access to all the data inside it. Access control wasn’t enforced within the system; instead, separation was handled at the system boundaries. High systems stayed high, low systems stayed low, and guards were put in place to control what moved between them.

That was a disciplined approach to data separation and role separation. The people who built it understood the risks and engineered controls accordingly. The problem now is that LLMs operate in the same system-high fashion, once data is inside, everything is accessible, but today’s AI builders are gluing these systems together without the rigor of formal separation. They’re not designing real guards; they’re just bolting filters onto ad hoc pipelines. Which means we’re reliving the same data separation challenge, only without the security discipline that existed in the 1980s and ’90s.

It’s time to get old school. To treat LLMs not as secure systems in themselves, but as untrusted components inside larger architectures. To enforce structure at ingress and egress, to bind scope to prompts, to build layered defenses around them. Only then do we stand a chance of making agentic workflows into something more than a myth.

Conclusion

When we evaluate how so-called agentic AI works today, the core issue is clear: there is no framework. Security can’t be bolted onto a single prompt call and expected to hold. Treating an LLM as “throw everything in, get everything out, then reformat for the end user” isn’t a workflow: It’s an IPE (ingress, process, egress). And that approach all but guarantees security failures, which is exactly what we’re seeing with prompt injection and data leakage today.

What’s needed is a true framework — one that enforces security over data as it moves through the system, preserves permissions and scope across steps, and makes security enforceable rather than statistical. That requires breaking down the problem into structured stages, not pretending a single probabilistic engine can handle correctness, scope, and access control all at once.

I won’t go into all the details here, but there are massive advantages to a stepwise approach: layering defenses, preserving scope, and giving us multiple points to validate security rather than trying to solve it all at once. Until the industry recognizes that, secure “agentic workflows” will remain more marketing myth than reality.