Agentic
Data Access
AI agents are now your primary data consumers. And they need data in milliseconds. Immuta provisions it to them quickly and safely.
AI agents are now the primary data consumers of enterprise data.
To keep up, many organizations let agents borrow human accounts to log in to data sources.
Account sprawl
Accounts with standing privileges exist everywhere, just in case.
Over-exposed data
Agents see all the human’s data, not only what the task needs.
Inflated permissions
Accounts collect standing grants so agents don’t get blocked.
Unclear audit trail
No clean way to tell who actually accessed the data.
Immuta treats AI agents as first-class data consumers.
Immuta gives agents have their own governable identities. They can request data at question time, and get just-in-time, ephemeral access to the data they’re authorized to use — with every action fully auditable.
Agents act on behalf of humans, but they have their own governable identities.
Agent Identity
No more borrowing human accounts. In Immuta, AI agents are registered users in the data ecosystem.
Inherited Access Rights
When an agent acts on behalf of a human, it operates under that human’s Immuta-defined access rights. They can see only what that human is allowed to see. These rules are enforced at the data tier, so no prompt can bypass them.
Fully Auditable
Everything the agent does (on behalf of whom, and why) is fully tracked and auditable.
No need to grant access in advance. Agents can request data access as needed for the task.
Permission-Aware Querying
At question time, the agent validates access permissions in the semantic layer, before even touching the data source. So no broken queries trying to access off-limits data.
Data Requests and Approvals
When an agent sees that an answer is possible but the human lacks the rights to the data, it proactively submits an access request via Immuta. Immuta deterministically evaluates all requests against policies, automatically approving safe ones, and routing sensitive ones to the right human approvers for review.
Continuous Policy Learning
As Immuta learns from each decision, your policy library gets smarter and more fine-tuned, allowing Immuta to automate even more provisioning for you.
Data access is granted for only as long as needed to answer the question, and no longer.
Just-in-Time Grant
Immuta evaluates the intersection of the human’s authority, the agent’s permitted capabilities and the task’s purpose, then creates a short-lived role natively in your data platform.
No Standing Privileges
Once access is approved, Immuta grants the data for only as long as needed to answer the question — no longer. Access is removed as soon as the agent’s task is complete. So you have no prolonged exposure risk.
Frequently Asked Questions
How does this differ from traditional OAuth 2.0?
Standard OAuth often requires the user to have an active session or account on the destination resource. With Immuta, we decouple authorization from access. The user is authorized to see the data, but they are not required to have direct access to the database. Immuta bridges this gap by creating an ephemeral database role on the fly, allowing the agent to act as a secure, authenticated broker.
Why not just create a database role for every agent task?
Mapping intents directly to session tokens or static roles creates a “user blind spot.” The intent-based role often ignores the specific user’s attributes. For example, if an agent has a “summarize data” intent, it might access the data the same way regardless of whether a CEO or an intern is asking.
What is “role/scope explosion,” and how does Immuta avoid it?
Role/scope explosion occurs when you try to create a unique database role or Oauth scope for every possible permutation of a user’s job and an agent’s task. If you have 100 users and 10 agent “intents,” you could end up managing 1,000 distinct roles/scopes. Immuta uses ABAC (Attribute-Based Access Control) to solve this. Instead of building a new role or scope for every scenario, Immuta uses a single policy that says, “Allow access if User.Region = Data.Region.” It doesn’t matter if there are 5 intents or 5,000; the policy remains the same, and the role is vended dynamically.
Is Immuta’s model harder to set up than mapping roles?
Actually, it’s much simpler to maintain at scale. With role-mapping access, you face a “linear maintenance” problem: every new permutation of access your agent gains requires a new set of roles and mappings. With Immuta’s ABAC, you set your global data policies once. Whether you add 1 agent or 100, they all automatically follow the same enterprise guardrails without a single additional database role being manually created.
How does Immuta support intent-based authorization?
While others use “Intent” as a replacement for robust access control, Immuta is building a concept of intent intersection. Soon, you will be able to define a specific intent for a task, and Immuta will automatically calculate the intersection of that intent and the user’s actual ABAC permissions. This provides a double-lock system: the agent is limited by what it is trying to do and what the user is allowed to see.
How do you prevent “prompt injection” from gaining unauthorized data access?
Because Immuta’s authorization is deterministic, not probabilistic, it doesn’t matter what the prompt “tells” the LLM to do. The agent is bound by a vended database role that is physically restricted at the data platform level (e.g., Snowflake or Databricks). Even if a malicious prompt “convinces” an agent to try and drop a table, the underlying database role simply won’t have the permission to execute that command.
Is there an audit trail for what the agent did versus the user?
Yes. One of the biggest risks in agentic workflows is the loss of attribution. Immuta maintains a dual-identity audit log. Every query executed by an agent is tagged with both the agent ID and the end-user ID. This provides complete visibility into who authorized the action and which autonomous system carried it out, meeting the strictest compliance requirements for financial and regulated industries.
How does the agent know what it is allowed to query?
Immuta allows you to set delegated access policies that act as a “governance filter.” By decoupling these permissions from the underlying physical database, the agent is restricted to a specific, safe sandbox. This allows developers to scope exactly which tables or views an agent can interact with on behalf of a user, preventing the agent from accidentally accessing sensitive data it doesn’t need for its core function.
Is there a “kill switch” for agentic access?
Yes. Because Immuta vends short-lived, ephemeral roles, security teams have centralized control. Since the agent’s access is tied to a specific vended session rather than a permanent API key, you can revoke access or update policies in Immuta, and have that reflected immediately across all active agentic workflows without needing to rotate credentials in the database.
