Parallel Agents Break Authorization — And You Can't Revoke What They Already Know

The Experiments

I ran two experiments over the past two weeks to test how authorization behaves when AI agents run in parallel. These experiments were designed to test a simple assumption:

If you give AI agents scoped tasks, will their access stay scoped?

It didn't.

Experiment 1: Authority Replication

I assigned three AI agents to three different tasks:

• Agent A → research the auth module
• Agent B → analyze CRM data
• Agent C → build a slide outline

Each agent was supposed to access only files relevant to its task.

It didn't.

The auth researcher read the CRM data. The CRM analyst read the secrets file. Both lightweight agents could also read ~/.zshrc outside the workspace.

Task scope provided zero access control.

Every agent inherited the same authority.

Experiment 2: Revocation Propagation

Then I launched agents reading canary files in a loop and tried to revoke access mid-execution in four ways:

Method	What Happened
Content mutation	Agents saw new content on next read — zero caching
File deletion	Agents got "File not found" immediately
Permission change (chmod 000)	Agents got "Permission denied" immediately
Process termination	Nothing to terminate — no killable process existed

Every per-file revocation worked.

Nothing propagated.

To revoke access across agents, I had to repeat revocation manually — per file, per agent.

And when I tried to terminate a running sub-agent:

There was nothing to terminate.

Sub-agents don't exist as killable processes. They run server-side.

The parent has no off switch.

And one more thing:

You can revoke access to a file. You can't un-read it.

The Shift

Sequential systems are manageable:

step 1 → step 2 → step 3

Authority flows along time.

But parallel agents change the model.

Authorization stops being about time. It becomes about execution graphs.

Agent
<p>
 ├─ Branch A
 ├─ Branch B
 │    └─ Sub-agent
 └─ Branch C

Parallelism turns permission into inheritance.

These experiments exposed three core failure modes.

1. Authority Replication

Evidence: directly tested

When an agent fans out work across branches, authority gets copied.

Expected (intent-scoped):

Agent A → auth/**
<p>
Agent B → crm/**
Agent C → slides/**

Observed (runtime authority):

Agent A → ALL FILES
<p>
Agent B → ALL FILES
Agent C → ALL FILES

Even though each agent had a different purpose, every sub-agent inherited the same filesystem authority as the parent.

Authority wasn't scoped. It was replicated.

Key insight:

• Agent purpose ≠ access control
• Authority is inherited from the runtime, not derived from intent

2. Cross-Domain Access

Evidence: consequence of tested replication

This is a direct consequence of authority replication.

Because every branch starts with global permissions, each branch can access any domain:

• The slide generator can read CRM data
• The auth researcher can read secrets
• The CRM analyst can read the presentation

Even though their tasks don't require it.

This isn't really "leakage." It's exposure.

Authority was never isolated to begin with.

Parallel execution doesn't create exposure. It makes existing exposure visible — and multiplies its blast radius.

Key insight:

• Parallel execution multiplies the blast radius of global permissions

3. Revocation Doesn't Propagate

Evidence: directly tested across multiple methods

Per-file revocation works instantly:

Method	Latency	Destructive?	Reversible?
Content mutation	0 seconds	No	Yes
File deletion	0 seconds	Yes	No
chmod 000	0 seconds	No	Yes

Every agent saw errors on the next read.

But nothing propagated.

To revoke access from three agents reading two files each, I had to perform six manual revocations. There was no "revoke branch" command. No graph-level mechanism.

There is no:

• branch-level revocation
• execution-level control
• graph-wide propagation

The architecture makes it worse:

• Sub-agents cannot be terminated
• There is no revocation channel
• There is no parent-level control once execution starts

The most surprising finding

I tried to terminate a running sub-agent.

There was nothing to terminate.

No process. No cancel API. No control channel.

Once launched, a parallel agent runs to completion.

Sub-agents didn't exist as persistent local processes. They ran as server-side loops with ephemeral tool calls. The parent had no cancel button, no revocation channel, and no way to stop a child agent after launch.

And revocation had no persistence:

When I restored file permissions, agents silently resumed reading — no re-authorization required.

Key insight:

• Authority must not only be granted — it must be containable
• Current systems have no containment mechanism across the execution graph

The Irrevocable Memory Layer

This reinforces a deeper constraint — when files were mutated from v1 to v2, agents saw v2 on their next read — tool access reflected live filesystem state.

But the LLM's context still contained v1 from earlier reads.

You can delete a file. You can't un-read it.

This creates a split-brain:

Layer	After Revocation	Revocable?
Filesystem	Access denied / content changed	Yes
Tool reads	Return fresh state or errors	Yes
LLM context	Still has the earlier data	No

Content mutation can revoke future tool-mediated access. It cannot revoke data already consumed into the agent's reasoning context.

Why this matters now

If you're running agents in production, this means:

• You cannot rely on task scoping for isolation
• You cannot revoke access once execution fans out
• You cannot stop execution once sub-agents are launched

This is not a tooling gap. It is an architectural gap.

Revocation works at the system layer. It fails at the memory layer.

Additional Observations

The experiments surfaced secondary patterns:

• Agents accessed files outside intended workspace (~/.zshrc)
• Different models behaved differently in the same runtime
• Tool restrictions were mode-based, not capability-based

Which means:

If the runtime doesn't enforce boundaries, the model becomes the last line of defense.

And that's a fragile place for security.

The Deeper Architectural Problem

Most systems today attach authority to agent identity.

But agents don't behave like identities. They behave like execution graphs.

They:

• spawn sub-agents
• branch into parallel tasks
• merge results
• delegate dynamically

So the core question changes.

Old question: What can this agent access?

New question: What can this branch of execution access right now?

A Better Mental Model

Today — Identity-Scoped Authorization:

Agent identity
<p>
      ↓
Global permissions
      ↓
Inherited everywhere
      ↓
No revocation channel

Needed — Execution-Scoped Authorization:

Execution graph
<p>
      ↓
Branch-level permissions
      ↓
Authority shrinks per branch
      ↓
Revocation propagates

What the Experiments Proved

Claim	Evidence
Task scope provides no access control	3 agents, 3 tasks, identical access
Authority replicates across branches	All branches read all files
Per-file revocation works	Immediate, consistent across methods
No graph-level revocation exists	Manual per-resource revocation required
Sub-agents cannot be terminated	No killable process
Revocation has no persistence	Access resumes after restore
LLM memory is irrevocable	Previously read data persists

Closing

Parallel agents didn't introduce a new problem.

They exposed an old assumption:

That authority flows linearly.

It doesn't. It spreads across a graph.

Parallelism doesn't just improve performance. It changes the security model.

Final Thought

Authority doesn't just need to be granted. It needs to be scoped, propagated, and contained across every branch of the execution graph.

The systems we have today can grant authority.

They cannot contain it once it spreads.