Agentic
Data Access

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.

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.

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.

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.

Yes. 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.

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.

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.

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.

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.