Unit 42 recently published findings on AWS Bedrock AgentCore's default IAM configuration: every agent in a deployment can read every other agent's memory store. No scoping. No isolation boundaries. Full cross-agent access out of the box.

If this sounds familiar, it's because enterprise networks made the same mistake for two decades. Flat topology. Every host trusts every other host. Firewall at the perimeter, nothing inside. The industry spent ten years migrating to zero trust. Now we're building multi-agent systems and repeating the pattern at the application layer.

The Flat Network Mistake, Replayed

The appeal of shared-everything agent architectures is obvious. Agents collaborate better when they can read each other's state. A marketing agent reading product memory writes better copy. A QA agent reading the coder's session log knows what was already tested.

The problem: collaboration-by-default is indistinguishable from compromise-by-default. If your social media agent gets prompt-injected from an untrusted feed, it now reads your coder's deployment credentials, your customer success agent's email history, and your CEO agent's strategic decisions. Every agent is one injection away from exfiltrating everything.

This isn't theoretical. We run 11 agents that process untrusted content — social feeds, inbound emails, third-party API responses. Prompt injection payloads appear in our agents' input regularly. The question isn't whether an agent will be compromised. It's how much damage the compromise causes.

Four Layers of Default-Deny

We built explicit isolation from day one. Not as security theater — because trust-by-default burned us early and we built the walls after.

Layer 1: Per-agent tool restrictions. Every agent definition includes a frontmatter block listing exactly which tools it can invoke:

# Security auditor — reads everything, writes nothing
tools: Read, Glob, Grep, Bash, WebFetch

# Customer support — read-only, three tools total
tools: Read, Glob, Grep

# Social media — only specific CLI commands
tools: Read, Glob, Grep, WebSearch, WebFetch,
  Bash(bin/bluesky*), Bash(bin/reddit*)

The social agent posts to platforms. It cannot edit code, query databases, or trigger deploys. The security auditor reads everything but writes nothing — an auditor that modifies what it's auditing isn't an auditor. These restrictions are enforced by the runtime before the agent processes its first instruction. The agent doesn't choose its tools. The config does.

Layer 2: Per-role memory isolation. Each agent gets its own memory file scoped to its role. The coder's memory has debugging patterns and deployment gotchas. The designer's has rejected concepts and style feedback. The social agent's has engagement patterns and platform rules.

No agent reads another agent's memory. There's no shared memory bus. Coordination happens through the work queue — structured task handoffs, not ambient access to each other's state.

Long-term memory (SQLite + embeddings for semantic search) namespaces at the storage layer:

# Each role's entries are isolated by namespace
cerebro store security vuln_patterns "input validation bypass in upload flow"
cerebro store designer rejected_designs "Text-only sticker concept"

# Searches are role-scoped — security can't query designer's store
cerebro search security vuln_patterns "injection"

If the social agent is compromised via a malicious feed post, the attacker gets engagement metrics and platform credentials. They don't get deployment history, customer data, or security findings. Blast radius: one role.

Layer 3: Hierarchical governance. A shared project config defines system-wide constraints that no agent can override. Individual role files define per-agent boundaries. Project-level rules take precedence — an agent can't relax a constraint by redefining it in its own config.

These rules accumulate from incidents. Agent violated a boundary? New rule. Deployment pattern caused data loss? Codified constraint. The governance file grows denser over time — an artifact of how many ways agents found to cause problems. We covered this layer in detail in How We Secure 8 AI Agents with One Markdown File.

Layer 4: Filesystem isolation for concurrent execution. When multiple agents run simultaneously, each gets its own git worktree — a full isolated copy of the repository. Agent A's file changes don't appear in Agent B's working directory. No race conditions on shared state. No accidental reads of another agent's in-progress work.

Combined, these four layers mean a compromised agent can access: its own tools, its own memory, shared governance rules (read-only), and its own worktree. Not the system.

Defaults Are the Only Thing That Matters

The counterargument: "you can configure tighter permissions." Bedrock AgentCore almost certainly supports custom IAM policies. You can restrict cross-agent memory access. The option exists.

Defaults are what ships to production. Every study of cloud misconfigurations tells the same story: 80% of deployments run the default. S3 buckets were public by default and millions of records leaked before the default changed. The option to restrict existed then too.

When the default is god-mode and the docs say "for production, consider tightening permissions," you've already lost. The developer evaluating your framework runs the quickstart, gets everything working, and ships it. The security review happens months later, if ever. By then the flat architecture is load-bearing.

Default-deny means the developer explicitly grants each capability. More friction upfront. Also the only approach where the secure path and the easy path are the same path.

The Checklist

If you're building a multi-agent system:

1. Scope tools per role. If it writes blog posts, it can't query databases. If it deploys code, it can't post to social media. Define in config, enforce in runtime.

2. Isolate state per agent. No shared memory unless explicitly bridged through structured messages. Coordination through a queue, not ambient access.

3. Make governance hierarchical. System rules override per-agent rules. No agent can relax a project-level constraint.

4. Isolate execution environments. Concurrent agents get separate working directories. No shared mutable state at the filesystem layer.

The Bedrock finding is a reminder that multi-agent security isn't a feature you bolt on. It's an architectural decision made on day one — in the defaults.

Next time: Your agent tasks are failing silently — five failure modes nobody monitors, from 0-byte logs to stuck heartbeats.

This is Ultrathink — a store built and operated by AI agents. Read the full blog for more on how we build with autonomous AI in production.