Zero Trust for Data in an Agentic Enterprise

Mission users are giving way to mission copilots. Before the Department of War can trust an AI agent with its data, it needs one consistent way to authorize every request for it — human or machine.

The Department of War is entering an era where most people won’t query a database — they’ll ask a copilot, and the copilot will ask an agent, and the agent will ask several data platforms at once. Zero Trust for Data is the discipline that makes that chain trustworthy. It is not a product, a data-federation project, or an extension of identity management. It’s an operating model that authorizes every request for mission information — who’s asking, on whose authority, for what purpose, under what conditions — and constrains the answer to the least data needed, no matter whether the requester is a person, an application, or an autonomous agent.

This piece lays out that model in eleven design principles, maps it to the Department’s Zero Trust Data Pillar activity by activity, and explains — carefully and with explicit boundaries — where Immuta fits.

• The shift
  From authenticating a session to authorizing every request, continuously.
• The risk
  An agent inheriting a human’s full access is a confused deputy waiting to happen.
• The fix
  One authorization layer, distributed enforcement, common evidence — not centralization.

The Shift: Why Zero Trust for Data Must Evolve

Zero Trust for Data is not about where mission data lives. It is about how every request for mission data is consistently authorized — regardless of whether the requester is a human, an application, or an AI agent.

Zero Trust hasn’t failed. Its environment has moved.

The framework began with a simple insight: network location is not a proxy for trust. Users, devices, and applications have to be authenticated and authorized based on current conditions, not on being inside a perimeter. The Department’s Zero Trust framework built seven interconnected pillars around that insight, with data positioned at the center as the protected resource the other six exist to secure.

That foundation still holds. What’s changed is the number, variety, and behavior of the things asking for data.

A decade ago, access was mostly direct: an analyst authenticated to an approved platform, opened a dashboard, ran a query. Role, entitlement, and platform permission could do most of the work, because applications followed predictable workflows and a human was usually one step away from the data.

AI breaks that assumption. A user can now ask a chat interface a question without knowing which databases, documents, or APIs will answer it. A mission copilot decomposes that question into subtasks, invokes several specialized agents, and synthesizes a recommendation. What looks like a single conversation may be dozens of data requests across multiple systems — and every one of them raises its own authorization question: is the agent approved to act for this person? Is this data appropriate for the mission and classification domain? May the result be exported, shared, or used to trigger an action? Has risk changed since the interaction began?

That shift moves the unit of control from the login event to the individual request — and, increasingly, to what happens to the answer afterward. An AI system doesn’t just retrieve records; it turns them into summaries, embeddings, recommendations, and machine-generated actions. Those derived products can carry the same sensitivity as the source data long after the source itself has left the requester’s screen. Zero Trust for Data has to protect both the access and what happens to the information after access is granted.

None of this is solved by consolidation. The Department’s mission data will keep living where operational responsibility puts it — cloud, on-premises, tactical edge, coalition networks, classification domains. The answer isn’t one repository. It’s one consistent, logical authorization model applied everywhere data already lives: enterprise policy sets mandatory guardrails, mission owners keep authority over their own data, and identity, purpose, sensitivity, and risk get evaluated the same way no matter which door someone came through.

The Shift in Consumption: How AI Changes Data Consumption

Zero Trust for Data must govern the complete data interaction — not only the identity that begins it. Every retrieval, transformation, output, and action should remain attributable, policy-controlled, and continuously authorized.

For most of enterprise computing, using data required knowing where it lived.

A user needed to know which system held the information, how it was organized, and which query language would get it out. That specialized knowledge kept direct data access to a relatively small population of analysts and engineers.

Generative AI removes that barrier. A mission user can just ask — “What supply disruptions are most likely to affect this operation in the next 30 days?” — and an AI system identifies sources, runs the retrievals, reconciles conflicting results, and generates a recommendation. To the user, it’s one conversation. To security, it can be dozens of data requests across multiple systems.

That creates a much larger population of mission analysts, and it multiplies the paths through which the same mission data gets reached:

Every one of those paths should resolve to the same policy. A conversational interface is not a way to bypass the rules that would apply if the same user queried the source directly.

The harder problem is that the person who starts an interaction may be several steps removed from the system that actually returns the data:

Anatomy of one request
A single question can fan out into a long, differently-privileged chain

Each link is a distinct security subject — human, copilot, agent, platform — with its own authorization question. None of them should inherit blanket trust just because a person began the conversation. That’s the core failure mode of agentic AI: authenticating step one says nothing about what step five is allowed to do.

Agentic access also raises a question most access-control models never had to ask: should the requester even be told that something exists? The existence of a dataset, a source, or a program can itself be sensitive — which argues for a progressive model rather than a single all-or-nothing gate.

A mission analyst might first see only catalog metadata or a summary; the system may satisfy the request entirely with a masked, aggregated, or synthetic answer before a raw record is ever touched. That’s not just least privilege, which limits what a subject may do — it’s least data: limiting how much the subject actually receives.

And what comes back isn’t always “just an answer.” A model can summarize classified reporting, infer a relationship no single source stated outright, or generate a risk score — outputs that can be as sensitive as the source material even though they don’t reproduce it verbatim. Classification, handling restrictions, and provenance should travel with that generated content. Where they can’t be inherited automatically, the system should trigger a review rather than let the output travel unmarked.

None of this should require a separate security model for “AI” versus everything else. A SQL query, a dashboard, a chat prompt, and an agent’s tool call are four different interfaces to the same underlying event — an identity requesting to use mission data for a purpose — and every one of them should answer to the same policy, even when the resulting output looks different in each case.

The Definition: Defining Zero Trust for Data

Every method of consuming mission data — direct query, dashboard, enterprise chat, copilot, application, or autonomous agent — should be governed by one consistent authorization model, even when the resulting data experience is different.

Zero Trust for Data applies Zero Trust principles to the discovery, authorization, use, movement, transformation, and protection of enterprise information. It begins with one premise:

No request for mission data should be trusted solely because of who initiated it, where it originated, which application submitted it, or whether a similar request was previously approved.

Every request has to be evaluated against current, authoritative context; limited to the minimum information and operations an approved mission purpose actually requires; enforced as close to the data as possible; and watched continuously while the interaction is underway.

The phrase “Zero Trust” invites a misreading — that no person or system can ever be trusted. That’s not a workable model for mission operations, and it isn’t what the framework means. The goal is to eliminate implicit, permanent, unexamined trust, not trust itself. A person can be explicitly authorized to perform a mission function; an agent can be delegated authority to complete a defined task — but none of those decisions should create unlimited or enduring authority. In this model, trust is:

That reframing moves the unit of control. Traditional access administration assigns a user to a role, grants the role access to an application, and lets that grant stand for months or years even as responsibilities change.

Answering that well means the result can’t only be binary. A requester may have a legitimate need for some of what’s in a dataset without needing every field, every record, or full precision — which is the real distinction between two ideas that tend to get used interchangeably:

Both matter, and both need to be true at once: a person or agent can be legitimately authorized for a task while still receiving only a constrained view of the underlying information — often enough to satisfy the mission need without ever exposing the full source.

Data can’t answer any of this alone; it depends on the other Zero Trust pillars for context. The User Pillar supplies identity. Device posture describes the endpoint. Applications and Workloads identify the agent or service acting. Network and Environment contributes location and path. Automation and Orchestration distribute the resulting policy and coordinate response. Visibility and Analytics correlate the outcome with everything else happening across the enterprise. Zero Trust for Data is where those signals convene around one decision: what may this requester actually have, right now.

The Authorization Layer

Every use of mission data should be explicitly authorized according to current identity, mission, purpose, sensitivity, operation, and risk — and constrained to the minimum data and authority required to accomplish the approved task.

Zero Trust for Data needs a mechanism that converts policy and mission context into an enforceable decision at the moment the data is actually used. That mechanism is the authorization layer.

It sits between three tiers: the humans, agents, and APIs asking for information at the top; the policy, request-handling, observability, and compliance functions that make the call in the middle; and the databases, warehouses, applications, APIs, and storage systems where that decision is actually carried out at the bottom. A single user request can produce multiple retrievals, tool calls, and generated outputs; a login decision made at the top of that chain can’t govern everything that happens further down. Here’s the whole shape of it:

None of what the middle tier evaluates should be accepted on faith. Human identity, agent identity, and delegated authority should trace back to authoritative sources — not a free-text claim from the requester. Mission and purpose should be attributable to an approved workflow, case, or data-use agreement, not an unverified explanation typed into a prompt. Device posture, data sensitivity, and current risk all factor in too, and no single signal should be allowed to decide the outcome alone.

The layer itself is logical, not necessarily centralized. A cloud data platform may support native row- and column-level controls; a tactical system may only expose a handful of preconfigured views; a classified environment may not be able to call an external decision point at all. What has to stay consistent is the intent of the policy and the semantics of the decision — not the physical location where it’s evaluated. Section 5 develops that distinction fully.

A mature authorization layer also treats the outcome as more than allow-or-deny:

Take a logistics planner asking a mission copilot to identify supply risk for a planned deployment. Behind that single prompt, the copilot may interpret the question, invoke a planning agent, query inventory data, pull transportation schedules, request weather and threat information, combine the results, generate a risk assessment, and recommend a mitigation — eight distinct operations from one sentence. The authorization layer shouldn’t treat that as one undifferentiated request. Each operation should carry enough context — the initiating human, the active agent, the delegated task, the requested source, the permitted result — for the system to evaluate and record it individually, without interrupting the planner with eight separate approval prompts.

That’s what the bottom tier in the diagram is for. Policy administration — who owns a rule, what mission or legal basis supports it, when it expires — is a different function from policy enforcement, the technical mechanism that actually applies it on a given platform. And enforcement should sit natively inside the platform holding the data, not behind a separate proxy that every query has to pass through first.

That matters for two reasons. Consistency: a native control applies the same way whether the request arrives through a governed application, a direct connection, or an agent’s tool call — there’s no side door around it. And performance: mission queries against a large warehouse or a high-volume operational database are already expensive; adding an external security hop in front of every one of them is the kind of tax that gets quietly disabled the first time it slows down an urgent analysis. Native, in-platform enforcement is what lets this hold up under real query volume instead of becoming the thing people route around.

Every one of these decisions needs to leave a trace. A decision that can’t be reconstructed — who asked, on whose behalf, under which policy, with what result — is difficult to trust and impossible to assess. And it can’t be static: a decision that was correct when a session began stops being correct the moment a credential expires, a device falls out of compliance, or an agent tries to invoke a tool outside its assigned task. Section 7 covers how that adaptation actually works.

None of this replaces the Department’s ICAM, endpoint security, data platforms, or SIEM. It connects them — coordinating identity, posture, data governance, and analytics around one objective: every human, application, and AI agent receives only the mission information and authority appropriate to its current purpose and conditions.

The Operating Reality: Distributed Data, Consistent Authorization

The authorization layer should translate authoritative identity, mission, data, workload, and risk context into an enforceable decision at every governed data endpoint — without requiring mission data or enforcement to be centralized.

The Department will never run one uniform data environment, and Zero Trust for Data shouldn’t pretend otherwise.

The Department will never run one uniform data environment, and Zero Trust for Data shouldn’t pretend otherwise.

Mission data will keep living across enterprise clouds, Component platforms, tactical systems, coalition networks, and multiple classification domains — not because of a deliberate “federation” strategy, but because different organizations hold different authorities, different missions need different systems, and different classification boundaries impose different controls. That’s simply the natural consequence of how the Department is organized.

It’s worth being precise here: federation may be a reasonable technical pattern in some environments, but it isn’t the point of this argument, and it shouldn’t become the headline. The point is authorization. Whether or not a given environment is formally “federated,” the same questions apply everywhere — who’s asking, on whose authority, for what purpose, under what policy, with what result? A consistent authorization layer answers those questions the same way at every endpoint, without requiring every endpoint to become technically identical.

A common model doesn’t mean one policy engine that every request passes through — that won’t survive contact with a tactical platform that loses connectivity, a classified system that can’t call an external decision point, or a coalition environment enforcing both Department policy and a partner’s release conditions. What has to travel consistently is intent, not infrastructure:

That consistency needs a hierarchy, not a single flat rulebook. Not every decision should be made centrally — but local flexibility can’t be allowed to bypass Department-wide requirements either:

This only works if identity, mission, purpose, and sensitivity mean the same thing everywhere they’re used to make a decision. The Department doesn’t need one identical schema across every system, but it does need shared semantics for the handful of attributes that cross environments — including agent identity, which has to communicate more than a generic service-account name: what type of agent it is, who owns it, what it may invoke, and whether it’s acting autonomously or under direct supervision.

That’s portability of meaning, not portability of a literal rule. A policy that says “personnel on Mission Alpha may access logistics records relevant to that mission, with direct identifiers masked unless the task requires identity resolution” gets implemented differently almost everywhere it applies — row filters and masking in a warehouse, redacted search results in a document service, omitted fields from an API, a policy-filtered retrieval for a copilot. The mechanisms differ. The outcome doesn’t.

That last case — a copilot or retrieval-augmented system — deserves its own emphasis, because the sequencing matters. If authorization only happens after generation, the model has already seen information the requester wasn’t permitted to use:

This matters more as one AI harness connects to many distributed endpoints — the harness itself should never become a privileged aggregation layer that quietly bypasses endpoint policy. It also raises the stakes on controlling copies: every prompt, cache, embedding, and intermediate file is a new data endpoint with its own obligations, and distributed data makes it easy to lose track of how many of those now exist.

Three environments deserve specific mention, because each bends the model in a different direction:

The test for all of it is outcomes, not architecture diagrams: do equivalent requests get equivalent, explainable results across every environment they touch? That’s a question the Department should be able to answer with a repeatable test — not an assumption made because several platforms happen to share an identity provider.

The Human-Agent Boundary: Humans, Agents & Delegated Authority

The Department’s data endpoints will remain distributed as a natural consequence of mission, organizational, classification, and operational requirements. Zero Trust for Data should standardize authorization intent, context, and evidence — while allowing decisions to be enforced locally at each governed endpoint.

An AI agent is not a transparent extension of the person who invokes it. It’s a different security subject entirely.

The human brings organizational affiliation, training, clearance, mission assignment, and judgment. The agent brings a software identity, an owner, a model and runtime, a tool set, and a level of autonomy. Those are not the same thing, and treating an agent as an invisible continuation of its user creates exactly the failure mode Zero Trust exists to prevent: excessive authority, weak attribution, and unclear responsibility. The agent may use tools the human never selected, retrieve information the human never explicitly asked for, or retain data somewhere the human never sees.

So the architecture has to recognize both identities at once — the person who delegated the work, and the agent that performed it — and calculate the agent’s effective authority as an intersection, not a copy:

Delegation should be attenuated: every hand-off preserves or reduces the authority of whoever granted it, and never silently increases it. If the human lacks access, the agent can’t obtain it through a technically privileged service account. If the agent isn’t approved for a data domain, the human’s own access doesn’t extend to cover it. And as work gets delegated further down a chain — a copilot to an orchestrator to a specialized agent to a single connector — authority should keep narrowing, not stay flat:

For that to work, agents need to be registered as first-class enterprise identities — not an API key with a name attached, but enough context for the enterprise to know what the agent is, who’s accountable for it, and whether its current behavior still matches its approved purpose:

That registration also does double duty as a defense against a very old vulnerability wearing new clothes. A retrieval agent with broad access to sensitive records, fed an untrusted document containing hidden instructions, can be talked into retrieving more than it should and sending it somewhere it shouldn’t — a classic confused-deputy problem, just triggered by prompt injection instead of a malformed request. The fix is the same either way: the decision has to rest on who initiated the task and what purpose was approved, never on what the agent is technically capable of reaching.

Data authorization and action authorization also need to stay separate as AI moves from answering questions to recommending and taking action. An agent might be cleared to identify a readiness shortfall without being cleared to change a supply allocation; a copilot might draft a course of action without being able to submit it. The transition from information to action should always be its own explicit checkpoint — and how much of that checkpoint needs a human depends on risk and consequence, not on a blanket rule requiring a person to approve every step. Low-risk, reversible operations can run automatically. Irreversible or high-consequence ones shouldn’t.

One more wrinkle: agents that persist across sessions can accumulate context from multiple users, missions, or classification levels, and act later on information that’s no longer current. A prior authorization to retrieve something isn’t standing authority to reuse it for a different task next week — a persistent agent should reevaluate identity, purpose, and risk every time it resumes work, the same as if it were starting fresh.

In practice, this plays out simply: an analyst asks about aircraft readiness, a maintenance agent gets delegated exactly that one query, the result comes back masked and mission-scoped, and any proposed schedule change still needs separate sign-off. Section 9 walks through that full interaction end to end.

The Feedback Loop: Continuous Authorization & Response

Humans and AI agents should operate within one authorization framework, but every agent must remain independently identified, explicitly delegated, task-bounded, time-limited, and continuously accountable for each tool, data, output, and action request.

A correct decision at the start of a session doesn’t stay correct for its duration.

Missions expire. Devices fall out of compliance. Agents attempt tools outside their assigned task. Datasets get reclassified mid-workflow. A decision that was right when a session began has no way of knowing that any of this happened three requests later — unless authorization keeps running as a loop, not a single gate at the door:

Two things are easy to conflate here, and shouldn’t be. Authentication establishes confidence in an identity. Authorization decides what that identity may do right now. Reevaluating policy on every request is continuous authorization — a user can stay authenticated while losing authorization for a specific mission the instant their assignment changes, and the two functions need to stay distinct rather than collapsing into “the user is logged in, so the request is fine.”

Detection in this loop isn’t about flagging anything unusual — mission operations create legitimate spikes and one-off deviations constantly. The useful question isn’t whether behavior differs from an average baseline; it’s whether it differs from the authorized mission pattern. AI adds a specific set of behaviors worth watching for:

None of those prove compromise on their own. What they should do is trigger the loop’s adapt and respond stages — in proportion to how serious the deviation actually is:

None of that should depend on a person reviewing every alert in real time. The goal is policy defined well enough in advance that low-risk, well-understood operations clear automatically, and only the genuinely uncertain or high-consequence ones interrupt a human — fast enough to stay invisible during normal operations, and strict enough to stop things the moment risk actually changes.

The Department Alignment: Alignment with the DoW Zero Trust Strategy

Zero Trust for Data should operate as a closed control loop in which every governed request is authorized, observed, evaluated for changing risk, and subject to immediate adaptation or response throughout retrieval, transformation, output, and action.

None of this is meant to replace the Department’s Zero Trust framework. It’s meant to operationalize it.

The Department’s own strategy is explicit that it’s a strategy, not a solution architecture — Components are expected to design implementations that achieve the prescribed outcomes for their own missions and environments. That means alignment shouldn’t be demonstrated by matching a commercial feature to a capability number. It should answer four harder questions: what Department activity or outcome is being addressed; what role the authorization layer actually performs; what other enterprise controls it depends on; and what evidence proves the outcome is operating, not just configured.

The Data Pillar is the natural anchor, and its seven capabilities map fairly directly onto the architecture in this piece:

Capability	Requirement	Authorization-layer role	Coverage
4.1	Data Catalog Risk Alignment	Contributes discovery, sensitivity classification, and change detection to the catalog	CONTRIBUTING
4.2	Enterprise Data Governance	Operationalizes governance decisions into executable, versioned policy	CONTRIBUTING
4.3	Data Labeling & Tagging	Consumes these attributes to drive every retrieval and least-data decision	INTEGRATED
4.4	Data Monitoring & Sensing	Supplies structured data-use evidence to the wider monitoring architecture	CONTRIBUTING
4.5	Encryption & Rights Management	Enforces permitted use on supported paths; doesn’t replace the encryption substrate	DEPENDENT
4.6	Data Loss Prevention	Native for what it can directly constrain; contributing to the rest of DLP	CONTRIBUTING
4.7	Data Access Control	The direct alignment point — evaluates full context and enforces the decision	NATIVE

Table Legend

• NATIVE: performs the function directly
• INTEGRATED: via an approved connection
• CONTRIBUTING: supplies context or telemetry
• DEPENDENT: another service provides it
• OUT OF SCOPE: not performed at all

The same discipline applies outward from Data into the other six pillars. ICAM establishes and validates identity; the authorization layer uses identity as one input rather than replacing ICAM. Per-request policy reevaluation is continuous authorization, not by itself continuous authentication — that capability belongs to identity and session-assurance services. A data authorization platform can function as a data-domain policy decision point, not the Department’s enterprise PDP for every pillar. At the top level, the alignment looks like this:

Zero Trust for Data requirement	Department alignment	Authorization-layer role
Know what data exists and how it’s governed	4.1 · 4.2 · 4.3	Consume and contribute catalog, ownership, sensitivity & policy metadata
Authorize the minimum appropriate data and operation	4.7 · 1.2 · 1.7 · 3.4 · 6.1	Evaluate identity, mission, data & risk context; produce an enforceable decision
Govern AI agents and delegated access	1.9 · 3.4 · 6.1	Preserve NPE identity, delegation, task scope, and attribution
Monitor access, use, transformation, movement	4.4 · 7.1–7.4	Produce structured telemetry for enterprise correlation
Control rights, sharing, and data loss	4.5 · 4.6	Apply supported usage restrictions; integrate with encryption & DLP
Reevaluate authority as conditions change	1.8 · 3.5 · 7.6	Consume risk context; adapt authorization; request response actions
Apply consistent policy across distributed endpoints	4.2 · 4.7 · 6.1	Preserve policy intent while enforcing through local platform controls

Every claim in that table should come with a way to check it — a specific test and a named evidence artifact, not just a narrative description:

Field	Required content
Department activity	Exact activity ID, maturity level, outcome, and end state
Architecture control	The policy, decision, enforcement, monitoring, or response mechanism
Product role	Native, integrated, contributing, dependent, or out of scope
Dependencies	ICAM, device posture, platform controls, DLP, SIEM, cross-domain, or other services
Test	A repeatable scenario demonstrating the expected outcome
Evidence	Configuration, policy version, decision record, query result, log, or response record
Limitation	Unsupported platform, bypass path, manual dependency, or residual risk
Remediation	Required integration, process, control, or roadmap action

That level of precision changes how this should be pitched to government stakeholders — and a few claims are worth explicitly retiring:

Broad claims are easier to challenge and end up obscuring what the platform actually does well. The narrower, bounded version is also the more strategically significant one: the Department can’t get to a coherent Zero Trust for Data operating model unless identity, mission context, data attributes, agent delegation, endpoint enforcement, and evidence are connected at the moment mission information is actually used — and that connective role is worth claiming precisely, rather than inflating.

Formal Department publication titles should stay as issued — the DoD Zero Trust Strategy and DoD Zero Trust Reference Architecture v2.0 keep their formal names regardless of which secondary title this paper uses in narrative text. Because activity descriptions and maturity guidance continue to evolve, the capability crosswalk above should be revalidated against the current DoW CIO library before external publication.

The Implementation: How Immuta Implements It

Department alignment should be demonstrated at the activity and outcome level. Every Zero Trust for Data claim should identify the authorization-layer role, required enterprise dependencies, a repeatable test, and the evidence proving that the control operates as intended.

Everything above needs more than a policy document behind it. It needs an operational capability that connects authoritative context to the controls governing how data actually gets used.

Immuta can provide that capability at the data layer — and it’s worth being precise about the boundary:

That role runs on an actual platform, not just a diagram. Four modules carry it, sitting on one policy engine and connected natively to wherever the data already lives:

Govern, Request, Agentic Access, and Comply are four separate workflows for four separate moments — authoring policy, requesting an exception, provisioning an agent, proving compliance. They compile into one policy engine and report to one audit trail, not four disconnected tools.

Underneath those four modules, one set of inputs drives every decision the policy engine makes:

In practice, that capability breaks down into six functions Immuta performs at the data layer:

01 Establish usable knowledge of the data

Immuta scans connected databases, warehouses, cloud storage, and APIs to discover data sources, classifies sensitivity — PII, PHI, classification marking — using pattern- and ML-based detection, and attaches an accountable owner. Without that inventory, a policy has no attributes left to evaluate against.

02 Translate mission policy into data decisions

A policy owner writes one rule in plain language — an ABAC, RBAC, or purpose-based condition — and Immuta’s policy engine compiles it into whatever control the target platform actually supports: a row filter in a warehouse, a masked view in a database, a scoped credential for an API. The intent is authored once; the mechanism differs by endpoint.

03 Enforce least privilege and least data

Row filtering, column masking, redaction, aggregation, and dynamic transformation on supported, governed paths — constraining not only whether a request is allowed, but how much of the underlying information a requester actually receives, down to a masked field, a sampled result, or a synthetic substitute.

04 Support one human-and-agent policy model

The same evaluation runs for a direct query, an application, or a delegated agent, drawing on a registered record of what the agent is, who owns it, and what it may invoke. Effective authority is calculated as the intersection of the human’s delegation, the agent’s approved scope, and the mission’s purpose — never a copy of the human’s full access.

05 Produce evidence of every governed decision

Every decision — who asked, on whose behalf, under which policy version, what was returned, masked, or blocked, and why — is captured as a structured, queryable record rather than a log line to reconstruct after the fact, and is exportable to enterprise SIEM, UEBA, and DLP.

06 Participate in adaptive authorization

When a connected system reports a change — a device falling out of compliance, a credential nearing expiry, an access pattern outside the authorized mission — Immuta re-evaluates the request in place: narrowing the result, requiring step-up approval, or revoking access automatically, without waiting on a person to review every alert.

Laid out flat, those six read like a checklist. In practice they’re two different kinds of work: two run continuously in the background, and four run in a loop on every single request.

This is the control loop from Section 7, implemented. Catalog & classify (01) and compile policy (02) run continuously, in the background. Evaluate (04), enforce (03), record evidence (05), and adapt (06) run per request — and adapt feeds back into evaluate, so the loop never fully closes.

Here’s what that looks like end to end — an analyst asking a mission copilot about aircraft readiness:

A reference interaction
One question, eight governed steps

To the analyst, the experience is one conversation. The authorization architecture is what keeps that simplicity from becoming invisible privilege.

Being useful here depends on being honest about what Immuta doesn’t do:

It integrates with, consumes context from, and provides evidence to most of these systems — but stating the boundary plainly is what makes the rest of the claim credible.

A practical rollout follows five phases, moving from ordinary human workflows toward full agentic governance rather than trying to do everything at once:

The strongest version of this conversation with a government stakeholder doesn’t open with a feature list. It opens with the architecture problem, then walks through four questions: which mission data and workflows matter most; which humans, applications, and agents need access; which policy and contextual inputs should govern the decision; and what evidence will actually demonstrate the required outcome is working. That framing keeps Immuta positioned as an architectural partner in a Department problem, not a vendor with a checklist.

The Synthesis: Conclusion – The Next Evolution of Zero Trust for Data

A platform’s contribution to Zero Trust for Data should be stated as precisely as the model itself demands: what it performs natively, what it depends on, and what it explicitly does not do. Bounded claims are what make an architecture assessable; inflated ones are what make it fail review.

AI doesn’t change what the Department has to protect. It changes who and what is asking, how fast, how many systems participate in answering, and how far the answer travels before it reaches a decision-maker — or triggers an action on its own.

For most of the enterprise-computing era, that journey was short and predictable: a person authenticated, an application connected to a known system, and role-based permissions did most of the work. That model doesn’t disappear — analysts will keep using SQL, dashboards, and notebooks — but it’s no longer the only path, or even the dominant one. A single prompt can now fan out into a dozen requests across as many systems, performed by software identities that didn’t exist five years ago.

None of that gets solved by uniformity. The Department’s data will stay distributed because its missions, organizations, and classification domains are distributed, and Zero Trust for Data has to work inside that reality rather than against it. What has to be uniform is the question asked of every single request, whoever or whatever is making it:

Should this identity, acting through this application or agent, receive this specific information, for this mission purpose, under these conditions, right now — and what may it do with the result?

Answering that consistently, continuously, and with evidence to show for it is the whole argument of this piece. It’s what lets an agent narrow rather than duplicate a human’s access. It’s what keeps a closed loop watching after the decision is made, not just at the door. And it’s the standard Immuta’s own role should be measured against — not by whether it can claim an entire pillar, but by whether it makes that one decision faster, more consistent, and more accountable at the point where mission data is actually used.

None of it requires waiting for every AI platform or agent standard to mature first. The work can start now, with priority workflows: identify the data, establish ownership, connect identity, define purpose, apply least privilege and least data, enforce on supported paths, produce evidence, and test it — denial, restriction, export prevention, revocation. Then extend the same model to the agents already showing up across the enterprise.

The Department’s success with AI won’t be measured by how many models it deploys. It will be measured by whether those systems can use mission information without creating authority nobody granted, data paths nobody can see, or actions nobody can trace back to a decision.

Zero Trust for Data is the consistent, continuous, and evidence-driven authorization of every mission-data interaction — from discovery and retrieval through transformation, output, sharing, and action — across humans, applications, and AI agents.