AI agent swarms need identity controls beyond shared filesystems

At a glance

What this is: This is an analysis of why agent swarms keep converging on filesystems and why that model breaks down without explicit identity, scoped authority, and revocation.

Why it matters: It matters because IAM teams now have to govern agent identities, workload access, and human approval boundaries together, rather than treating swarms as just another automation layer.

👉 Read 1Password's analysis of agent swarms, filesystems, and identity controls

Context

Agent swarm security becomes an identity problem the moment shared files become the coordination fabric. The article argues that the core failure is not model quality or prompt design, but the assumption that a machine-level workspace can safely carry intent, authority, and accountability for production use.

For IAM, that shifts the discussion from compute isolation to access isolation. Filesystems can help agents share context, but they also create durable access paths that must be governed like any other non-human identity surface, especially when agents inherit credentials and machine permissions by default.

Key questions

Q: How should security teams govern AI agent swarms that share filesystems?

A: Security teams should govern swarm filesystems as shared workspaces with explicit identity, not as implicit trust zones. Every agent should have scoped read and write permissions, time-bound access, and revocation that works while the runtime is still active. That prevents the filesystem from becoming a hidden privilege amplifier.

Q: Why do shared filesystems create risk for agent swarms?

A: Shared filesystems create risk because they blend coordination, persistence, and access in the same layer. Agents can see more than intended, keep state longer than needed, and interfere with other agents if boundaries are unclear. The control failure is ambiguity about who can act on which paths.

Q: When should teams use just-in-time access for autonomous agents?

A: Teams should use just-in-time access whenever agent work is task-scoped, high-risk, or dependent on sensitive data and credentials. JIT is most useful when access should disappear as soon as the agent finishes, because standing privilege makes swarm activity harder to contain and harder to audit.

Q: What is the difference between a filesystem workspace and an identity control plane?

A: A filesystem workspace stores and shares artifacts, while an identity control plane decides who or what may access those artifacts and for how long. The workspace manages coordination. The identity layer manages authority, attribution, and revocation, which is what production swarms actually need.

Technical breakdown

Why filesystems became the default coordination layer for agent swarms

Filesystems work for agent swarms because they provide a shared namespace for plans, outputs, logs, and checkpoints without forcing every interaction through a context window. Agents can read, write, diff, and revisit artifacts in ways that map naturally to how modern models already interact with repositories and shell workflows. That makes the filesystem a practical memory and coordination layer, not just storage. The technical advantage is durability plus legibility: late-joining agents can inspect state, and every meaningful change can be traced. But that same abstraction only describes data movement, not authority. It answers what is present on disk, not who should be allowed to act on it.

Practical implication: Treat the filesystem as a coordination substrate, not an access-control boundary, and bind every meaningful file operation to identity and policy.

How shared filesystem access turns into authority leakage

When an agent gets host filesystem access, it often inherits more authority than intended because the operating system exposes broad read and write reach through that local context. In swarm environments, that means one agent can see files another should not, persist state longer than needed, or interfere with sibling agents in subtle ways. Networked file systems amplify the issue by extending that reach across multiple clients and runtime nodes. The problem is not the presence of files, but the fuzziness of the boundary around them. If the filesystem is both workspace and privilege surface, then every path becomes a potential control failure.

Practical implication: Separate writable swarm workspaces from sensitive host state and scope filesystem permissions to the minimum paths required for each agent role.

What production-ready swarms need from an identity layer

Production swarms need identity issued at agent creation, scoped authority that can be revoked in real time, and a runtime that can distinguish routine file operations from high-risk actions requiring approval. That is a different model from sandbox demos, where a human is nearby and access is often implicit. The article’s key point is that authority must exist at execution time, not just at storage time. In identity terms, the swarm needs leases, attribution, and continuous enforcement. The file system then becomes a capability surface backed by policy, not a free-for-all shared disk.

Practical implication: Design agent runtimes so every action is attributable, time-bounded, and revocable before the swarm can touch production infrastructure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent swarms expose a shared-state governance gap, not just an automation problem. The article shows that the hard part is not orchestration scale, but how authority is expressed when many agents coordinate through files. That makes the real control question one of identity, scope, and revocation across a shared workspace. Practitioners should treat swarm coordination as an access-governance problem, not a tooling feature.

Intent, authority, and accountability cannot be inferred from a filesystem alone: a shared directory is designed for persistence and collaboration, not for proving who may act, for how long, or under what approval boundary. That assumption fails when multiple agents use the same workspace because the filesystem does not encode decision rights. The implication is that production swarms need a separate identity control plane, not just better folder structure.

Agent workspace sprawl creates a new form of non-human identity blast radius. When agents inherit machine credentials and broad host access, the filesystem becomes the point where read scope, write scope, and persistence all expand together. This is the same governance pattern IAM teams already struggle with in service accounts, but swarms make it faster and harder to observe. Practitioners should model the workspace itself as an identity-bound asset with explicit limits.

Just-in-time access is more relevant to swarms than static permissions ever will be. The article’s argument for time-bound, revocable access reflects a broader shift in NHI governance: durable privilege is the wrong default for actors that appear, coordinate, and disappear dynamically. The issue is not whether an agent can use files, but whether it should retain access long enough to become ungovernable. Teams should assume agent access must expire by design.

Production swarms will force IAM and PAM to converge on runtime enforcement. The article describes a world where approval, attribution, and lease control have to happen while the agent is still active. That is a different operating model from post-hoc review, because the evidence and the risk exist at the same moment. Practitioners should expect agent identity governance to sit at the intersection of NHI, PAM, and workload runtime control.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
• The fragmentation problem is now showing up in agent stacks too, so readers should compare this post with Top 10 NHI Issues for the broader governance pattern.

What this signals

Agent workspace sprawl is becoming an NHI governance issue, not a developer convenience issue. As swarms move from demos to production, the unit of control becomes the identity-bound workspace, not the model prompt or the container boundary. Teams should expect access review, revocation, and audit requirements to move closer to runtime enforcement and farther from periodic recertification.

Shared-state coordination will keep pushing IAM and PAM into the same operating model. The article’s position is that filesystems are useful because they make agent behaviour legible, but only if access is separately governed. For practitioners, that means the next control conversation is less about where agents run and more about how their writable context is leased, observed, and revoked.

If your programme already struggles with credential sprawl, this topic is a preview of what happens when agents inherit the same problem at runtime. The control gap is not theoretical, and the governance model will need to account for machines that coordinate through shared artifacts while still requiring explicit identity and approval boundaries.

For practitioners

• Map every shared filesystem path to an explicit agent identity Inventory which swarm components can read, write, or persist to each workspace, then tie those permissions to the specific agent instance rather than the host or container alone. Require attribution for every meaningful file operation.
• Strip broad host-file access from production agents Keep agent workspaces separated from sensitive host state, and avoid granting implicit access to developer machines, credentials, or local secrets stores. If an agent does not need a path to complete its task, do not expose it.
• Issue time-bounded leases for swarm access Treat access as a revocable lease, not a standing entitlement, so agents lose the ability to continue operating once their approved task or context ends. Make revocation possible while the runtime is still active.
• Require approval gates for high-risk filesystem actions Define which file operations can proceed autonomously and which must pause for human approval, especially when the action can expose credentials, alter execution state, or widen access beyond the original task.
• Use shared artifacts as coordination, not authority Let agents exchange plans, logs, and outputs through files, but enforce policy at the identity layer so the workspace itself never becomes the mechanism that grants privilege.

Key takeaways

• Agent swarms fail in production when shared filesystems are treated as an authority layer instead of a coordination layer.
• The scale of the problem is governance, not just engineering, because swarms can inherit machine-level access and extend the blast radius of every workspace.
• Teams should move swarm access to identity-bound, time-limited leases with approval gates for high-risk actions.

Key terms

• Agent Swarm: A group of AI agents that coordinate work through shared context, artifacts, and state rather than a single linear prompt. In practice, the swarm becomes a distributed identity problem because each agent may need its own access scope, approval boundary, and audit trail.
• Filesystem As Coordination Layer: The use of files and directories as the shared workspace where agents store plans, logs, and intermediate outputs. It is effective for collaboration and persistence, but it does not inherently define authority, so identity controls must sit alongside it.
• Identity Control Plane: The layer that issues identity, scopes access, records attribution, and revokes permissions for an actor at runtime. For agent swarms, it separates what the workspace contains from who or what is allowed to use it.
• Time-Bounded Access Lease: A temporary permission model that expires after a task, session, or approval window ends. For non-human and agentic systems, leases help prevent standing privilege from outliving the work that justified it.

Deepen your knowledge

Agent swarm identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are working on production-ready swarms or shared workspace controls, it is a relevant place to start.

This post draws on content published by 1Password: agent swarms, filesystems, and the identity layer needed for production use. Read the original.