Governance and Security

Casabase Cube’s Snowflake Intelligence integration is designed to preserve the same governed analytical model used by other supported Casabase Cube query paths.

Adding a conversational interface does not create a separate security boundary around cube data.

At a high level:

User
 │
 ▼
Snowflake Identity
 │
 ▼
Snowflake Role and Agent Access
 │
 ▼
Native App / Tool Access
 │
 ▼
Casabase Cube Application Role
 │
 ▼
Casabase Cube Row-Level Security
 │
 ▼
Governed Result

Each layer controls a different part of the request.

Security Principles

The integration follows several core principles:

• Snowflake remains responsible for platform identity, authentication, roles, and privileges.
• Casabase Cube application roles control access to Casabase Cube capabilities.
• Casabase Cube row-level security continues to govern cube data through supported query paths.
• App-created Cortex Agents run under Snowflake’s restricted caller security model.
• Access to customer-owned Snowflake objects must be explicitly authorized where required.
• Agent tools should be limited to the capabilities required for their intended purpose.
• Prompt instructions are not a substitute for access controls.
• The agent should not bypass the Casabase Cube query engine to recreate governed cube results independently.

Snowflake Identity Remains the User Identity

Users access the Casabase Cube agent using their Snowflake identity.

The agent does not introduce a separate Casabase Cube username or password.

Conceptually:

Snowflake User
      │
      ▼
Snowflake Role
      │
      ▼
Cortex Agent
      │
      ▼
Casabase Cube

Snowflake controls authentication mechanisms such as passwords, federated identity, MFA, and other account-level identity policies.

Casabase Cube operates within that Snowflake identity model.

Cortex Agent Access

Users require Snowflake authorization to invoke Cortex Agents.

Snowflake provides database roles including:

SNOWFLAKE.CORTEX_AGENT_USER

for Cortex Agent access and:

SNOWFLAKE.CORTEX_USER

for a broader set of Cortex capabilities.

Use the narrower role where appropriate for your organization’s least-privilege model.

Cortex Agent permissions are evaluated using the user’s default Snowflake role. A role selected only for the current session does not replace the default role for this purpose.

Users also require a default warehouse, and the applicable role must be able to use it.

See Setting Up the Agent.

Casabase Cube Application Roles

Snowflake agent access does not by itself grant Casabase Cube access.

Casabase Cube uses application roles:

Application Role	Purpose
CUBE_PUBLIC	Query and discovery access
CUBE_ADMIN	Administrative access; inherits CUBE_PUBLIC

A user who requires only analytical access should normally receive CUBE_PUBLIC.

Administrative capabilities should remain restricted to users who require CUBE_ADMIN.

Conceptually:

Can Use Cortex Agent
        │
        X
Does Not Automatically Mean
        │
        ▼
Can Administer Casabase Cube

See Roles and Privileges.

Row-Level Security Still Applies

Casabase Cube row-level security continues to apply when the agent executes a supported Casabase Cube query.

For example, suppose the Entity hierarchy contains:

Total Company
├── North America
│   ├── United States
│   └── Canada
└── Europe
    ├── Germany
    └── France

If a user’s active Casabase Cube security rules permit only:

North America

then a request such as:

Show revenue for all entities.

is evaluated within that permitted scope.

Conceptually:

Agent Request
      │
      ▼
User Security Context
      │
      ▼
Permitted Entity Scope
      │
      ▼
Aggregation / Calculation
      │
      ▼
Result

The agent is not a bypass around row-level security.

Security Is Applied Before Analytical Evaluation

Security filtering is part of the query path before the final multidimensional result is produced.

This matters because calculated values can depend on the data visible to the user.

For example:

User A
Allowed: North America

User B
Allowed: Europe

Both users can ask:

What is total revenue?

and receive different valid results because each result is calculated from the user’s permitted data.

This behavior is consistent with Casabase Cube’s other supported query paths.

Casabase Cube Security Is Opt-In Per User

Casabase Cube row-level security remains opt-in per user.

Filtering is applied when:

1. Security is enabled on at least one dimension of the cube.
2. The user has at least one active security rule for that cube.

A user with application access but no active security rules for the cube is unrestricted by Casabase Cube row-level security.

This behavior does not change because the query originates from the agent.

See Access Control.

App-Created Agent Security

A Cortex Agent created by a Snowflake Native App runs under Snowflake’s restricted caller’s rights security model.

This prevents an app-created agent from automatically gaining access to arbitrary customer-owned objects.

For a tool invocation that accesses a consumer-owned object, effective access requires the applicable user privilege and the caller access explicitly approved for the application.

Conceptually:

User Has Privilege
        +
Application Has Approved Caller Access
        │
        ▼
Tool Can Access Consumer Object

If either side is missing, access is not granted.

This creates a consumer-controlled boundary around customer-owned Snowflake objects.

App-Owned Objects

Objects owned by the Native App are handled differently from customer-owned objects.

The application can use its own approved internal objects and explicitly exposed capabilities without requiring the customer to grant caller access to each app-owned object.

This allows Casabase Cube to expose controlled application functionality while keeping internal implementation details within the Native App boundary.

The user receives access to the capabilities exposed through application roles and agent tools, not unrestricted access to the application’s internal objects.

Customer-Owned Objects

When an agent capability requires access to a customer-owned Snowflake object, additional authorization can be required.

Examples can include:

• Warehouses
• Databases
• Schemas
• Tables
• Views
• Semantic views
• Other supported Snowflake objects

The Snowflake administrator should grant only the caller access required for the intended capability.

For example, an agent should not receive broad access to an entire database merely because one approved tool needs one specific class of object.

Restricted Caller Rights

Restricted caller’s rights are designed so that an app-owned executable cannot simply inherit every privilege available to the caller.

The consumer controls which caller privileges the application is permitted to use.

Conceptually:

Privileges Available to User
            │
            ▼
Consumer-Approved Caller Boundary
            │
            ▼
Effective Privileges Available to App

This provides an additional restriction beyond normal user access.

App-created Cortex Agents run with restricted caller’s rights. Snowflake does not support owner-rights Cortex Agents, although individual app tools can have their own documented execution context.

Least Privilege

Use least privilege at every layer.

For general analytical users:

Snowflake Role
     │
     ├── Required Cortex Agent Access
     ├── Required Warehouse Access
     ├── Access to Casabase Cube Agent
     └── CUBE_PUBLIC

For administrators:

Administrative Snowflake Role
     │
     ├── Required Cortex Agent Access
     ├── Required Warehouse Access
     ├── Access to Casabase Cube Agent
     └── CUBE_ADMIN

Do not grant CUBE_ADMIN simply because a user needs conversational analytics.

Likewise, do not grant broad caller privileges simply because the application can technically use them.

Tool Scope Is a Security Boundary

The Casabase Cube agent does not automatically expose every procedure or function in the application.

Only deliberately configured capabilities should be available as tools.

Conceptually:

All Casabase Cube Capabilities
             │
             ▼
       Selected Agent Tools
             │
             ▼
        User Authorization
             │
             ▼
     Effective Agent Actions

Limiting the tool set reduces the number of operations the agent can attempt and makes agent behavior easier to review.

Administrative tools should be exposed only when they are required and appropriately privilege-controlled.

Tool Descriptions Matter

Agent tool names and descriptions help the language model determine which capability to invoke.

They should clearly describe:

• What the tool does
• When it should be used
• What inputs it expects
• Whether it reads or changes state
• Which operations require administrative privileges

Tool descriptions should not be treated as security controls.

Authorization must still be enforced through Snowflake privileges, Native App controls, Casabase Cube application roles, and the underlying procedure or function behavior.

Prompt Instructions Are Not Security Controls

Instructions such as:

Do not show confidential data.

or:

Only administrators may use this tool.

can help guide agent behavior, but they do not replace technical authorization.

The security model should remain effective even if:

• A user asks the agent to ignore its instructions.
• A prompt is ambiguous.
• A malicious instruction appears in retrieved content.
• The agent selects an unexpected tool.

The underlying Snowflake and Casabase Cube controls must determine whether an operation is permitted.

Prompt Injection and Tool Boundaries

Like other tool-using AI systems, agents can encounter instructions in user input or retrieved content that attempt to influence their behavior.

The appropriate defense is not to assume the language model will always distinguish trusted from untrusted instructions.

Instead:

Agent Reasoning
      │
      ▼
Explicit Tool Boundary
      │
      ▼
Snowflake Authorization
      │
      ▼
Casabase Cube Authorization
      │
      ▼
Permitted Operation Only

An unexpected tool choice should still be constrained by the privileges available to the user and application.

Multiple Tools Share Agent Context

A Cortex Agent can be configured with multiple tools.

When multiple tools or MCP servers participate in the same agent invocation, information returned by one tool can influence subsequent agent reasoning and tool selection.

For this reason:

• Add only tools required for the intended use case.
• Review the trust boundary of every connected tool.
• Avoid combining unrelated high-trust and low-trust capabilities without a clear reason.
• Treat tool output as data that can influence the agent.
• Keep sensitive administrative capabilities narrowly scoped.

This is particularly important when combining Casabase Cube tools with external or independently managed tools.

Do Not Put Secrets in Agent Instructions

Do not place secrets in:

• Agent system prompts
• Tool descriptions
• User instructions
• Documentation indexed for agent retrieval

Examples include:

• Passwords
• Private keys
• API tokens
• Authentication secrets
• Other credentials

Agent specifications can be inspectable by authorized Snowflake administrators, and prompts are not intended to function as secret storage.

Use Snowflake-supported credential and secret-management mechanisms where credentials are required by other platform capabilities.

Consumer Review of the Agent

Snowflake administrators should review an app-created agent before broadly delegating access.

Review areas include:

• Agent instructions
• Configured tools
• Tool descriptions
• Referenced objects
• Required caller grants
• Intended user roles

Snowflake provides agent metadata that administrators can inspect for this purpose.

The goal is to understand the application’s requested trust boundary before granting additional access.

Feature Policies

Snowflake feature policies allow consumers to control whether Native Apps can create certain object types, including Cortex Agents and MCP servers.

An organization can use feature policies to:

Allow Agent Creation

or:

Block Agent Creation

for all applications or selected applications.

This is a Snowflake governance control owned by the customer.

Casabase Cube should not attempt to bypass a feature policy that prevents agent creation.

If the agent cannot be enabled because of a feature policy, the appropriate Snowflake administrator must decide whether to permit the capability.

Administrative Operations

If administrative Casabase Cube tools are exposed to the agent, the same principle applies as elsewhere in the application:

Can Ask for Operation
        │
        X
Does Not Mean
        │
        ▼
Authorized to Perform Operation

For example, a user might ask:

Rebuild the Entity dimension.

The request should succeed only if:

• The relevant operation is exposed as an agent tool.
• The user has the required Casabase Cube administrative access.
• All applicable Snowflake and Native App privileges are satisfied.

Natural language changes how the operation is requested, not who is authorized to perform it.

Read vs. Write Capabilities

Where administrative tools are available, distinguish between operations that inspect state and operations that change state.

For example:

Read / Diagnostic
├── Discover metadata
├── Review configuration
├── Run validation
└── Run Health Check

State-Changing
├── Rebuild
├── Modify configuration
├── Change security
└── Other administrative operations

State-changing capabilities should be exposed conservatively and remain restricted to appropriate administrative roles.

The exact operations available depend on the installed Casabase Cube version and agent configuration.

Governed Metrics

The agent should use Casabase Cube as the authority for governed cube metrics.

Suppose the cube defines:

Revenue
Cost of Sales
Gross Margin
Gross Margin %

If the user asks:

Show Gross Margin % by region.

the agent should request the defined Casabase Cube member.

It should not independently invent another formula and present that result as though it were the governed cube calculation.

This protects semantic consistency as well as security.

Direct Fact-Table Queries Are Not Equivalent

Access to an underlying fact table does not automatically mean a direct query against that table is equivalent to a Casabase Cube query.

A governed cube result can depend on:

Fact Data
    +
Hierarchy Structure
    +
Aggregation Behavior
    +
Member Formulas
    +
Solve Order
    +
Time Behavior
    +
Casabase Cube Security

For cube analysis, the agent should use the Casabase Cube query path when these semantics are required.

This avoids creating an alternate analytical path with different security or business logic.

Data Classification

Casabase Cube Data Classification provides governance metadata for identifying the sensitivity or business classification of a cube.

Classification is a governance label.

It does not by itself:

• Grant access
• Deny access
• Filter rows
• Change agent privileges

Access enforcement remains the responsibility of Snowflake privileges, Casabase Cube application roles, and Casabase Cube row-level security.

See Data Classification.

Compliance and Privacy

Casabase Cube administrative reporting can support broader governance, privacy, and compliance activities.

These capabilities can help administrators review:

• Data inventory
• Privacy-related information
• Access configuration
• Governance metadata

They do not replace the organization’s own compliance program or Snowflake governance controls.

See Compliance and Privacy.

Audit and Monitoring

Organizations should monitor agent and Casabase Cube activity according to their operational and governance requirements.

Relevant sources can include:

Snowflake
├── Agent activity
├── Conversation threads
├── Tool invocations
└── Execution traces

Casabase Cube
├── Administrative activity
├── Configuration changes
├── Security changes
└── Other auditable application operations

Snowflake provides agent monitoring for conversation history, planning and tool traces, responses, and feedback. Access to agent monitoring is controlled separately from ordinary agent use.

The exact monitoring interfaces can evolve independently of Casabase Cube.

Use current Snowflake documentation for agent-specific monitoring capabilities and privileges.

See Audit Log for Casabase Cube audit behavior.

Data Does Not Need to Leave Snowflake for Cube Evaluation

Casabase Cube runs as a Snowflake Native App and performs its cube operations within Snowflake.

The agent invokes the Casabase Cube capabilities exposed within that environment.

Casabase Cube does not require a separate Casabase-hosted OLAP server to evaluate the query.

Conceptually:

Snowflake Account
│
├── Customer Data
├── Casabase Cube Native App
│      └── Cube Query Engine
└── Cortex Agent
       │
       ▼
   Governed Query

Snowflake’s own Cortex and agent services operate according to Snowflake’s platform architecture, terms, region availability, and AI governance controls.

Cross-Region Inference

Depending on the Snowflake region and the models used by Cortex Agents, Snowflake can require or use cross-region inference.

This is a Snowflake platform configuration, not a Casabase Cube data-routing feature.

Organizations with data-residency requirements should review:

• Snowflake model availability in their region
• Cross-region inference configuration
• Organizational AI policies
• Applicable Snowflake documentation and terms

before enabling the agent.

Security Review Checklist

Before broadly enabling the Casabase Cube agent, review:

[ ] Intended users and roles are identified
[ ] Users have only required Cortex Agent access
[ ] CUBE_PUBLIC and CUBE_ADMIN are granted appropriately
[ ] Required warehouses are explicitly approved
[ ] Caller grants are limited to required consumer objects
[ ] Agent tools are limited to required capabilities
[ ] Administrative tools are restricted
[ ] Agent instructions and tool descriptions contain no secrets
[ ] Row-level security has been tested with restricted users
[ ] Feature policies have been reviewed
[ ] Cross-region inference requirements have been reviewed
[ ] Agent activity can be monitored according to organizational requirements
[ ] Casabase Cube audit activity is reviewed where appropriate

Troubleshooting Access

When a user receives an access error, check the layers in order:

Snowflake User
      │
      ▼
Default Role
      │
      ▼
Cortex Agent Access
      │
      ▼
Default Warehouse + USAGE
      │
      ▼
Access to App-Created Agent
      │
      ▼
Required Caller Grants
      │
      ▼
Casabase Cube Application Role
      │
      ▼
Casabase Cube Security Rules

A failure at one layer should not be corrected by unnecessarily broadening another.

For example, do not grant CUBE_ADMIN to solve a missing Snowflake Cortex privilege.

See Access & Permission Issues.

Responsibility Model

The governance model can be summarized as:

Layer	Responsibility
Snowflake	Identity, authentication, RBAC, warehouses, Cortex access, caller grants, feature policies, agent infrastructure
Customer administrator	Approve Native App capabilities, caller access, agent delegation, user roles, and organizational AI policies
Casabase Cube	Application roles, cube semantics, row-level security, governance metadata, audit behavior, and exposed cube tools
Cortex Agent	Interpret requests and orchestrate configured tools within the permitted security boundary
User	Ask questions and perform only the operations authorized by the user’s effective access

No single layer replaces the others.

Key Takeaways

• The Casabase Cube agent does not create a bypass around Snowflake or Casabase Cube security.
• Snowflake identity and role-based access remain the foundation of user access.
• Cortex Agent access and Casabase Cube application access are separate authorization layers.
• Casabase Cube row-level security continues to apply to supported agent-generated cube queries.
• App-created agents operate within Snowflake’s restricted caller security model.
• Consumer-owned objects require explicit authorization where applicable.
• Agent tools should be deliberately scoped and protected by technical access controls.
• Prompt instructions are not security controls.
• Feature policies allow customers to govern whether Native Apps can create agents and MCP servers.
• Administrative capabilities remain restricted even when requested through natural language.
• Casabase Cube remains the authority for governed multidimensional calculations and security semantics.

Related Topics

• Intelligence Overview
• How Casabase Cube Works with Snowflake Intelligence
• Setting Up the Agent
• What the Casabase Cube Agent Can Do
• Using Casabase Cube in Snowflake Intelligence
• Tips and Limitations
• Security Model
• Roles and Privileges
• Access Control
• Data Classification
• Compliance and Privacy
• Audit Log