What OpenAI and Anthropic’s Agent Security Papers Mean for Enterprise Data Access

What OpenAI and Anthropic agree on about agent identity, least privilege, short-lived access, and auditability, and where Immuta fits.

As enterprises put AI agents in front of business systems, the central security question is changing. It is no longer enough to ask whether an agent has a valid credential or whether its prompt tells it to behave responsibly. The harder question is whether the agent can turn a mistaken instruction, manipulated document, or compromised tool into an unauthorized data access event.

Two recent security papers reach a similar conclusion from different starting points:

• Anthropic’s Zero Trust for AI Agents argues that traditional access controls cannot prevent agents from misusing legitimate permissions.
• OpenAI’s Agent security in the enterprise argues that a credential or tool connection does not authorize every action available through it.

Both papers point toward the same design principle: agent security requires enforceable boundaries outside the model itself. Those boundaries need to be tied to identity, task, scope, duration, and accountability. This article compares where OpenAI’s and Anthropic’s guidance converges, and what those principles mean at the data plane, where an agent’s planned action becomes an actual query against sensitive enterprise data.

Executive Summary

In an earlier Immuta article, Beyond the Prompt, we described the control plane and data plane as two distinct layers of an agentic architecture. The control plane interprets a request and plans a response. The data plane is where the agent’s query executes and where sensitive data is returned. That boundary is the focus of Immuta’s Agentic Data Access capability. Immuta extends its data provisioning model to agents, providing policy-driven, delegated, temporary access with a dual-identity audit trail.

The goal is not to suggest that Immuta replaces agent runtime security, tool security, or prompt-injection defenses. Those controls remain essential. The point is that the security principles described by both papers need a deterministic enforcement point at the data plane. Immuta provides that boundary by limiting what data an agent can access, even when the control plane makes a mistake.

Four themes stand out across both papers: 

1. Resource-side enforcement
2. Distinct agent identity
3. Task-scoped authority
4. End-to-end auditability

These are also the areas where Immuta’s Agentic Data Access model aligns most directly with the emerging consensus on secure agent deployment.

1. Enforce controls at the resource boundary

Both papers emphasize that security controls should be placed as close as possible to the potential impact.

How Immuta aligns

For data access, the receiving end is the data platform itself.

Immuta evaluates policy and provisions access into the underlying data environment, where table access, row filtering, column masking, and other controls can be enforced at query time. The agent does not receive unrestricted access simply because the orchestration layer decided that a dataset might be useful.

This distinction matters because the control plane is probabilistic. An agent can misunderstand a request, select the wrong table, or follow an instruction embedded in retrieved content. The data plane provides a separate enforcement point that can still restrict what the agent is allowed to see.

Immuta’s role is therefore specific and practical: make the final data-access decision at the point where data is accessed, not only at the point where the agent plans its work.

That approach complements the native capabilities of data platforms such as Snowflake and Databricks. Immuta adds centralized policy-driven provisioning and cross-platform governance on top of those execution environments. 

2. Treat the agent as distinct from the human

The second area of alignment is identity.

An agent may act for a person, but it should not simply become that person. Collapsing the two identities creates ambiguity around authority, privilege, and accountability.

How Immuta aligns

Immuta treats agents as first-class identities with their own attributes, groups, and policies. When an agent acts on behalf of a user, Immuta maintains both sides of the relationship:

• The identity of the human who initiated the request.
• The identity of the agent that performed the work.

The agent acts as itself, not as a borrowed human account. Immuta then evaluates the relevant policy context for both identities before vending temporary access to the data platform. This distinction also has a formal analogue in RFC 8693, OAuth 2.0 Token Exchange, which separates delegation from impersonation. Under delegation, the acting party retains its own identity while acting on behalf of another party. Under impersonation, the acting party is effectively indistinguishable from the party it represents.

Immuta’s model follows the delegation pattern at the data plane: the agent remains a distinct identity, while the user’s identity and entitlements inform the access decision. That lets Immuta govern what the agent may access without turning the agent into the user. 

This is materially different from two common patterns:

• A shared service account, where many users and agents appear identical in the audit logs.
• Full user impersonation, where the agent may inherit the user’s broad or administrative privileges.

With Immuta, the agent can receive the access required for the task without requiring every user to maintain a standing account in every data platform. The alignment is at the architectural level: distinct identities, explicit delegation, and authorization that does not collapse the agent into the user.

3. Replace standing access with task-scoped authority

Both papers identify persistent privileges as a major source of agentic risk. An agent that is always authorized to access a resource has a persistent blast radius, even when it is not actively performing a task.

How Immuta aligns

This is the most direct connection between the two papers and Immuta Agentic Data Access.

When an agent needs to perform work on behalf of a user, Immuta can evaluate the agent’s and user’s entitlements, then dynamically vend a short-lived, traceable role in the underlying data platform. The role is scoped to the request and carries a time-to-live. When the task ends or the TTL expires, the role is removed. 

This model changes the default:

• The agent does not carry a broad, permanent database role.
• The user does not need to be pre-provisioned across every data platform.
• The organization does not need to create a new static role for every possible agent and user combination.
• Access exists when the task requires it, then disappears.

That is the practical meaning of zero standing privilege for agentic data access.

It also addresses a limitation of ordinary user impersonation. If the user has more access than the agent needs, the agent should not automatically inherit all of it. Immuta’s policy model allows the agent’s access to be governed independently while still incorporating the user’s authorized data entitlements. 

4. Make the full access chain auditable

The final area of alignment is accountability.

Both papers argue that logging the agent alone is not enough. Security teams need to understand who initiated the work, which agent performed it, what authority was granted, what action occurred, and what effect followed.

How Immuta aligns

Immuta provides the data-access portion of this chain.

The audit trail can connect:

• The human who delegated the task.
• The agent that acted.
• The temporary role that was provisioned.
• The policy that applied.
• The data platform that was accessed.
• The data and queries involved.

This is especially important for compliance and incident response. A log that only shows AI_APP_PROD queried a customer table does not explain who initiated the request or whether the access was appropriate. A dual-identity audit trail provides substantially more useful evidence: which agent acted, on whose behalf, under which policy, and with what temporary authority. 

Immuta does not claim to provide the entire operational telemetry model described by the papers. Organizations still need complementary visibility into prompts, tool calls, agent runtimes, network activity, external communications, and downstream effects. Immuta makes the data-access portion of that chain explicit and provable.

The common architecture: layered controls, deterministic data access

OpenAI and Anthropic are not arguing that one product or one policy can secure an autonomous agent.

Their guidance describes a layered model:

Immuta’s focus is the fourth layer, while also contributing identity, delegated authorization, temporary credentials, and audit context to the surrounding chain.

That focus is important. Prompt instructions can guide an agent, but they cannot guarantee that the agent will interpret every instruction correctly. Runtime controls can contain execution, but they do not determine whether a user is authorized to see a particular table, row, or column. Identity systems can establish who the caller is, but they do not by themselves determine what data that caller should receive.

Immuta connects those decisions at the data plane. It turns identity, policy, and delegation context into governed access at the point of execution.

Conclusion: Zero Trust needs a data-plane decision

The OpenAI and Anthropic papers converge on a straightforward principle: an agent should not be trusted simply because it has a valid credential or because its instructions appear safe.

Agents need distinct identities. Authority should be scoped to the task. Credentials should be short-lived. Sensitive actions should be independently controlled. The resulting activity should be attributable and auditable.

Immuta applies those principles to enterprise data access.

Immuta Agentic Data Access enables agents to act on behalf of users without borrowing their identities, receive temporary policy-driven access without standing privileges, and leave an audit trail that connects the human, agent, policy, and data accessed. 

This does not eliminate the need for secure agent runtimes, tool controls, prompt-injection defenses, or incident response. It does something narrower and essential: it ensures that the final data-access decision is governed by policy at the data plane, where the organization can enforce what the agent is actually allowed to see.

The future of secure agentic access is not a choice between intelligent control-plane orchestration and deterministic data-plane enforcement. It requires both.