Read-Only Compute Isolation for LLM Agents

A human analyst logs into a database, runs a handful of queries, and logs off. An agent doesn't work that way, and that difference is the reason read-only compute isolation has become a foundational infrastructure requirement rather than a security nicety. This piece walks through why the old access controls don't fit agentic behavior, what isolation actually means as a technical pattern, and why the economics of object storage make the problem worse the more an agent is put to work.

Why agents are a different database user than humans

A human analyst who needs customer data runs a query, looks at the result, and moves on. The request is bounded because a person is asking it, and a person only has so many questions in them before lunch. Agents don't share that constraint. They probe relentlessly, often non-deterministically, and they do it by chaining tool calls together in ways that look harmless at each step and dangerous in combination.

The access-control systems built for human users were never designed to catch this. Network-level permissions work by checking whether an account is allowed to talk to a database at all, not by judging whether a specific query is reasonable. If an agent's service account has API access, the firewall waves through every query that account sends, legitimate or not. A reconciliation agent in a 2024 financial services case, manipulated through a support ticket, was coerced into exporting records matching a pattern the attacker had written as a regex broad enough to match the entire table. The agent walked away with 45,000 customer records, and from the firewall's point of view, nothing had gone wrong. The account had permission to query. It just had permission to query everything.

Research from TrajectoryDB notes that agent-driven token consumption on OpenRouter grew roughly 14 times between February and August 2026, and it reached close to five times the volume generated by human users on the same platform. Whatever risk a single probing agent represents, multiply it by a usage curve climbing that steeply, and the security model built for occasional human queries starts to look like it's defending against the wrong threat.

The danger in the gap between executive confidence and operational reality

The behavioral mismatch above would be manageable if the people running these systems knew about it and were building around it. The evidence from 2026 says otherwise.

That confidence gap matters because it determines what gets funded and what gets postponed. Organizations expanded agentic AI deployments sharply through 2025 and into early 2026, giving agents more autonomy as they went, while reliability, security, and trustworthiness remained open questions flagged as adoption barriers rather than solved problems. Scale came first. The architecture to secure that scale came second, if it came.

Governments noticed before most enterprises adjusted their own posture. The Five Eyes guidance document, "Careful Adoption of Agentic AI Services," published May 1, 2026, was the first intergovernmental statement to take on this architecture gap directly. A joint release from CISA, NSA, and four allied cybersecurity agencies doesn't happen because everything is fine. It happens because the practitioner consensus had already hardened enough, outside government, that an official response became necessary.

The root of the gap is structural. Agent access is governed by network-level permissions, and those permissions have no vocabulary for the business rule that actually matters: retrieving one customer's record is not the same as retrieving every record that happens to match a pattern. A firewall can say yes or no to a connection. It cannot say yes to "this specific record" and no to "all records like it," because that distinction lives at the level of the query, not the level of the account.

What read-only compute isolation means as an infrastructure primitive

Isolation, properly built, is a change to where compute physically runs and what that compute is capable of doing, independent of any policy layered on top. The pattern has three layers. The first is a set of isolated read-only replicas, separate compute that agents are routed to by default, sitting apart from the primary path that handles writes. The second is a centralized API gateway that enforces permissions, logs every access, and routes traffic exclusively to those isolated replicas, so it does real enforcement rather than acting as a single firewall rule that either lets traffic through or doesn't. The third is a semantic data model that gives agents business-friendly abstractions to query against instead of raw SQL access, which shrinks the space of what can even be asked in the first place.

This is exactly the configuration the May 2026 Five Eyes guidance converged on: direct database connections prohibited outright, every analytical query routed through a centralized gateway, and all traffic directed to isolated read-replicas rather than the primary store.

The Model Context Protocol, now the common integration layer between agents and their tools, builds a version of this distinction into its own architecture. MCP separates Resources, which are read-only data the model can pull in for context, from Tools, which are actions capable of side effects. A correctly deployed database sandbox under MCP permits only SELECT statements when the server declares its capability as information retrieval, and UPDATE and DELETE are disabled at the protocol level rather than merely discouraged by policy.

None of this works without compute and storage being separate to begin with. When object storage is kept apart from the engines that process it, compute can scale independently of storage, and that independence is what makes short-lived, agent-specific compute clusters practical. Agents frequently spin up temporary databases to get a task done, and ephemeral compute lets that happen without ever touching the primary store. Columnar storage adds a further benefit here: a query that only reads the columns it needs produces an I/O profile that's predictable and bounded. Agent query behavior can actually be audited and planned for, something far harder to pull off on row-oriented storage where every query potentially touches everything.

MCP's structural security deficit makes isolation mandatory

MCP spread fast. It became the default way agents connect to tools and data well before its security architecture had caught up to the job of guarding production databases, and that timing gap is the practical reason isolation can't be left to policy alone.

The NSA's own assessment of the protocol spells out how wide the gap is. Its Cybersecurity Information Sheet, CSI_MCP_SECURITY, states that MCP components can be set up to access or process data without any required access control measures at all. Plenty of real implementations skip authentication entirely, and the ones that do include it often leave out role-based enforcement, which leaves data access both ambiguous and impossible to trace back to a source. Layered on top of that is dynamic tool invocation: agents can call new tools at runtime that weren't part of the original session, so an agent's actual permission scope at any given moment isn't fixed when the session starts. It can expand while the session is already running.

A Cursor AI agent with Supabase service-role access was shown, in a demonstrated proof-of-concept documented across incidents, to exfiltrate integration tokens, though no confirmed production incident resulted from it. Asana's MCP implementation allowed data exposure across different customer instances. Microsoft 365 Copilot, tracked as CVE-2025-32711, was exploited through indirect prompt injection delivered via crafted emails, which caused it to exfiltrate sensitive data.

A correctly configured database sandbox under MCP closes most of this off at the protocol layer rather than relying on an administrator to get every setting right. Only SELECT is permitted when the server's declared capability is information retrieval. The sandbox intercepts every query input, applies escaping rules to it, and rejects any statement containing a keyword that hasn't been explicitly approved. That's the shape isolation needs to take given what MCP actually permits by default: not a recommendation layered on top of the protocol, but a constraint built into how the protocol is deployed.

The five security principles that read-only isolation directly implements

Isolation isn't one control doing one job. It satisfies several of the foundational principles the 2026 International Scientific Exchange on AI Safety laid out for managing agentic risk, which named ten in total: least privilege, traceable identity, auditability, validated deployment, adversarial resilience, multi-agent stability, runtime assurance, interruptibility, legibility, and human oversight.

Isolation maps directly onto at least five of those. Least privilege is satisfied because the agent compute layer has no write capability at all, so whatever goes wrong, whether through failure or injection, is bounded to what can be read rather than what can be changed. Traceable identity follows from giving each agent or session its own isolated compute, so every query traces back to a specific identity instead of disappearing into a shared service account. Auditability comes from routing every query through a gateway that logs it in full, producing a record that's complete and hard to tamper with, something shared write-capable compute simply can't promise in the same way. Adversarial resilience holds because prompt injection can't produce a write when the write path doesn't exist on that compute. Interruptibility comes from the fact that ephemeral isolated compute can be shut down or suspended without touching the primary data store or any other agent's session.

That last point connects to a lesson familiar from decades of security engineering outside of AI entirely. Hardening a single component, whether that's model alignment or careful prompt engineering, is worth doing but rarely enough on its own. What works is placing deterministic enforcement points at multiple layers of the stack, which raises the cost of a successful attack without dragging down performance. Isolation is one of those enforcement points, not a replacement for the others.

What full query logging requires from the underlying data store

Autonomous doesn't mean unaccountable, and making that true requires more than turning on a logging flag. It requires the data store underneath to treat the agent's own trajectory as a first-class kind of data, because what an agent trajectory actually is looks nothing like a standard application log.

A trajectory records the messages sent to the LLM, the model's responses, every tool call, every tool result, and the runtime state tied to all of it. That's nested and ordered rather than flat, and it's highly redundant, because each new model invocation tends to repeat a large share of the context from the one before. TrajectoryDB, out of Harvard and published at PVLDB 2027, argues this makes trajectories a distinct data-management workload in their own right. Ingesting them means reconstructing execution structure and lineage. If you store them, you organize contexts that are large and heavily repetitive without losing the relationships between records. Querying them means reasoning jointly over structure, time order, meaning, and lineage all at once, a combination existing log stores were never built to handle.

The standard transport for this kind of observability in 2026 is OpenTelemetry using gen_ai.* semantic conventions. A non-trivial agentic product that year typically mounts somewhere between 5 and 10 MCP servers, and every tools/call, resources/read, and prompts/get generates its own span tagged with a tool name. That volume of structured telemetry is what standard application performance monitoring wasn't built to absorb. Traditional APM assumes failures announce themselves as crashes or stack traces. LLMs fail silently instead, producing semantic errors: a hallucinated answer still returns a 200 OK with ordinary latency, so the observability store has to be queried analytically to catch a problem like that, not just scanned for error codes that will never appear.

Reliability data adds another requirement on top. Major LLM APIs each experience outages roughly every few days, with a median recovery time around an hour. Agent database sessions have to survive provider failures without any mutation to the underlying data, a guarantee read-only replicas can make reliably and shared write-capable compute cannot. There's also a subtler failure mode specific to multiple agents sharing a write-capable store without global state visibility: formal work on Agentic Redux shows that two agents can independently commit actions that together violate a system invariant, a pattern known as write skew, which read-only isolation rules out by construction, since there's no shared write path for two agents to collide on in the first place.

The object-storage cost trap compounding for agentic workloads

Object storage pricing was built around how humans query data, and agents query data in close to the opposite pattern. Every existing cost inefficiency in an S3-routed architecture gets worse once an agent is the one doing the asking.

The economics of object storage are straightforward on paper: storage per gigabyte is cheap, and the real cost is in data transfer and request count. Humans tend to run occasional large batch reads, which keeps request counts low even when the data volume is high. Agents do the opposite, firing off large numbers of small, frequent requests rather than big infrequent ones, landing on data transfer and request count, the cost dimensions object storage handles worst.

Billing granularity makes the gap worse than it first appears. MotherDuck's guide on the subject points out that an agent firing many short queries across a day can run into a 60-second billing minimum on each one, and that minimum can work out to a 30 times cost multiplier compared to systems that bill per second, a structural penalty that some services are explicitly designed to avoid. If an agent asks a genuinely useful one-second question, it still gets charged for sixty.

Isolated, read-only compute sitting over a cache layer sidesteps a large share of this. Hot data stays resident in memory, so queries resolve against the cache instead of reaching out to S3, and the cost profile stays flat even as the volume of queries climbs, An architecture that keeps hot data in a distributed cache mesh purpose-built for agentic workloads is one example of a design built around exactly that premise, ObsessionDB, a managed database service whose cache-mesh architecture routes no query through S3, giving each agent session isolated read-only compute with full query logging, is one such system. Compute-storage separation supports the same goal from another angle: isolated read-only compute can be spun up for a single agent session and torn down once the session ends, which keeps the cost of that session bounded and predictable rather than letting it accumulate across shared infrastructure the way a long-lived connection would. Per-query pricing charges for what agents do most: they ask many small questions out of something close to curiosity rather than running one deliberate batch job. Compute-hour pricing ties cost to the capacity actually provisioned instead of the number of questions asked, which lines up with what an agentic workload actually looks like far better than a model built around infrequent human queries ever could.