As enterprises rush to deploy autonomous AI agents, a quiet realization is setting in across engineering teams: AI problems are ultimately data governance problems. We’ve spoken to many of the most security conscious customers on the planet about their AI platforms, and when we look under the hood of most enterprise AI deployments today, we see an architectural tug-of-war. Teams are struggling to connect unpredictable, non-deterministic language models to highly secure, deterministic enterprise data platforms like Snowflake, Databricks, or Google BigQuery.
How we manage that connection dictates whether an AI initiative scales into a massive business accelerator or grinds to a halt under the weight of security risk. To understand how to build this correctly, we first have to get in the right headspace regarding how an agent interacts with your infrastructure.
The core concept: Control plane access vs. data plane access
When an AI agent interacts with an enterprise ecosystem, its actions are split across two entirely different architectural layers: the Control Plane and the Data Plane.
- The Control Plane (Orchestration): This is where the agent thinks, plans, and maps out user intent. It leverages semantic layers, model registries, and AI context fabrics to understand what the user wants. For example, if you integrate a semantic management engine like Natoma or AWS AgentCore, it operates squarely in the Control Plane, governing how the agent interprets a question, translates natural language into standard database definitions, and structures its operational plan.
- The Data Plane (Execution): This is where the physical execution happens. When an agent converts an abstract plan into a physical query (like Text-to-SQL) and hits your data platform to retrieve records, it has stepped directly into the Data Plane.
The security and operational breaking point for most companies occurs right at the boundary where the Control Plane hands off instructions to the Data Plane. Depending on how organizations architect that handoff, they fall into one of three distinct access patterns.
Entering the AI Threat Landscape: Anthropic's Zero Trust Framework
To objectively evaluate these access patterns, we have to look through the lens of modern, machine-speed vulnerability windows. Anthropic recently published a foundational blueprint titled Zero Trust for AI Agents: A security framework for deploying autonomous AI agents in the enterprise.
The paper delivers a stark warning to the industry: perimeter defenses are dead because frontier AI models compress the timeline between vulnerability discovery and active exploit from months down to hours. Because autonomous agents have the unique capacity to independently interpret goals, select tools, and chain operations together, standard access controls are no longer enough.
Anthropic explicitly challenges every enterprise architecture with a single question: Does a security control make an attack impossible, or just tedious? Agentic attackers possess infinite patience and near-zero per-attempt financial cost; controls that rely on mere friction (like complex prompt instructions or application rate-limiting) will inevitably degrade and fail. True security demands hard barriers at the infrastructure and data layers—completely removing an agent’s technical capability to do harm rather than simply throttling it.
With this framework as our baseline, let’s analyze the three data access archetypes dominating corporate deployments today.
Mapping the 3 data access archetypes
Archetype A: The Shared Service Account (or Multi-Account Pool)
How It Works
The AI application connects to the underlying data platform using a static corporate service credential (e.g., AI_APP_PROD). In slightly more mature variations, organizations deploy a pool of several distinct service accounts divided by department or function (e.g., AI_FINANCE_READ, AI_HR_DEFAULT). The application’s Control Plane evaluates the user’s prompt and programmatically selects which service account from the pool is “most appropriate” to pass down to the database.
| Architectural Element | Current State Configuration |
|---|---|
| Identity at Database | Static App-Specific Service Account Pool |
| Privilege Model | Group-Scoped / Over-privileged (Broad Shared Access) |
| Token Lifecycle | Long-Lived / Persistent Credentials |
| Policy Enforcement | Basic Application-Level Control Plane Routing |
Business & Operational Impact
- The Pro: Relatively fast to deploy and offers a rudimentary form of data separation across different departments without requiring a deep overhaul of database-level IAM infrastructure.
- The Con (Role Explosion): As security mandates tighten, organizations inevitably try to fix this archetype by creating separate service accounts for every combination of department, role, and geographic region. This immediately triggers a catastrophic role explosion. Data engineering teams become entirely consumed by provisioning, managing, and maintaining thousands of static database configurations. It quickly becomes impossible to keep up with the infinite permutations of human data access, crippling the business’s agility.
- The Audit Blindspot: Your database-level audit logs are an unreadable black box. Every single record accessed reads exactly the same: a generic account like AI_FINANCE_READ pulled data. You have zero capability to verify which human user initiated the request or what the true downstream intent was. If a compliance breach occurs, parsing out who did what is functionally impossible.
Anthropic Zero Trust Alignment
❌ Severe Violation. Even with multiple service accounts, this model falls directly into what the Anthropic paper calls the Attribution Gap. Relying on the application’s control plane to choose the “right” account is a friction-based boundary, not a hard barrier. If an agent is manipulated via indirect prompt injection, an attacker can trick the control plane into selecting a higher-privilege account from the pool. Because the database platform cannot verify the originating user’s identity or intent, it blindly executes the query, granting an unmitigated blast radius to the exploit.
Archetype B: Human User Impersonation
How It Works
The agent attempts to directly mimic the human worker. When a user logs in, the agent captures their specific identity credentials or standing OAuth token and passes it down to the database, running queries as that human.
| Architectural Element | Current State Configuration |
|---|---|
| Identity at Database | Human End-User Identity Only |
| Privilege Model | Human-Scoped (Inherited Administrative Clearance) |
| Token Lifecycle | Standing / Persistent Human OAuth Token |
| Policy Enforcement | Standard Human Role-Based Access Control (RBAC) |
Business & Operational Impact
- The Pro: It respects standard user access. An employee won’t see data via the AI that they couldn’t see via a standard dashboard.
- The Con: It restricts the agent from doing its job effectively and complicates operational tracking. If an agent needs to pull broad operational baselines or aggregate multi-department metrics to answer a complex business query, it is artificially bound by the narrow row-level data access of whichever individual employee hit “Enter.”
- The Audit Blindspot: While you can see which user account ran the query, your security logs suffer from a dangerous lack of context. The database cannot distinguish between an employee pulling data manually via an allowlisted application vs. an autonomous agent acting autonomously on their behalf. If an agent behaves anomalously or is hijacked, it looks identical to standard user behavior in the core telemetry streams.
Anthropic Zero Trust Alignment
⚠️ High Risk (The Confused Deputy). This archetype directly violates Anthropic’s core requirement for Least Agency—the principle that you must strictly constrain what an agent tool can do, how often, and where, independently of human permissions. If a human user has broad clearance, an impersonating agent inherits that full data power. This opens the door to a severe “Confused Deputy” vulnerability: an attacker can trick a low-privilege system (like an email-reading or web-scraping agent) into passing malicious instructions to a high-privilege agent. The high-privilege agent then blindly uses the human’s valid, inherited data access to execute a malicious data exfiltration.
Furthermore, from a pure cyber perspective, it requires that all human employees have an account and standing privileges in all your systems, just in case they might ask AI a question – creating a huge security vulnerability footprint.
Archetype C: Intent-Based / Dual Identity with Zero Standing Privileges (ZSP)
How It Works
This is the modern target state. Data access paths do not exist by default. The system introduces a separate, first-class identity for the AI system itself. When a query is initiated, the policy engine performs a Just-In-Time (JIT) identity union: it blends the distinct identity of the agent with the attribute context of the requesting human user. A temporary, task-bound database role is dynamically vended to support the request, and it automatically vanishes the moment the execution concludes. Moving forward, architectures can introduce an additional layer of functional intent over this configuration, refining the union into a tightly bounded identity intersection.
| Architectural Element | Optimized State Configuration |
|---|---|
| Identity at Database | Combined Agent + User Identity Context |
| Privilege Model | Identity Union (User Attributes + Agent Identity Engine) |
| Token Lifecycle | Ephemeral / Task-Bound (Zero Standing Privileges) |
| Policy Enforcement | Dynamic Just-In-Time (JIT) Union of ABAC policies |
Business & Operational Impact
- The Pro: The ultimate state for enterprise scale, cost control, and security. Business units can deploy highly capable agents knowing that data access is dynamically governed based on the combined profile of the system and the user.
- The Audit Superpower: This model entirely solves the logging flaws of Archetypes A and B. Because it passes down a combined identity context, your data security logs provide flawless, granular dual-identity auditing. For every single query executed, compliance officers can explicitly verify: “This specific AI agent ran this precise Text-to-SQL query acting on behalf of this exact human user, validated by an ephemeral session token.”
- The Con: It requires an automated data security platform that can dynamically evaluate complex cross-identity logic and handle ephemeral token rotation at machine speed.
Anthropic Zero Trust Alignment
🏆 Perfect Alignment (The Advanced Standard). This archetype fully satisfies the framework’s baseline for advanced security. Registering the agent as a standalone, cryptographically verifiable identity completely eliminates the attribution gap. Furthermore, utilizing task-scoped, ephemeral tokens passes the “Impossible vs. Tedious” test. If an agent suffers from memory poisoning, there are no standing tokens or cached database privileges on the host environment for an attacker to harvest—the physical data access path simply ceases to exist.
The Ultimate Blueprint: Merging Control Plane and Data Plane in Archetype C
When we evaluate these models against the reality of building enterprise software, Archetype C emerges as the definitive operational sweet spot because it represents the seamless marriage of the Control Plane and the Data Plane.
By combining these two layers, you unlock the best of both worlds:
- Context-Aware Intent (Control Plane): A tool like Natoma or AWS AgentCore can manage the semantic layer, translating natural language business queries into precise schema logic, ensuring the agent understands exactly what definitions to use.
- Deterministic Enforcement with Zero Standing Privileges (Data Plane): A governance layer simultaneously intercepts the request at the database level, dynamically checking the union of the user’s and agent’s attributes, and vending a temporary, short-lived role to physically restrict row and column visibility.
When you combine a semantic engine with a data-plane access gateway, you get an extraordinarily elegant workflow. The agent uses Natoma to understand the relationships between financial tables (Control Plane). But when it goes to execute its Text-to-SQL query to pull the records, the data governance layer dynamically steps in, strips out PII, applies row filters based on the active human user, and authorizes the transaction via an ephemeral, task-bound token (Data Plane).
This approach transforms your security posture. You no longer have to build fragile prompt filters or write exhaustive application-level validation checks. Security shifts from a probabilistic guess inside an LLM prompt to a deterministic mathematical constraint inside your data platform.
Conclusion: Designing for breach
Anthropic’s Zero Trust guide leaves us with a stark, accurate conclusion:
“The organizations best positioned for this shift will not necessarily be the ones with the most advanced AI. They will be the ones whose fundamentals are strong enough that AI-assisted scanning finds fewer bugs in the first place, and whose agent deployments were architected for breach from day one.”
If your AI architecture treats data access as an afterthought—relying on a single massive service account or blindly impersonating users without tool-centric boundaries—you are exposing your enterprise data estate to severe risk.
This architectural reality is precisely why Immuta is fundamentally focused on driving Archetype C architectures. We believe that for AI agents to achieve true operational utility, they must be treated as top-level identities bound by zero standing privileges, session-scoped context, and strict dual-identity auditing. By decoupling authorization from the prompt layer and enforcing it natively at the data plane, we turn the dangerous vulnerability of agentic manipulation into a secure, predictable, and compliant enterprise asset.