Komal Mangtani, Can Lin, Projjal Ghosh, and Iuliu Rus
A year ago the question about enterprise AI was, “Can we build agents?” Now we’ve reached the point where the question has flipped, and we are asking, “Can we govern them and safely feed them at scale?”
Today 80% of organizations have AI deployments, however only 21% companies currently have a mature model for governance of autonomous agents, leading to a Gartner prediction of the Great AI Rollback: 40% of enterprises will demote or decommission autonomous AI agents due to governance gaps identified only after production incidents occur.
These are clear indicators that governance cannot be a bolt-on, especially when we are moving from the era of chatbots that just talk to agents that actually do things. This new scenario raises the goalposts of governance even more: from managing content (Was the answer right?) to managing conduct (Should the agent have been allowed to do that, touch that, persist that, share that?). Done well, though, agent governance becomes an engineering advantage and can even open opportunities for new product offerings.
Why agents break traditional governance
Governance for agents has to be designed from scratch. It cannot be ported from past applications, not reused from old solutions. Two comparisons explain why.
AI agents are not like traditional enterprise applications. Enterprise applications move data through a well-defined set of artifacts, with deterministic execution, and are constrained by managed safety measures. AI agents, however, can persist data at any step of execution, are probabilistic, and produce unified outcomes for end-to-end tasks that require dynamic safety controls. An agent touches many systems across retrieval, tools, code execution, artifact generation to create new persistence points dynamically. Their execution paths are indeterministic, which makes its touch points almost impossible to track in any contained form. Governance for agents has to cover conduct and execution, not just output content.
Agents are not like humans either. Humans have ethics to govern their behavior, agents need a constitution that codifies that behavior. We have to encode constraints explicitly. Furthermore, humans act linearly, performing one action at a time; agents backed by massive compute engines, act in parallel, exploring many paths at once.
The intrinsic indeterminism of agentic outcomes combined with massive parallelism requires a different approach to Agentic Governance.
Where exposure shows up across an agent run
Governance controls for a non-deterministically acting agent, whose ethics and conduct can be overwritten by a prompt, are hard to plan, to say the least. We break down the agent into four pillars, as depicted in Figures 1 and 2.
Figure 1. The four colors of a typical agent run
Figure 2. Where exposure shows up across the agent run
Those four pillars are:
- Input: Includes prompt injection, sensitive content sitting in user prompts, and unmasked conversation history.
- Context infra: Unauthorized data access is the obvious risk, but the subtler one is sensitive data leaking through tool execution itself such as the RAG index and the data tools. Every backend service is a new potential leak point.
- Agent + LLM: The agent executes as the user’s proxy and inherits everything the user can see. It produces cross-user insights it should not have, and the model uses sensitive data in its reasoning.
- Output: Trajectories sit in plaintext, sensitive insights leak downstream, and unsafe actions are taken.
We designed for six recurring capabilities:
- Scanning, masking, and encrypting: Applied to in-between data movements, not only at sources and sinks.
- Agent identity and attribution: Not just “on behalf of” the user, an agent.id that propagates end to end so every read, decrypt, and tool call carries who actually acted.
- Sensitivity-aware enforcement at query and tool boundaries: Policy evaluated at every fetch and every tool call, not only at the initial gate.
- Output closure: A single controlled exit for every result. The risk is not only in the response, it is in the trace, the embedding, and the log, and lack of output closure can turn those into leaks.
- End-to-end isolation of data and derived artifacts: The boundary follows the data wherever the agent takes it, so indexes, embeddings, and trajectories inherit the same protection as the source.
- A governed environment that bounds tools, inputs, and outputs in one scope: Rather than scattering point controls across the stack.
Why out-of-the-box agent frameworks don’t close the gap
Modern agent frameworks are genuinely good at orchestration: tool/function calling, state management, human-in-the-loop breakpoints, tracing and observability, basic prompt guards. That is real progress.
What they do not do is anything you would call enterprise governance. There is no native agent identity that propagates end to end. Classification-aware policy is lacking at the query or tool boundary. Secure code-generation or runtime execution guardrails are lacking. Trajectories and outputs are plaintext across many persistence points. Access management is not fully agent-aware in ways that can keep workflows alive when an agent hits a permission wall. And finally, no governed environment bounds the full data path in one scope.
Frameworks help agents act. They do not constrain how they act around sensitive data.
Stopping the bleed: the point solutions we built first
We did not solve any of this in one shot. Through 2024 and 2025 we worked use case by use case, unblocking the teams whose work AI could not yet touch: Performance reviews. HR reviewing employee data through our widely deployed top-level agent. Querying sensitive organizational data. Early support for agent reasoning over sensitive chats. Each fix unblocked one workflow that AI had been locked out of, and each fix taught us one more capability we needed long-term.
Stacked together, those fixes produced a set of capabilities that maps onto the same four-color canvas—one capability for each exposure layer (see Figure 3).
Figure 3. Capabilities mapped to each layer, backed by isolation domains
Those capabilities are:
- Agent identity (agent.id): Most agent frameworks operate “on behalf of” the user. Agent identity taints the user credential with an agent-specific attribute that propagates end to end, so downstream systems can tell which user invoked, which agent acted, and what policy allowed it.
- Agent-aware access control: ABAC (attribute-based access control) evaluates each request against a set of attributes about it (who is asking, what is being asked for, and from where) rather than against a fixed role assignment, which is what makes it expressive enough to reason about agents. We used data classification, agent identity, and agent environment (sandboxed, internal, external) to evaluate policies at the query or tool boundary. The decision is more flexible than binary yes or no, and is instead based on allow, aggregate, redact, or deny, depending on sensitivity and context.
- Agent-based access management: When an agent hits a permission denial, the classic flow stops the whole session. Then the user files a ticket, waits hours or days, and comes back. Where policy permits, the agent-based access-management tool handles triage, least-privilege fallback, and auto-approval. This reduces the friction-induced bypass risk: When the governed path is slower than the workaround, the governed path is avoided. (This was the subject of a separate talk, Agentic Solution for Data Warehouse Access, at last year’s @Scale conference).
- Agent artifact review: Agentic coding has two risk windows: pre-commit (generation time) and runtime (execution time, including code that never becomes a diff). Our tool to review agent artifacts shifts left at generation via context files, enhanced prompts, and CI checks to guard execution so that unsafe disposable code cannot quietly exfiltrate data.
- Multi-tenant RAG/sensitivity-driven retrieval: Makes sure what gets retrieved into the context window for User A’s question cannot include data ingested for User B. Closes cross-user leakage in the Context Infra layer.
- Isolation domains (IDS): Domain-scoped encryption with output closure. We will deep-dive this in the next section.
- DataVM: The trusted environment that bounds inputs, tools, and outputs in one scope. We will deep-dive this after IDS.
The same Meta Engineering post mentioned above, Agentic Solution for Warehouse Data Access, provides additional background.
The principles those fixes taught us
When we stepped back from the scatter, four principles stood out consistently—and they are the ones IDS and DataVM are designed to realize end to end:
- Identity-keyed encryption follows the data: A domain key tied to a user (or a use case) covers data, derived artifacts, and trajectories under one scope. The unit of protection is the identity, not the storage tier.
- Governance at the boundary, not the surface: Policy gets evaluated where data enters the agent’s reach, the query or tool boundary, rather than where it eventually lands. That is the only way to stop a downstream surface from becoming an unsupervised plaintext store.
- Output closure: One controlled exit point, with provenance, sensitivity scanning, and per-table release conditions applied at that gate. Better one explicit door than six implicit ones.
- Environment over scattered controls: Inputs, tools, execution, and outputs bounded in a single governed scope, so policies compose by construction instead of by review.
Isolation Domains: single secure substrate
An isolation domain is a security boundary defined by a domain ID that binds three things: encryption key scope, authorization policy, and operational guardrails. It provides a crisp guarantee: If data is in the domain, it is encrypted at rest, and only authorized identities for that domain can decrypt.
What counts as “agentic data” inside that boundary is wider than most teams expect. Isolation domains encrypt the full surface: the data itself, the knowledge graph, the surrounding context, reasoning trajectories, conversation history, prompts, evaluation runs, and outputs. All of it falls under the same domain-scoped key.
Figure 4. Isolation domains protecting the four areas across the agent path
Without a single substrate like this, teams keep hitting the same three failure modes:
- Coverage gaps: New logging surfaces ship without encryption.
- Ambiguous access boundaries: It is unclear which identities can decrypt which artifacts.
- Retrieval and derived outputs become leaks: Indexes and embeddings quietly become brand-new plaintext stores. Isolation domains close that whole class of problem with one consistent boundary.
What IDS gives us is the cryptographic boundary. We still need an environment that puts the boundary to work.
DataVM: trusted data environment
If isolation domains are the cryptographic boundary, DataVM is the environment that puts that boundary to work—a sessionized, identity-tagged container that bounds inputs, tools, execution, and outputs in one scope.
The agent itself sits outside the DataVM. It hands a prompt in and receives a governed handle back. It never sees raw data.
Figure 5. DataVM logical container: Configure / Run / Post-process, with outbound arrows to artifact and audit paths
Agent-Aware ABAC sitting under the runtime is how we prevent a superuser’s agent from inheriting superuser blast radius. And the post-process step is what lets us unleash exploration inside the box during discovery: If Data Provenance gates the export only to the data that actually produced the output, we can allow the agent to browse broadly while still releasing narrowly.
One agent, many DataVMs over its lifetime. Most asks are one-shot (e.g., Why did DAU drop on Saturday?) and run in ephemeral mode: one question, one fresh box, discarded when done. For multi-turn conversations we run in semi-persistent mode: The box stays warm for that one conversation and is torn down at logoff. The rules at the gate do not change between modes—what data was used, is any of it sensitive, is the caller allowed to see it. If something goes wrong, the blast radius is bounded to one person and one conversation, and it’s gone when they log off.
DataVM is the natural convergence of the earlier execution islands. Once enough of the point capabilities were in place, we realized we were not adding controls anymore but constructing an environment.
Our target outcomes
A governed execution should make sensitive work easier, not harder. Our target outcomes were:
- Right data, right time, right harness: Agents access sensitive data only through certified, encrypted pathways. The agent doesn’t get to invent its own.
- Sensitive workflows become first class: Reasoning over sensitive chats is just how the agent works, not a special case users avoid.
- Friction drops: Access interruptions shrink from hours or days to seconds or minutes, via auto-approval where policy permits.
- Regulatory-ready by construction: Encryption, audit, and retention are baked into the infrastructure, rather than retrofitted under deadline.
- Build for your highest-volume agent first, then generalize: We started with one widely used agent, and every mechanism downstream was easier because it was already battle-tested.
What’s still unsolved
There is plenty of work ahead of us to make safe-by-default agent execution the normal path. We are actively working on:
- Multi-agent policy composition: Policies need to compose when agents delegate to each other, collaborate, or reuse intermediate state. We continue to explore ways to safely compose policies across multiple agents.
- Derived data and memory: Embeddings, summaries, trajectories, evals, and artifacts can preserve sensitivity well beyond the original query. How do you honor “right to be forgotten” when the data lives in an embedding?
- Agent identity and accountability: We have the primitive (agent.id). The end-to-end attribution story across systems is still being built.
- Developer experience: Safe defaults must be easier than the bypass. The moment governance becomes a tax, people may route around it.
If any of this excites you, we are hiring.
