Permissioning Models for Read-Only Agent Access in OLAP Databases

Permissioning models for read-only agent access in OLAP databases need more than a ban on writes. A production-ready model combines per-agent credentials, engine-level row filtering and column masking, scoped schema visibility, isolated compute, and full query auditing. For managed OLAP services, the decisive test is whether those controls work together, so an autonomous agent’s access, resource use, and actions remain bounded and attributable.

Why a read-only grant is the wrong place to stop

Starting with a read-only role is a sound instinct. It blocks INSERT, UPDATE, and DELETE, so the agent cannot use those operations to change stored data. But the grant alone does not restrict which rows or columns a permitted query can retrieve, or how many rows it returns. Those are separate decisions about access. A valid SELECT can still return data the task never needed.

Three failures make that distinction concrete. Prompt injection can redirect an agent toward records its credential technically permits, leaving the database with a valid query under a valid identity. Policy inheritance can fail when rules written for a named human do not attach to a shared service credential. AC4A, by Sharma & Grossman, 2026, identifies the deeper authorization gap as agents having passwords but no permission slips. A model’s judgment or ad-hoc application logic decides whether a tool call proceeds, but neither is a security-grade authorization layer. Hooks and regex filters cannot reliably handle common table expressions, writable views, and the many ways to write a query that gets the same result.

How agents query differently from humans, and why it changes the threat model

What changes when the credential belongs to an agent? The next query comes from a model output, with no human checking each step before it runs. A person’s pause between wondering about a question and running a SELECT disappears. Agents also probe schemas, read rows, and follow references across many queries per session, where an analyst might run a handful. With per-query billing, each probe adds to the bill, so estimates based on average load say little about how much an investigation will cost in all.

A human analyst uses judgment, such as choosing not to pull a full user table to answer a billing question. An agent may retrieve it if the role permits it and the task suggests it could help. The same natural-language request can also generate different SQL each time, so a pre-approved query allowlist must anticipate a shifting query space. AC4A describes the underlying all-or-nothing pattern, in which access to an API or page grants more capability than a task needs.

Why enforcement must happen before the query reaches the engine

The architectural response is to put enforcement outside the agent’s discretion, before execution or within the engine before protected data is read. A response guardrail acts after data is retrieved, while a log alert may come after the agent has already used the result. Neither can substitute for deciding what the query may access before it runs.

Role-based and attribute-based access predicates can be inserted into SQL before execution, or enforced by the engine itself. Engine-level masking also applies no matter who wrote the query or which SQL form they chose. These controls do not require predictable model behavior. A separate MCP or REST server can refuse writes before they reach the database, adding another deterministic refusal point. At a minimum, the architecture therefore needs enforcement in both the engine and the server, with auditing that is independent of both. Tool annotations such as readOnlyHint can inform approval prompts, but a hint is not an enforced restriction.

Row-level security as the first mandatory layer above read-only

A row rule written for a human user does not automatically follow an agent using a shared service login, even when both appear to have the same nominal role. Engine-level row-level security, or RLS, closes that gap only when its predicates apply to the agent’s actual identity. Dynamic RLS uses the caller’s current attributes as well as static role membership, so filtering can follow tenant boundaries and the context of the task. Each agent should therefore have a dedicated credential.

A billing agent should receive SELECT access to the exact tables and views its task requires, with no read path to user login tables. RLS then filters within that permitted surface. Role-enforced limits on returned rows and short query timeouts also constrain a confused model’s attempt to retrieve a full table. Does this add planning overhead? Yes, but at OLAP scale that cost is manageable when predicates are applied during compilation.

Column masking as protection against over-broad table grants

Correct row filtering leaves a second question unanswered. Which fields within an allowed row does the agent need? An orders table may hold billing data needed for the task alongside customer emails and payment instruments. A billing agent can have the right row grant and still receive sensitive columns unrelated to its task. RLS cannot resolve that distinction because it governs only rows.

Engine-level masking rewrites matched fields before results reach the agent, so it receives the substituted value. That also limits what a prompt-injected query can surface from a permitted table. Filtered views that leave out sensitive columns are valid for simpler cases, but require upkeep when schemas change. Dynamic masking policies generalize better as columns evolve. The policies should be tied to agent identity, allowing the same table to serve an unmasked result to a human analyst and a masked result to an agent in a production context.

Scoped schema visibility and the governed dataset pattern

Agents commonly inspect metadata before they write SQL as part of normal discovery behavior. Yet unrestricted discovery gives them a map of tables and relationships beyond their task, inviting queries along paths that narrow grants were meant to exclude. Restricting access to information_schema or equivalent catalog views limits that map. Schema visibility is a separate boundary alongside row and column enforcement.

A governed dataset makes this boundary easier to express. It is a pattern built around a pre-calculated, pre-filtered representation of the data. The agent sees the schema its task requires rather than the database’s full physical organization. This gives the agent fewer chances to follow references into unrelated tables and makes it easier to predict how it will query. Governed datasets and restricted schema views need maintenance as the underlying schema evolves, but that work has a defined scope and owner. Once the agent has a curated data interface, exposing that interface through curated MCP tools becomes a natural next step.

MCP as a permission enforcement layer, not just a connectivity layer

Connecting an agent is not the same as authorizing it. MCP separates read-only Resources, callable Tools, and reusable, parameterized Prompts, but those categories alone do not enforce a database policy. A server becomes a permission boundary when it exposes task-scoped tool schemas and actually refuses forbidden operations. In that arrangement, it acts as a semantic firewall rather than a generic SQL transport. The dedicated database login remains the backstop regardless of which client or server an agent uses.

The MCP 2026-07-28 specification moved the protocol core to stateless operation, removing the mandatory initialize/initialized handshake. Each request now includes its own protocol version and capabilities. What happens to a grant assumed to last for a session? It no longer exists at the protocol layer, so the database or semantic layer must enforce authorization per request. Per-agent MCP or REST keys anchor attribution, while readOnlyHint and destructiveHint remain approval inputs. For a database without a native user model, such as SQLite opened through MCP, server-side refusal is especially important because there is no database user grant underneath it.

How isolated compute protects production queries from agent workloads

An agent issuing aggressive parallel queries on shared compute can exhaust connection pools, consume cache, and slow analysts’ queries or customer-facing dashboards. Read-only permission does nothing to prevent that contention. Giving agent workloads isolated, read-only compute over shared storage separates their processing from production query paths while preserving access to the same underlying data.

Agent compute becomes a separately attributable cost within the bill. Per-query charges and rigid minimums can penalize short, frequent, parallel queries, while compute-hour pricing with isolated agent compute makes an investigation’s cost more predictable and auditable. For experimentation, a snapshot or sandboxed branch can provide a separate place for what-if queries or schema tests. AC4A distinguishes read, write, and create permissions without prescribing which an agent should receive or requiring human approval for writes. Isolation complements those tiers by providing infrastructure boundaries within which the chosen permissions can operate.

Query auditing as the non-negotiable accountability layer

Preventive controls restrict activity, but they do not explain it. A useful audit record must identify the agent, the full SQL as executed, the tables and columns touched, the returned row count, the timestamp, and the upstream task or user request. Shared credentials erase attribution before logging even begins. A role name cannot identify which agent acted, which human initiated the request, or which task justified it. Because generated SQL varies, the natural-language prompt is not a reliable substitute for the query the engine received.

Full query records support reconstruction after a prompt injection incident by showing what the agent retrieved and in what order. They also support investigation into whether retrieved data left the system, rather than leaving the team without a retrieval record. Regular review can reveal repeated errors or access to sensitive tables more often than task requirements explain. AC4A also helps with review by letting active permissions be shown as natural-language statements that non-technical readers can understand. Logging is therefore a design requirement for the other layers. Accountability depends on attribution, and attribution breaks when agents share a credential.

Assembling the layers — what a production-ready permission model looks like end to end

At the database boundary, the stack begins with a dedicated credential per agent, SELECT-only grants on required tables and views, no EXECUTE or file privileges, and role-enforced row limits and timeouts. Engine-level RLS and masking then bind permitted results to that identity, while restricted schema visibility exposes only the governed dataset. The grant limits available operations and objects, while engine policies narrow the data returned from them. Neither depends on the agent deciding to behave cautiously.

Above that foundation, MCP or REST enforcement refuses writes, presents curated tools, and authenticates each request through a per-agent key. Isolated compute keeps the workload’s resource use separate from production, with branches available where experimentation requires them. Independent auditing connects executed SQL to the agent and upstream task. For a team evaluating managed OLAP services, those are concrete capability criteria rather than interchangeable claims of read-only support. Native support reduces the work of assembling and maintaining the boundaries by hand.

Microsoft Fabric’s April 6, 2026 change illustrates the least-privilege direction at the semantic layer. It cut the access creators and consumers need to use an agent to the semantic model’s minimum required Read permission, so they no longer need workspace access or Build permission. Beyond that semantic-layer example, a service that is ready for production must also make compute isolation, per-request enforcement, and query attribution work together. Buyers must assess whether an agent’s permitted data, resource use, and executed queries can each be governed without relying on its judgment.