Your Agents Need Boundaries. Please Keep Them in a Data Sandbox.

Every time I log into an agent platform, I see more connectors and plugins.

Connect your Slack. Connect Salesforce. Connect Jira, Notion, GitHub, Snowflake, Google Drive, your databases, your internal APIs, and everything else that might contain useful information. Give the agent tools for all of them and let it decide which source to query, when to query it, and how to combine what comes back.

I understand the appeal. More connectors mean more things the agent can know and do. But I think we are heading toward architectures where the agent has far too much responsibility for how data gets into its own context.

Every source has its own semantics, freshness characteristics, schema, failure modes, and security assumptions. The agent ends up responsible for both solving the task and navigating the data infrastructure required to solve it.

I think we should move in the opposite direction. Bring the data to the agent, not the other way around. Put the data through a controlled ingestion process, and let the agent operate inside a trusted data environment.

Agents Should Consume Data, Not Own the Data Pipeline

An agent already has a difficult job. It has to understand the objective, determine what information matters, reason over it, use tools, produce artifacts, and decide when the task is complete. When we also make it responsible for discovering and reconciling data across dozens of systems, we quietly give it another job: data engineering.

For example, customer information might be spread across Salesforce, billing, support, product analytics, and the warehouse. Those systems may use different identifiers, update at different times, represent the same fields differently, and disagree about which source is authoritative.

A data team would normally resolve those issues before exposing the result to downstream consumers. We create mappings, canonical entities, transformations, tests, lineage, and freshness guarantees. With direct tool access, we often push those decisions into the agent loop and ask the model to reconcile the mess while solving the user’s problem.

Centralize the Path Into Context

One of the most important questions in an agent system is simple: how does information become context?

If the agent can call whatever tool it wants, every tool becomes part of your context pipeline. Governance, observability, validation, provenance, and access control become distributed across dozens of integrations.

A centralized ingestion layer gives you a stronger boundary. External systems can remain the systems of record, while information passes through a deliberate pipeline before becoming available to agents.

Inside that controlled environment, you can resolve identities, deduplicate records, enforce schemas, attach provenance, strip restricted fields, classify sensitive information, precompute joins, and expose stable semantic objects rather than forcing the model to understand every upstream API.

ETL Becomes Part of the Security Boundary

We usually think about ETL as infrastructure for analytics. In agent systems, it can also become part of the security model because the data entering the model may directly influence its behavior.

Documents can contain hostile instructions. Web pages can contain prompt injection. A compromised upstream system can introduce manipulated information, while stale or malformed data can produce bad decisions without any malicious actor involved.

Direct access makes these risks harder to contain because the agent retrieves information at the same moment it is reasoning over it. A controlled ingestion layer creates a place to inspect, classify, sanitize, quarantine, and annotate data before it enters the agent environment.

You can record provenance, distinguish trusted internal records from untrusted external text, restrict which fields are exposed, and preserve raw source data for auditing. It gives you a defined control point before data becomes model context.

Provenance Gets Much Easier

After an agent makes a bad decision, one of the hardest questions can be: what exactly did it know?

With direct tool access, the agent may have queried several APIs whose responses have since changed. It may also take different retrieval paths on different runs, which makes reproducing the original context difficult.

A controlled data plane lets you version the data environment itself. Instead of saying the agent queried several systems at 2:13 PM, you can say it operated against customer snapshot 8421, generated from Salesforce, billing, support, and product events using pipeline version 17.

You can inspect that snapshot, rerun the task against the same inputs, and determine whether a failure came from the model, the transformation pipeline, or the upstream data.

Tools Still Have a Place

Agents still need tools to send messages, create tickets, modify records, trigger jobs, run code, and interact with systems that cannot reasonably be replicated into a central data layer.

There will also be read cases where direct access makes sense because the data is too dynamic, specialized, or expensive to ingest continuously. The important architectural decision is where the default sits.

I would make arbitrary direct reads the exception and the controlled data layer the normal route by which information reaches the model. That keeps the agent environment understandable while preserving escape hatches where they are genuinely useful.

The Data Sandbox

I like thinking about this as a data sandbox because the analogy is useful. We already sandbox agent code because we do not want generated programs freely roaming across our infrastructure, so we constrain the filesystem, network, credentials, libraries, runtime, and resources they can access.

Data access deserves a similar boundary. An agent can have access to enormous amounts of information while still operating inside a controlled environment containing structured records, documents, events, cached API responses, embeddings, historical artifacts, and materialized views.

What matters is that information crosses the boundary through a known path. You know where it came from, when it arrived, how it was transformed, what policies apply to it, and which version the agent used.

Make the Outside World Come Through the Front Door

As agents become more capable, there will be pressure to give them access to more information. I want agents to have access to enormous amounts of data, but I also want to know how that data reached them, where it came from, when it was captured, and whether I can reproduce the context behind a decision.

That makes the data pipeline a first-class part of agent architecture. Build the connectors, ingestion pipelines, canonical entities, semantic representations, validation rules, and provenance layer that bring the outside world into a controlled environment.

Then keep your agents inside the data sandbox.