Why Agentic Systems Are Dangerous by Design

Part 1 of the D2 Blog Series — “Authorization in the Age of Agents”

We’re at a weird point in AI. Everyone’s racing to build “agents” these autonomous systems that browse the web, read documents, run tools, and execute code.

But here’s the uncomfortable truth:
every one of those capabilities is an attack surface.

When you wire an LLM into your stack, it’s not “just calling APIs” anymore it’s now deciding what APIs to call, with what arguments, and when. That’s not intelligence that’s implicit authority. And in security, authority without verification is where things go sideways fast.

🧠 The Core Problem: Trust Bleed

Most of today’s agent frameworks (LangChain, LlamaIndex, OpenAI MCP, etc.) assume the model will follow “system prompts” like you are a helpful assistant that must never exfiltrate data.

That’s not security. That’s hope.

The moment an LLM reads from an untrusted source a document, an email, a website that source can inject malicious instructions back into the model’s context. And because the model has tool access, those injected instructions can translate directly into actions: file deletion, data leaks, money transfers, arbitrary code execution.

It’s the same pattern we’ve seen for decades:

• Prompt injections are just SQL injections, but for reasoning engines.

• You’re letting user-controlled text decide what function gets executed.

• The difference is there’s no schema, no compiler, no type system to stop it.

⚙️ Data Flow vs. Control Flow

The recent CaMeL paper from Google DeepMindnails this: every agent has two flows that can be corrupted.

1. Control flow – the sequence of actions (“find email → get attachment → send file”).

2. Data flow – the arguments passed between actions (who the email goes to, what file gets attached).

Even if you isolate the LLM so it can’t change the control flow, a malicious payload in the data flow can still hijack the execution.
Example: the model was supposed to send “meeting_notes.pdf” to bob@company.com instead it sends confidential.txt to attacker@gmail.com because that’s what the compromised notes file told it to do.

That’s not a hallucination that’s a failure of authorization design.

🔒 Why This Matters

Traditional AuthZ systems don’t model this kind of risk.
They assume functions are deterministic that only a human, not a model, decides what arguments to pass.

Agentic systems break that assumption. They blur the boundary between who decides and who acts.
Once you cross that line, you’ve moved from identity-based access control into behavior-based authorization and we don’t have good primitives for that yet.

🧩 Our Take

With D2, we started by asking:

What if authorization were enforced programmatically — not inferred through prompts or trust?

We built a system where every guarded function is checked against a cryptographically signed policy bundle before it executes — bringing authorization logic out of the model and back into code.

We call it function-level authorization.
It’s what Control Flow Integrity was to binary exploits but for AI agents.

🚀 What’s Next

In Part 2, we’ll dive deeper into why traditional RBAC and IAM models collapse in multi-agent systems — and how we’re rethinking AuthZ for environments where “the caller” isn’t human anymore.

TL;DR

• Agents introduce implicit authority every time they call tools.

• Prompt injections exploit that authority by corrupting control and data flows.

• Current “defenses” depend on model obedience, not enforcement.

• The fix isn’t prompt engineering it’s authZ by design.