From Principles to Enforcement: How Immuta Delivers the Data Controls ARMCF Requires
For decades, the answer to “how do we manage identity at scale” was the same: lift it above your platforms. Don’t let every application manage its own user store. Centralize authentication in an identity provider, and let your platforms trust it. Okta, Azure AD, and others built entire categories on that insight.
Authorization is facing the same reckoning.
As agents proliferate across enterprise data platforms, the old model – where each platform manages its own roles, permissions, and access policies — is breaking down. Machine-speed access requests, dynamic user contexts, and non-human identities don’t fit neatly into any human-centric role hierarchy. The question organizations are now asking isn’t just “who can access this data?” It’s “how do we govern access when the requester is an agent, the context changes per query, and the volume is orders of magnitude beyond what any static role model was designed for?”
The Software Analyst Cyber Research team named this problem directly in their new AI and Agentic Risk Management and Control Framework (ARMCF). We think the answer follows the same logic as identity did: authorization needs to live above your platforms, not inside them.
The core claim ARMCF makes
ARMCF applies the familiar six-function lifecycle of NIST CSF 2.0 — Govern, Identify, Protect, Detect, Respond, Recover — to the specific risks created by AI systems with autonomous action-taking capability. It’s a practitioner-oriented framework designed to close the gap between high-level AI governance principles and the technical enforcement that security teams can actually operationalize.
Its central argument is one we’ve been repeating to customers for over a year: an AI agent that can query data, call APIs, or trigger downstream actions must be governed like a privileged digital actor, not like a static software component.
The framework calls out the risk areas that expand an agent’s blast radius well beyond that of a traditional application: tool invocation, context access, delegated permissions, MCP-style brokered tool access, and identity delegation. It argues that existing cybersecurity frameworks don’t fully resolve these risks without AI-specific interpretation. It also argues that AI governance frameworks often describe sound principles without providing the technical enforcement that security teams can operationalize.
That last point is the translation problem ARMCF was built to solve. And the reason that translation gap exists is structural.
Traditional platforms were built to authenticate at login and enforce access through pre-assigned roles. That model worked when users were human, requests were infrequent, and identity context was stable. AI breaks all three assumptions simultaneously. Agents don’t log in. They act continuously. Their access context changes with every user prompt. No platform-native role system was designed for that, and no amount of static configuration inside your platforms will fix it. The enforcement model has to move up the stack — external to the platforms — the same way authentication did.
Where the translation problem surfaces in data access
The most immediate place organizations feel that translation gap is at the data layer. When AI agents need to access sensitive data in platforms like Snowflake or Databricks, organizations are typically forced into one of two choices, and neither is good.
Option 1: Over-privileged service accounts. Give the agent broad, persistent access so it can serve any user at any time. Fast to deploy. Terrible for security. One compromised agent, one prompt injection attack, and the blast radius is your entire data warehouse.
Option 2: OAuth Account sprawl. Provision individual database credentials for every potential user so the agent can authenticate as them via OAuth, across every platform the agent might touch, just in case they ask a question. This quickly becomes unmanageable, and the standing privileges it creates are exactly the kind of persistent attack surface that ARMCF flags as a core risk.
ARMCF’s Protect domain calls for zero standing privileges, least-privilege access, and ephemeral credentials. Its Govern domain calls for defined accountability and constrained autonomy. Its Identify domain calls for understanding data flows and blast radius. These aren’t abstract principles. They’re a direct critique of both options above.
How Immuta maps to ARMCF’s control objectives
Immuta approaches this as an authorization layer problem, not an authentication layer problem. The technical mechanism is what we call agentic data access: a role-vending model that treats agents as first-class identities and enforces policy at the moment of access, not before it.
Here’s how that maps to the specific control objectives ARMCF defines:
Agent Identity as a First-Class Construct (ARMCF’s Govern / Identify)
ARMCF argues that agents require distinct identity governance, separate from the humans they serve and separate from the systems they call. In Immuta, agents are registered as independent entities with their own groups, entitlements, and policy surfaces. They are not shadow users, inherited credentials, or generic service accounts. That distinction is foundational to everything else.
Zero Standing Privileges (ARMCF’s Protect)
Business users who always ask questions through agents need no account in the system, no standing privileges. When a user prompts an agent to query data, Immuta fetches what that user is authorized to see — based on their attributes, group memberships, and the policies authored in Immuta. It then generates an ephemeral, task-bound database role that represents a union of the agent’s own access and the user’s entitlements. Immuta vends that role to the agent at query time and deletes it the moment the task completes.
No persistent credentials. No standing privileges. If a session is hijacked or a prompt is injected, there is no durable access to exploit.
Data Minimization at the Policy Layer (ARMCF’s Protect)
ARMCF’s PT-4 control asks whether agents receive only task-required data, with sensitive fields protected from prompts, memory, and logs. Immuta enforces this at the policy layer automatically. When an ephemeral role is vended, it carries not just access permissions but the full set of data controls authored in Immuta — column masking, row-level filters, and PII protections. An agent querying on behalf of a user who shouldn’t see a sensitive column won’t see it, regardless of how the query is constructed. The enforcement happens at the data platform level, not at the application level, which means it can’t be bypassed by a clever prompt. And because these controls are enforced at the data platform layer, sensitive fields are masked before results are returned to the agent — they never appear in the response payload, and they never need to be scrubbed from logs after the fact.
Rights Inflation Prevention (ARMCF’s Protect / Govern)
ARMCF specifically calls out the risk of delegated permissions (OAuth) granting more access than intended. The policy union model prevents this in both directions.. If a user has admin-level permissions in a data platform, the agent does not inherit that clearance. The agent’s access is bounded by what Immuta policies explicitly permit, not by what the underlying platform would grant the human user directly. Policy is the gatekeeper. Not access.
Blast-Radius Containment (ARMCF’s Identify)
ARMCF’s ID-4 control asks organizations to assess the maximum damage available through each agent’s data access paths. Immuta’s architecture provides a structural answer to that question. Because authorization is externalized and enforced through ephemeral roles, the blast radius of a compromised agent is bounded by policy — not by what the agent’s long-lived credentials might otherwise permit. An attacker who gains control of an agent mid-session can only access what the task-bound role allows at that moment. The moment the task concludes, that role is deleted. There is no persistent foothold to exploit.
Clear Audit Trails (ARMCF’s Detect / Respond)
ARMCF places heavy emphasis on evidence preservation and traceable ownership. Every vended role in Immuta follows a strict naming convention that encodes the agent ID, the user ID, and a unique identifier: IMMUTA_VENDED_
This architecture also directly addresses ARMCF’s AI-R-005 risk scenario: an attacker compromises agent identity and misuses delegated permissions. In a traditional service account model, a compromised agent identity means persistent, broad access until someone notices and revokes it. With Immuta’s role-vending model, a compromised identity yields only what the ephemeral role permitted at the moment of compromise — scoped to one user’s entitlements, for one task, already expired. The audit trail then makes the incident reconstructable: which agent, which user, which data, and exactly when.
Autonomous vs. Delegated Agent Governance (ARMCF’s Govern)
ARMCF distinguishes between different levels of agent autonomy, from human-in-the-loop workflows to fully unsupervised execution. Immuta applies the same distinction. Agents acting on behalf of a user — chatbots, AI analysts, text-to-SQL tools — receive ephemeral, just-in-time access under the on-behalf-of model. Agents acting autonomously — scheduled bots, ETL pipelines, model training jobs — receive persistent, directly-assigned access governed by their own Immuta policy. The same platform, the right model for each use case.
What ARMCF covers that extends beyond data access
ARMCF’s scope is intentionally broader than the data layer. It also covers prompt injection, model supply chain risks, MCP server governance, tool orchestration security, and SecOps integration for detection and incident response. Immuta addresses the data access governance slice of that picture, and does so in depth, but organizations looking to fully implement ARMCF will need complementary capabilities covering the model layer, the tool invocation layer, and detection engineering.
The framework is useful precisely because it maps all of these domains together. Security and risk leaders can use ARMCF to identify which control objectives they have addressed and which they haven’t, and build toward a coherent operating model rather than a patchwork of disconnected tools.
Authorization needs to move above the platform
There’s a useful historical parallel here. For years, enterprises managed authentication inside each application. Every system had its own user store, its own login logic, its own session management. It worked until it didn’t — until multi-tenant SaaS, microservices, and workforce scale made per-platform authentication untenable. The industry responded by externalizing authentication into identity providers. Okta, Azure AD, and Ping became the trust layer that platforms deferred to, rather than replicated.
AI agents are forcing that same shift – this time on authorization.
When an agent can dynamically act on behalf of different users, traverse multiple data platforms in a single session, and do all of it at machine speed, per-platform role management collapses under its own complexity. The only scalable answer is to externalize authorization the same way we externalized authentication: a single policy layer that sits above your data platforms, understands both human and agent identity, and enforces access dynamically at the moment it’s needed.
That’s what Immuta is built to be: the authorization layer for AI. Not a layer inside Snowflake or Databricks, or whatever SaaS database or app, but a layer above them — one that those platforms trust the same way an application trusts an identity provider.
ARMCF names the control objectives. Immuta delivers the enforcement model. And the enforcement model — externalized, policy-driven, ephemeral, and auditable — is the same architectural move the industry made on identity a decade ago. We just think it’s time to make it on authorization too.
Want to see how Immuta governs agentic data access in practice? Reach out to schedule a demo.
