Immuta’s temporary agent roles remove standing access—but policy union is the boundary to review

Immuta has moved its Agentic Data Access design into public preview for customers that request enablement, documenting a role-vending workflow for agents querying Snowflake and Databricks on behalf of people. The core mechanism is a short-lived warehouse role created for a specific human-agent session rather than a static service account with durable privileges. Immuta’s reference guide says the agent harness requests the role through a regional API, polls until it is ready, obtains short-lived platform credentials and can explicitly revoke the role before its time-to-live expires.

The important boundary is a union, not impersonation

The subtle part is how Immuta calculates that temporary role. It combines the human requester’s attributes and groups with access assigned to the agent. Immuta’s example gives an analyst access to revenue data while the agent has access to a dimension table; the temporary role can join both, even though the analyst could not query the dimension table directly. Row-level policy still restricts the result to the analyst’s department. In other words, the agent is not merely impersonating the user: it contributes capabilities of its own to the session.

That model can be useful. Shared lookup tables, semantic layers and other non-sensitive context do not have to be granted separately to every employee who uses an analytics agent. Immuta also says the resulting access is pre-calculated through role hierarchies or parent-child group relationships rather than issuing table grants at question time.

But the union is also the review point. Teams should treat an agent’s groups and attributes as production authorization configuration, not harmless metadata. Giving the agent access to a lookup, semantic object or table can make that resource available during every eligible user session. Row and masking policies may constrain what comes back, but they do not turn an overly broad agent entitlement into least privilege.

What operators need to verify

The harness—not the language model—holds the agent personal-access token and asks Immuta to vend the role for an authenticated username. Immuta explicitly says the service must validate that user. That makes identity binding in the application tier a critical control: a correctly constrained warehouse role is only as trustworthy as the username the harness supplies.

Session binding matters too. Immuta advises customers to work with support to ensure the vended role or group is pinned to the corresponding agent session, with platform-specific configuration. The reference guide also notes that duplicate usernames cause the API to reject a request, and warns administrators not to clear external username mappings for people who lack native warehouse accounts because those mappings are used to provision access.

For audit, Immuta exposes agent activity showing which role was vended for which user so it can be cross-referenced with warehouse query history. That is stronger evidence than an application log alone, provided teams retain both sides and test that the correlation survives retries and concurrent sessions.

The preview is a concrete alternative to permanent all-purpose agent credentials. Its safety case does not rest on the role being temporary by itself. It rests on four things being right together: authenticated user binding, narrowly defined agent entitlements, platform-specific session pinning and end-to-end audit correlation.