A “read-only data agent” needs four controls—not one checkbox

Recent enterprise releases are converging on a useful correction to the phrase “read-only agent”: read-only is not a single property. It is the result of several independent controls that can disagree.

Four first-party sources published or updated this month make the pattern visible. Microsoft separates its Fabric SQL guidance into authoring, consumption and operations skills; Snowflake separately controls tools, hooks and cancellation; Immuta creates a session role from both user and agent entitlements; Oracle separates live database execution from durable memory. Taken together, they suggest a four-part review model.

1. Name the operating mode

Microsoft’s preview SQL database skills distinguish authoring, read-only consumption and operations. That is a useful intent boundary, but Microsoft also says skills are static guidance: the attached identity and tools still determine what can actually happen. A consumption prompt is therefore not a permission system.

The operational question is concrete: is this session allowed to query, diagnose or change? Give each mode its own tool set and credentials rather than relying on wording alone.

2. Verify the execution identity

Immuta’s Agentic Data Access reference shows why identity needs its own review. Its temporary role combines the human requester’s entitlements with access assigned to the agent. The result is not simple impersonation: agent-side access can expand what the joint session can query.

That design avoids a permanent all-powerful service account, but “temporary” does not automatically mean “least privilege.” Operators must inspect the user binding, the agent’s groups and attributes, session pinning and the warehouse audit trail.

3. Test enforcement failure and interruption

Snowflake’s Cortex Code Desktop v1.21.7 notes address a different layer. A denied PreToolUse hook now blocks execution; hook failures no longer become permission; subagents receive explicit skill scopes; and stopping a multi-statement SQL run terminates the whole run.

Those fixes expose two tests that “read-only” labels miss. First, does the policy fail closed when its enforcement component errors? Second, does stop mean no later statement continues? An agent can have narrow database permissions and still behave unsafely if its local control path fails open or cancellation is partial.

4. Govern what survives the session

Oracle’s SQLcl MCP documentation ties live tool actions to saved database connections and their privileges. Its separate Agent Memory API governs stored users, agents, threads, memories, retrieval and retention.

That separation matters because read-only execution says nothing about what context is retained afterward. A session that cannot modify a table may still persist sensitive schema or business context unless memory scope, expiry and deletion are reviewed independently.

The practical gate

Before approving an enterprise data agent, ask four questions: Which operating mode is active? Which identity reaches the database? What happens when enforcement or cancellation fails? What survives after the session?

No one vendor supplies this full model. The value is in the convergence: skills express intent, roles define authority, hooks and cancellation govern runtime behavior, and memory controls govern persistence. Calling an agent read-only before all four align is an incomplete safety claim.