Data access, what agents can and cannot reach

The first question a security owner asks about letting agents into a workspace is the direct one: what can an agent actually reach in our data, and what can it never reach? This page answers both halves in plain language. The short version is that an agent works with the specific piece of work it was handed, through tools that check permission, and it reaches your real data through those tools rather than through your databases. Your standing secret values, another customer's data, and another run's data are all outside its reach by the way the system is built, not by a setting someone has to remember to turn on.

This is the CISO view that pulls the rest of the section together. The mechanisms behind it live on sandboxed execution isolation, credentials and the secret policy, and approved actions and least privilege; here we map them onto the question your data team actually asks.

What an agent works with

An agent does not roam your data. It works with a bounded set of things tied to the job in front of it.

• The work it was given. When an agent reads a plan, a bug, or an initiative, it reads it through a permission-checked tool that is scoped to your workspace and the work the run is about. There is no general "query the database" tool; an agent fetches the specific records related to its task, and every fetch is scoped to your tenant.
• A checkout of the code it was pointed at. When the work involves a repository, the agent gets a clone of that repository inside its own sandbox, not a window into your whole source estate. The code lives in the container for the life of the run and goes with it.
• The documents attached to the work. Files a person attached to a plan or a bug live in a separate document store, and an agent reaches only the ones attached to the work it is doing, by following the attachment, not by browsing the library.
• The tools you connected. An agent reaches an outside system only through a connected tool you turned on, and only the specific tools on that connection's allowlist. A system you did not connect is a system the agent cannot reach.

The thread through all of it is that the agent's reach is the work it was handed and the tools you turned on, scoped to your workspace, and nothing wider.

It reaches data through tools, never your database

The way an agent touches your data is the part that matters most for a review. An agent holds no database credentials, no connection strings, and no keys to your stores. It acts only through a fixed, named set of tools, and each tool routes to a permission-checked handler on the platform rather than to a raw query. There is no path by which an agent opens a connection to a data store and reads what it likes, because it was never given the means to, and the platform's own access to those stores runs on managed cloud identity rather than keys an agent could be handed. Even the reads it can make are budgeted: an agent can fetch related records only a small number of times in a single turn, so it cannot sweep your workspace by brute force in one step.

So "what could an agent read if it tried" is bounded by the tools it has, and the tools it has are an enumerated list you can see, not an open door. The least-privilege model is what makes that list legible; this is the data-side consequence of it.

This is also the boundary that holds when an instruction goes bad. An agent that a prompt injection tried to redirect can still call only the enumerated, permission-checked tools it was given, because nothing it can be told widens that set or hands it a database. A hijacked agent reaches no further into your data than an honest one, which is the property that matters when the input an agent reads is not always one you wrote.

What an agent can send out

A fair question follows the one about what an agent can read: what can it send out? The protection a security owner wants stated first is that an agent holds no standing credentials to your systems. It cannot push to your repository, write to a connected tool, or reach a cloud resource except through a short-lived lease that is scoped to one action and written to the audit trail. So an agent cannot quietly authenticate to your systems and move data through them: the credential for every such action is granted at the moment of use, for that action alone, and recorded.

The reassuring detail underneath is that this holds without relying on a network wall. An agent's container can make outbound connections, the way any process that installs a package or calls an API does, so the line that protects you is not a firewall around the sandbox but the credential model: there is nothing the agent can authenticate to your systems with except a leased, recorded grant. What an agent works with is the scoped slice its task needs; what it can do with your real systems is leased, narrow, and on the record. The context an agent sends to the model it runs on is that same scoped slice, the work it was given, not your workspace at large; which model that is and how its key is held is AI models and SDK configs and the secret policy. Where the work runs, and why a bring-your-own host dials out rather than letting the platform reach in, is network boundary and customer-hosted compute.

The four things an agent must never reach, your secret values, another customer's data, another run's data, and your databases directly, sit outside that reach by the way the system is built. The sections that follow take them one at a time.

Your secret values are never in its reach

An agent never receives your standing keys. Your model-provider keys, your Git tokens, and the secrets your connected tools authenticate with live in a per-workspace vault that is set but never read back, by anyone, the agent included. When a step genuinely needs to act, the platform resolves the credential on the server and hands the one command that needs it a short-lived grant that expires in minutes; the agent gets the use of a credential for a moment, never a value it can keep. And anywhere a secret might surface in the exhaust of a run, a transcript, a log, an event, the value is redacted and replaced by its name, so the record shows what was handled without ever showing the secret.

The result a data owner cares about: there is no standing secret sitting in the agent's world to be printed, copied, or carried off, because the value is resolved at the moment of use and gone after.

Another customer's data is never in its reach

Your workspace is a hard data boundary. Every record the platform stores is partitioned by your workspace, and every query an agent's tools make is scoped to that partition, so a read returns your data and only your data. The platform reaches those stores through managed cloud identity rather than shared keys, so there is no master credential an agent could acquire to step outside its partition. A run in your workspace operates on your workspace's data; another customer's records are not in a place it can reach, by the structure of the storage rather than by a filter that has to be applied correctly every time. The architecture view of that storage, how it is partitioned, organized, and addressed, is on the data and tenancy model.

Another run's data is never in its reach

Just as one workspace's data is walled from another's, one run's work is walled from another's. Every agent run happens in its own container, named for that exact run, so the files, the checkout, and the working state of one run are not visible to another. On the platform's own messaging channel, a run can speak only for itself and cannot listen in on another run's traffic. Two runs in the same workspace, even two runs for the same person, do not share a workspace on disk or a view of each other's work, so one run's data never leaks into another's. When a run ends, its container goes with it, so the checkout and the working state inside leave no residue for a later run to find. Where your data sits at rest, and how it is encrypted, is encryption and data handling.

A person's reach into a run is governed too

The boundaries above are about what an agent reaches. A person's reach into a run is held to the same standard. When someone opens a sandbox in their IDE, they do not get a standing door into it; they get a signed session bound to that sandbox, that person, and your workspace, opened in an inspect-only or a write mode, time-limited so it lapses on its own, and recorded as an event of its own. So "who reached into this run, in what mode, and when" has the same kind of answer the rest of this page gives, a record rather than a recollection. The mechanics are on sandboxed execution isolation.

Private work stays invisible without a path to it

Inside your workspace, not everyone sees everything, and an agent inherits the same access model the person directing it works under. A public project or portfolio is readable across the workspace; a private one is reachable only by its owner and by the people a team link grants, and to everyone else it is not just read-blocked but invisible, returning the same not-found answer a record that does not exist would, so its very existence does not leak. An agent acting on a run reaches the private work the run's context grants and no more. Opening a private project to the right people is a deliberate grant, and the agent's reach into that work follows the same grant. The practical weight of invisibility is easy to miss: the name of a private initiative, the fact that it exists at all, never surfaces to an agent a non-member directed, so a confidential effort cannot be inferred from the edges the way a read-blocked but visible record would let it be.

What a reviewer can verify

Each boundary on this page is a fact a data owner can confirm rather than a posture to accept:

• The agent has no database credentials. It acts through an enumerated set of tools, each permission-checked, with no generic query path and no keys to a store.
• Secret values are never returned, to anyone; the agent acts through short-lived leases and redaction keeps values out of every record.
• Storage is partitioned per workspace, and the platform reaches it through managed cloud identity, so a query returns your data and only your data.
• Each run is isolated in its own container, so one run cannot see another run's checkout, files, or traffic.
• Private work is invisible without a path to it, returning not-found rather than leaking that it exists.

And every one of these boundaries that fires, a lease granted, a secret refused, a record changed, lands on the audit and evidence trail, so each is not only enforced but recorded, with secrets shown by name and never by value.

Walking the boundary

Before the Insights team turns agents loose on production-adjacent work, their security owner walks the data boundary with one question per layer. Can an agent read another customer's data? No: storage is partitioned per workspace and reached through managed identity, so a query returns only their own. Can it read our secret values? No: the vault is write-only, and an agent acts through leases that expire in minutes, with values redacted from every record. Can one run see another's work? No: each run is its own container, walled on disk and on the wire. Can it reach a database directly? No: it has no credentials and no generic query, only a named set of permission-checked tools. Each answer is something the platform engineer can show in the configuration and the records, not something the team has to take on faith, and the review that the security owner expected to be a fight turns into a walk-through.

Why data access works this way

An agent is treated as capable code that does useful work, not as a trusted member of staff, and that one stance decides the whole data model. A trusted-insider design would hand the agent broad read access and rely on it to stay in its lane; the day it strayed, through a bad instruction or a prompt injection, the blast radius would be everything it could see. So the model starts from the other end. The agent reaches the work it was handed, through tools that check permission, scoped to your workspace, and the things it should never touch, your secret values, another customer's data, another run's data, your databases directly, are not behind a setting it could be talked past but outside the structure it runs in.

That is what lets you give an agent real access to do real work without giving it the run of your data. The access it has is legible, the boundaries it cannot cross are structural, and both are things you can show a reviewer rather than promise them.

For the person who owns security, this is the answer to "what can an agent reach in our data." It reaches the work it was handed through permission-checked tools scoped to your workspace, and your secret values, another tenant's data, and another run's data are out of its reach by construction, each one a boundary you can verify rather than trust.

For a data owner, the model is that an agent has no keys to your stores and no general query. It reads what its tools allow, your storage is partitioned per workspace, and nothing an agent touches escapes that partition.

For an engineer, the practical version is that an agent works on the plan, the bug, or the repo you pointed it at, in its own container, with leased credentials and no standing keys. You do not hand it data; it fetches the scoped slice its task needs.

For a prospect evaluating the platform, this is how agent capability and data safety stop being in tension. The agent is capable inside a boundary you can read, and the data it must never reach is outside the structure it runs in, not behind a rule that has to hold every time.