Uchi Uchibeke

· Security

I Forked ByteDance's DeerFlow at 3 AM to Add Pre-Execution Authorization

Eight minutes from noticing the missing authorization hook to opening PR #1240: 1,033 lines across 11 files that authorize every tool call before it runs.

When you hear "AI agent framework from ByteDance," you think production-ready, enterprise-grade, battle-tested. You do not think "pre-execution authorization." You should.

At 3:03 AM ET, I forked ByteDance's DeerFlow. By 3:06 AM, I had opened PR #1240: feat/guardrail-middleware. Three minutes. That is how long it took to add the security layer missing from one of the most popular AI agent frameworks in use today.

This is not about finding vulnerabilities. It is about a pattern: we are building AI agents that can act on our behalf, and we are not building the authorization systems that should govern those actions. The gap is in the integrity, not the intelligence.

TL;DR

  • DeerFlow 2.0 is ByteDance's SuperAgent harness: sub-agent orchestration, long-term memory, sandboxed code execution, skills. It has middleware for everything except authorization
  • At 3:03 AM ET, I forked it. At 3:06 AM, I opened PR #1240: 1,033 lines across 11 files that intercept every tool call
  • The pattern: pluggable providers, then pre-tool-call authorization, then fail-closed by default
  • Of the seven agent frameworks I reviewed in 48 hours, six have the same gap
  • Vendors are shipping monitoring for agents that can already act without permission. 47% of CISOs have watched an agent do something it should not have

The 3 AM fork

DeerFlow is impressive. ByteDance built a harness that handles tool calling, memory, planning, and execution across multiple models. It is clean, well documented, and genuinely useful.

Here is what I noticed at 3 AM when I should have been sleeping: every tool call in DeerFlow goes straight to execution. There is no hook, no checkpoint, no authorization layer between "the agent decided to do this" and "the agent did this."

The timeline:

  • 2:58 AM: reading through DeerFlow's tool execution flow
  • 3:01 AM: realizing there is no authorization hook
  • 3:03 AM: fork created
  • 3:04 AM: middleware scaffold written
  • 3:06 AM: PR #1240 opened
  • 3:08 AM: tests written for the middleware
  • 3:12 AM: documentation updated

Eight minutes from realization to pull request. The receipts:

# The fork timestamp
$ git log --oneline -1
03b0fee (HEAD -> feat/guardrail-middleware) feat(guardrails): add pre-tool-call authorization middleware with pluggable providers

# The PR opened 3 minutes later
$ gh pr view 1240 --json title,state,createdAt
{
  "title": "feat(guardrails): add pre-tool-call authorization middleware with pluggable providers",
  "state": "OPEN",
  "createdAt": "2026-03-22T07:06:32Z"  # 3:06 AM ET
}

The missing middleware

In DeerFlow's architecture, middleware executes in strict order. Each tool call passes through this chain:

Request → Input Validation → Context Enrichment → Tool Selection → ??? → Execution → Output Formatting → Response

See the gap? Between "Tool Selection" and "Execution" is where authorization should live. It does not.

Here is what the middleware directory looks like:

middleware/
├── input_validation.py
├── context_enrichment.py
├── tool_selection.py
├── execution.py
├── output_formatting.py
├── logging.py
├── monitoring.py
└── state_persistence.py

No authorization.py. No guardrail.py. No pre_action_check.py. Every middleware in that list handles infrastructure: logging, monitoring, state persistence, context enrichment. None handles authorization.

The 1,033-line fix

Here is the guardrail middleware architecture I added, from the PR description:

# deerflow/guardrails/middleware.py
"""
GuardrailMiddleware for DeerFlow 2.0
Position 5 in the middleware chain, intercepts tool calls for pre-action authorization.
"""

from deerflow.guardrails.provider import GuardrailProvider, GuardrailRequest, GuardrailDecision

class GuardrailMiddleware:
    """Middleware that checks authorization before tool execution."""

    def __init__(self, provider: GuardrailProvider):
        self.provider = provider

    async def awrap_tool_call(self, tool_call, context):
        """Intercept tool call for authorization check."""

        # Create authorization request
        request = GuardrailRequest(
            tool_name=tool_call.name,
            tool_arguments=tool_call.arguments,
            agent_id=context.agent_id,
            thread_id=context.thread_id
        )

        # Call provider (pluggable: AllowlistProvider, OAP provider, or custom)
        decision = await self.provider.aevaluate(request)

        if not decision.allow:
            # Fail-closed: block unauthorized tool calls
            raise PermissionError(
                f"Authorization denied: {', '.join(r.message for r in decision.reasons)}"
            )

        # Tool call proceeds to execution
        return await self.next.awrap_tool_call(tool_call, context)

The provider verifies that the agent's passport is valid and active, checks the tool against the passport's authorized list, and writes a signed decision receipt before the call is allowed through. The decision is logged before execution, not after it.

The pattern is pluggable:

  1. Provider interface: any class can implement GuardrailProvider
  2. Built-in option: AllowlistProvider (zero dependencies, deny specific tools)
  3. OAP option: open standard for AI agent passports
  4. Custom option: your own authorization logic

From the PR config example:

guardrails:
  enabled: true
  provider:
    use: deerflow.guardrails.builtin:AllowlistProvider
    config:
      denied_tools: ["bash"]  # Simple allowlist/denylist

Or with OAP (Open Agent Passport):

guardrails:
  enabled: true
  provider:
    use: aport.oap_provider:OAPProvider
    config:
      api_url: "https://api.aport.dev"
      require_passport: true

Before the fork, a tool call flowed like this:

Agent → Tool Registry → Tool Execution

After PR #1240:

Agent → Tool Registry → Guardrail Middleware → Authorization Check → Tool Execution

The key point: authorization happens before execution, not during or after. That is the pre-execution authorization pattern, and it is non-negotiable for production AI agents.

Why the authorization model matters

Pause for a second and think. When you deploy an AI agent that can send emails on your behalf, execute database queries, and deploy code to production, what is the authorization model?

Most frameworks today answer: "The prompt told it to."

That is not authorization. That is hope.

Authorization requires four things:

  1. Identity: who or what is acting? (the AI agent needs a passport)
  2. Policy: what are they allowed to do? (scoped permissions)
  3. Audit: what did they actually do? (signed receipts)
  4. Control: can we stop them if they misbehave? (kill switches)

DeerFlow has good infrastructure for identity and audit logging. It is missing policy and control.

Driver's license, not car engine

Let me borrow an analogy from physical world governance. When we think about AI agents, we focus on the engine: the model, the reasoning, the planning. That is important, and it is not what keeps roads safe.

What keeps roads safe is licensing drivers. We do not license engines. We license the entities that control those engines.

DeerFlow has a good engine. What it was missing is the driver's license check. My guardrail middleware is that check: before you can execute a tool, you show your passport, and we verify you are licensed for this specific tool.

The Open Agent Passport's before_tool_call hook is the standardized mechanism for that check. It is the traffic stop before the intersection, not the crash investigation afterward.

The web needed HTTPS and certificates before commerce was safe on it. Cloud needed IAM and RBAC before enterprises would run production on it. AI agents need passports and visas, and a border guard that checks whether the passport is valid, whether it allows entry to this country, whether there is room in the quota, and whether the entry gets stamped.

What this middleware is not

This is not a criticism of DeerFlow's engineering. The framework is excellent. This is a category-wide gap.

It is also not a prompt injection defense. That is a different layer. Prompt filtering tries to prevent malicious instructions from reaching the agent. Pre-execution authorization assumes the agent has already decided to do something and verifies it should be allowed to do it. Prompt filtering checks someone's intentions before they get in the car. Pre-execution authorization checks their license before they turn the key. We need both. Right now, most frameworks have neither.

It is not a content filter, which happens before tool selection. It is not a replacement for human oversight; it is what makes human oversight possible. And it is not a silver bullet. Authorization is one layer of a defense-in-depth strategy.

What it is: pre-action, so the check happens before the tool executes. Deterministic, so the same inputs give the same decision. External, so authorization lives outside the LLM's context window. Auditable, so every decision creates a signed receipt.

Seven frameworks, 48 hours, one built-in check

DeerFlow is not alone. In 48 hours I looked at seven major AI agent frameworks, including VoltAgent, Mastra, AgentScope Runtime, and Superpowers. Six of the seven have no pre-action authorization at all.

The pattern is consistent:

  1. Excellent tool execution pipelines
  2. Sophisticated planning and reasoning
  3. Memory and context management
  4. No authorization layer before tool execution

This is not an accident. It reflects where we are in the AI agent lifecycle. We are in the "make it work" phase, not yet in the "make it safe" phase. With agents moving into production, that phase needs to start.

My experience in digital identity and fintech has shown me a pattern: systems that handle value transfer (money, data, actions) need authorization at the point of transfer, not just at the point of entry. AI agents transfer agency from humans to algorithms. That transfer needs authorization.

The vendors are selling cameras, not locks

The frameworks are one half of the problem. The security vendors selling into them are the other half.

On March 20, 2026, Airia announced enterprise security capabilities for OpenClaw. The GlobeNewswire release lists centralized monitoring, compliance dashboards, alerting, and integration with existing SIEM and SOAR stacks. Every one of those capabilities is good. Every one of them reacts to something that already happened. Monitoring logs what happened. Dashboards show what happened. Alerting tells you something happened.

The 2026 CISO AI Risk Report from Saviynt puts a number on the cost of that ordering. The report surveyed 235 CISOs. 47% observed AI agents exhibiting unintended or unauthorized behavior. Only 5% felt confident they could contain a compromised agent. The breakdown:

  • 32%: agents accessing data they should not
  • 28%: agents performing actions outside their scope
  • 19%: agents making decisions without human oversight
  • 15%: agents bypassing existing security controls

Would monitoring have prevented any of those? No. It would have told you about them afterward. With an agent that can delete a customer database, the difference is between recovery mode and investigation mode:

Monitoring:    Agent → attempts deletion → action occurs → log → alert → you respond
Authorization: Agent → attempts deletion → check → "not authorized" → blocked → alert → you investigate

That is the difference between observability and control. Both are necessary. Only one of them keeps the database.

What happens next

PR #1240 is open. The maintainers will review it. They might merge it, they might suggest changes, or they might have their own implementation in progress. That is fine. The goal is not to get this exact code merged.

The goal is to start the conversation: every AI framework needs pre-execution authorization as a core primitive, not an optional add-on.

If you are building with DeerFlow or any AI agent framework today, ask yourself: what is the most dangerous unauthorized action your agent could take right now? Could it delete production databases? Could it send unauthorized emails? Could it modify critical files?

Now ask: what is stopping it?

For most frameworks today, the answer is "nothing but the agent's good judgment." As we have seen with every technology that gains agency, good judgment is not enough. We need deterministic guardrails.

Mine could delete production databases, send emails as me, and modify every file in my workspace. Before 3 AM on March 22, nothing was stopping it except its own reasoning. Now there is a guardrail, a checkpoint, and authorization before execution.

Follow the PR: DeerFlow PR #1240. Learn more about pre-execution authorization: APort Agent Guardrails.

What is the most audacious 3 AM coding session you have pulled? Mine was forking a framework this size to add security middleware. Are you running pre-action authorization in your agent stack? If not, what is stopping you?