Patterns/Agent Patterns

Shared Mutable State Is an Injection Free-for-All

Why shared workspaces that multiple agents read and write are security nightmares

The Conventional Framing

Blackboard architectures use a shared workspace that multiple agents read from and write to. Agents contribute partial solutions, build on each other's work, and collaboratively solve problems. The blackboard enables loose coupling and emergent problem-solving.

The pattern is valued for flexibility—agents don't need to know about each other, just the shared workspace.

Why This Is Dangerous

The blackboard is shared mutable state that any agent can write to. There's no inherent access control, no provenance tracking, no validation. If one agent is compromised—or processes compromised input—it can poison the blackboard for all other agents.

This is injection with persistence and broadcast. One successful injection affects every agent that reads from the blackboard afterward.

Why this pattern compounds risk:

  • No write isolation. Any agent can modify any part of the blackboard. Compromised Agent A writes poison that Agent B trusts.
  • No read validation. Agents assume blackboard content is trustworthy because "another agent wrote it."
  • Persistence. Poison persists on the blackboard, affecting all future reads until explicitly removed.
  • Attribution loss. It's often unclear which agent wrote what, making forensics difficult.

Architecture

Components:

  • Blackboard— shared mutable workspace
  • Agents— independent processors that read/write
  • Controller— optional coordinator selecting which agent runs
  • Knowledge sources— agent contributions to the blackboard

Trust Boundaries

┌─────────────────────────────────────────────────────────┐ │ BLACKBOARD (Shared State) │ │ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ [Agent 1 output - may be poisoned] │ │ │ │ [Agent 2 output - may be poisoned] │ │ │ │ [Agent 3 output - may be poisoned] │ │ │ │ ... │ │ │ │ [Injection from ANY agent persists here] │ │ │ └─────────────────────────────────────────────────┘ │ │ │ │ Every agent reads this as if it were trusted │ │ Every agent can write to it │ │ One poisoned write affects all future reads │ └─────────────────────────────────────────────────────────┘
  1. External input → Agent — injection enters via any agent
  2. Agent → Blackboard — poison written to shared state
  3. Blackboard → Agent — poison read by other agents

Threat Surface

ThreatVectorImpact
Cross-agent poisoningCompromised agent writes malicious contentAll other agents affected by poison
Persistent injectionInjection written to blackboard persistsLong-term compromise of system state
Attribution lossCan't determine which agent wrote whatForensics and remediation difficult
Race condition exploitationTiming attacks on read/write sequencesInconsistent or manipulated state
State overflowFill blackboard with malicious contentDenial of service or attention hijacking

The ZIVIS Position

  • •
    Don't use blackboard for multi-agent systems.Seriously. Shared mutable state with no access control is the worst pattern for security. Use explicit message passing with validation instead.
  • •
    If you must, add provenance.Every write tagged with agent identity and timestamp. Readers can filter by source trustworthiness.
  • •
    Segment the blackboard.Different regions with different access controls. Agent A can only write to region A, can only read from regions A and B.
  • •
    Validate on read, not just write.Agents should treat blackboard content as untrusted input, even though 'an agent wrote it.'

What We Tell Clients

Blackboard architecture is elegant for collaborative problem-solving and terrible for security. Every agent can poison the shared state, and every agent trusts that state implicitly.

If you're building multi-agent systems, use explicit message passing with validation at each boundary. If you must use shared state, treat it like a shared database: access controls, provenance, and validation on every read.

Related Patterns