Per-Agent Filesystem Isolation and Credential Segregation

An agent reads a repository comment planted by an attacker, or pulls a tool description from a compromised MCP server, and treats it as an instruction. The model has no reliable way to tell that input apart from a legitimate request, because its entire job is to execute actions with whatever permissions the user or tenant has granted it. Once that instruction is accepted, the agent inherits those permissions wholesale, and the question that decides what happens next is not whether the agent was fooled but what it was physically able to touch once it was. That question is the subject of this piece: per-agent filesystem isolation and credential segregation are two walls of the same enclosure, and a deployment that builds only one of them leaves a gap shaped exactly like the wall it skipped.

Filesystem isolation without credential segregation lets a compromised agent read any secret sitting in its environment and send it out over the network, because the wall that would have kept the secret out of reach was never built. Credential segregation without filesystem isolation lets that same compromised agent write a persistent payload, something as plain as a reverse shell dropped into.bashrc, and wait for the next session to trigger it, because the wall that would have kept the filesystem clean was never built either. A systematization of 39 execution-security papers published between 2023 and 2026 treats isolation architecture and access control as one unified problem rather than two separate research literatures: adopting one hardening measure while deferring the other leaves the exact gap described above, since the research record treats them as a single problem rather than two independently schedulable fixes.

Filesystem isolation's boundary

Filesystem isolation, done properly, does not work by forbidding an agent from opening certain paths. It works by removing those paths from the agent's view of the filesystem, so they cannot be addressed. The distinction carries real weight: a forbidden path can still be the target of a time-of-check-to-time-of-use race or a policy bypass, because the path exists and some enforcement layer has to catch the attempt every single time. A path that was never mounted cannot be raced, bypassed, or talked around, because there is nothing there to reach.

On Linux, this is the function bubblewrap (bwrap) performs. Bubblewrap requires no root privileges and is already used by Flatpak and comparable projects to build a narrowed filesystem namespace for a running process. Inside that namespace, directories like ~/.ssh and ~/.aws don't exist from the agent's point of view because they were never mounted into the view the agent operates in. That same principle extends to a broader set of paths that an agent should never see regardless of which specific tool enforces the boundary: /etc, /var, /home, SSH keys, host environment variables, global configuration files, and anything outside the working directory the agent was assigned. Write access needs to stay scoped to that working directory and nothing below it; read access can be wider within that scope, but sensitive paths stay structurally excluded rather than merely flagged as off-limits.

The cost of getting this wrong is not abstract. The execution-security systematization confirms four disclosed, patched CVEs directly affecting production agent harnesses, among them a data-exfiltration flaw in a coding agent's project-load flow that let a malicious repository leak API keys before a user ever confirmed they trusted the project. Proper filesystem scoping at load time, keeping those credentials out of the agent's view until trust is established, would have closed that failure at the source. But filesystem isolation only answers half the question. An agent that can reach the network can still ship out anything it can read, and if the credentials sitting on disk were never scoped down in the first place, a narrowed filesystem view does nothing to stop them from leaving.

Credential segregation versus access control

Credential segregation is the practice of keeping credentials the agent doesn't need for its current task out of the agent's runtime environment altogether, provisioning what it does need at the moment the task starts and revoking it the moment the task ends. If an unsandboxed agent inherits the full host credential environment, it can reach every API key, every cloud role, and every database connection string the host process running it has, so the blast radius of a single compromise is the entire credential set of the deployment.

The fix is to inject secrets per task rather than let the agent inherit the host's full environment wholesale. Credentials get provisioned at runtime for the specific job at hand, scoped to the minimum the job requires, and revoked once the job finishes. This is least-privilege thinking applied specifically to agentic workloads, a runtime provisioning discipline tied to what the agent is actively doing rather than a general access-control posture layered on top of a static credential store. The 2026 Singapore Consensus on Global AI Safety Research Priorities, in the companion report on agentic risk management, names Least Privilege as Principle 1, so credential scoping sits at the base of what a safe agent deployment looks like, not as an optional hardening step.

But credential segregation fails quietly if the filesystem underneath it is left open. If the agent's filesystem view still includes paths where credentials get cached, a ~/.aws/credentials file, a ~/.config directory, token files a previous session happened to write, then a narrow runtime credential grant is undermined by whatever ambient secrets are already sitting on disk waiting to be read. And credential segregation on its own cannot stop a compromised agent from writing a persistent payload to an accessible path and triggering it later, because restricting what the agent holds right now says nothing about what it can leave behind for next time.

How the two controls reinforce each other

Putting the two walls up together closes the specific route each one leaves open for the other. A filesystem-only deployment lets a compromised agent read ambient credentials and exfiltrate them over the network. A credential-only deployment lets a compromised agent write a persistent payload to some accessible path and trigger it in a future session. Both of those routes depend on the missing wall being there to exploit, and when both walls are in place, neither route exists to begin with.

Together, the two controls enforce something closer to a session-bounded execution model. The agent sees only the files its current task actually needs, holds only the credentials provisioned for that task, and has nowhere to write a persistent artifact outside its working directory. A compromise, when it happens, stays bounded to the scope of the current task rather than spreading to the next session or the next tenant. This matters because the same execution-security systematization finds that policy-enforcement approaches built on denylists fail at high rates under adversarial conditions. A denylist has to catch every attempt; structural elimination, a mount that was never created, a credential that was already revoked, doesn't depend on catching anything, because there's nothing left for the agent to talk its way past.

The two-wall model has a boundary condition: multi-agent orchestration frameworks sometimes offer shared memory mechanisms of their own, optional global stores or crew-level memory shared across agents, and these sit above the infrastructure layer. Building both walls at the infrastructure level is necessary, but it is not sufficient if the orchestration layer reintroduces shared state through its own APIs, routing around the enclosure rather than through it; a later section returns to this caveat, which doesn't diminish the argument that the infrastructure walls have to be built first.

Compute isolation as the foundation for both controls

Filesystem isolation and credential segregation are only as strong as whatever isolation primitive actually enforces them underneath. A process-level boundary that shares the host kernel with every other guest on the machine is a weaker enforcement surface than a hardware virtualization boundary that hands each agent its own kernel, and that difference sets the ceiling on everything built above it.

Container-level isolation is built from Linux namespaces and process separation, so it keeps agents in distinct process trees, but every guest still shares a single host kernel. A kernel exploit found in one agent's environment can cross that shared kernel and reach the host, or reach a neighboring agent's environment, regardless of how carefully the filesystem and credentials inside that container were scoped. This isn't a hypothetical risk. Container escape CVEs recur on a regular basis; runc alone has produced CVE-2019-5736 and CVE-2024-21626, both rated high severity, and each disclosure opens a window during which a tenant-boundary crossing is possible that no filesystem policy or credential rule can close from inside the container, because the container boundary was never the thing holding the line.

MicroVM isolation, the model Firecracker implements on top of KVM, gives each agent its own dedicated guest kernel enforced by hardware virtualization rather than by the host operating system's process model. A kernel exploit inside one microVM cannot reach the host or a neighboring microVM, because the boundary sits below the kernel rather than above it. Firecracker boots in roughly 125 milliseconds and adds under 5MB of memory overhead per VM, numbers that remove the old argument that running one VM per agent is too slow or too expensive to operate at scale. gVisor offers a useful middle position for workloads where even that overhead is a constraint: it interposes a userspace kernel between the workload and the host OS, giving a smaller kernel attack surface than a plain container without taking on the full cost of a VM.

None of this amounts to an absolute boundary, and it shouldn't be described as one. The honest claim for microVM isolation is layered risk reduction: a compromise that wants to reach the host from inside a Firecracker guest has to defeat both the workload sandbox and the hypervisor beneath it, where a container escape only has to defeat the container boundary wrapped around a kernel every other guest is already sharing. For multi-tenant deployments, where strangers' agents run on the same shared hardware, both the execution-security systematization and separate analysis of multi-tenant isolation treat shared-kernel designs as structurally insufficient once the workload is arbitrary, AI-generated code rather than code the operator wrote and reviewed in advance.

Per-agent isolation and the per-user agent model at scale

Traditional multi-tenant SaaS keeps tenants apart at the application layer, through separate database rows, separate API keys, and role-based access controls, and that approach works because the vendor controls what code actually runs. Agent workloads invert that assumption entirely, because the agent generates and executes code at runtime from whatever the tenant's prompt asked for. The vendor no longer controls the code; the vendor controls, at best, the environment the code runs in.

That inversion makes per-agent isolation a fleet-level requirement. When agents execute arbitrary, AI-generated code inside a shared execution environment, resource exhaustion, kernel exploits, and data-leakage flaws stop being contained incidents and start being cross-tenant events. Workloads co-located on shared infrastructure already lose 5 to 50 percent of performance to interference alone, and a single filesystem or memory access flaw is enough for one tenant to read another tenant's data. In the per-agent isolation model, each agent runs in its own VM with its own filesystem view and its own task-scoped credentials, so any one failure stays bounded to a single tenant's current task rather than spreading across the fleet.

This is not a theoretical design pattern. AWS Bedrock AgentCore runs each user session in a dedicated microVM with isolated CPU, memory, and filesystem, which stands as a production deployment validating the per-agent-VM model at real operating scale. The 2026 Singapore Consensus names Traceable Identity as Principle 2 right alongside Least Privilege as Principle 1, and at fleet scale those two principles collapse into the same requirement looked at from two angles: per-agent identity is what makes per-agent credential scoping auditable, and per-agent credential scoping is what makes per-agent identity enforceable. The security model and the product model turn out to be the same model, which is the reason per-agent isolation belongs in the architecture from the start rather than bolted on once a deployment has already scaled past the point where it's easy to add.

A complete implementation at the infrastructure level

A complete implementation rests on four pieces working together: a per-agent VM boundary, a filesystem mount scoped to the working directory, credential injection scoped to the task, and network egress controls enforced at the boundary rather than inside the agent process. Each agent runs in its own microVM with its own dedicated kernel, so there is no shared kernel attack surface exposed to neighboring agents. The agent's filesystem view gets built at mount time to include only the working directory and whatever tool paths the task specifically needs, so sensitive system paths, SSH keys, and credential caches are structurally absent from that view rather than present and merely policy-denied. Credentials are injected per task at runtime, scoped to the minimum the task requires, and revoked the moment the task completes, so the agent never holds the host's full credential environment even briefly. Network egress is filtered against an allowlist at the infrastructure boundary, not inside the agent's own process, so unknown destinations are blocked outright rather than flagged for a model to reconsider. Anything that needs to persist across sessions, whether that's files, credentials, or session identity, gets explicitly provisioned and explicitly scoped rather than inherited from whatever ambient environment happened to be lying around.

Even built this way, the enclosure has known edges. Framework-level shared memory, the optional global stores or crew-level memory some orchestration frameworks offer across agents, reintroduces shared state above the VM boundary; the infrastructure enclosure is necessary, but an orchestration layer that bypasses it through its own APIs can still undo the isolation underneath. MCP tool scoping has to be handled per session rather than per server: if a single MCP server hands the same tool list to every tenant regardless of who's asking, the capability layer above the infrastructure undermines whatever isolation was built below it. Policy-authoring error sits outside what any of these controls can catch, since every enforcement mechanism in the execution-security research record assumes the person writing the policy got it right. The same systematization finds that benign, out-of-scope agent actions occur at a rate of 17.1% under realistic prompting conditions, a failure mode that neither filesystem isolation nor credential segregation was ever designed to constrain. Runtime behavioral monitoring belongs alongside these controls as a complement rather than a substitute.

A sound enclosure is one where both walls are actually built, where the gaps that remain are named and understood rather than discovered after the fact, and where a failure in any single control stays a failure in that control rather than becoming a failure of the whole system.