Setting Up the Agent

Casabase Cube can provide a Cortex Agent as part of the Snowflake Native App.

The agent exposes Casabase Cube discovery, query, and other supported capabilities through Snowflake’s agent platform, allowing authorized users to work with cube data through a conversational experience.

Setup involves two distinct responsibilities:

Casabase Cube
     │
     ├── Provides the Agent
     ├── Provides Cube-Aware Tools
     └── Provides Application Roles
             │
             ▼
Snowflake Administrator
     │
     ├── Approves Required App Capabilities
     ├── Grants Required Caller Access
     ├── Grants Users Access to Cortex Agents
     └── Delegates Access to the App-Created Agent

Because Casabase Cube is a Snowflake Native App, do not create a separate external copy of the Casabase Cube agent unless specifically directed by Casabase support or product documentation.

Prerequisites

Before enabling the agent, verify that:

• Casabase Cube is installed.
• At least one cube has been configured and built.
• Users who will query cubes have the appropriate Casabase Cube application role.
• The Snowflake account has the required Cortex Agents and Snowflake CoWork / Snowflake Intelligence capabilities enabled for app-created agents.
• An appropriate Snowflake warehouse is available for agent execution.
• Required AI capabilities are permitted by your organization’s Snowflake governance policies.

Depending on your Snowflake region and model availability, Snowflake may also require cross-region inference to be enabled for the models used by Cortex Agents.

Use current Snowflake documentation to determine whether cross-region inference is required for your account.

Step 1: Verify Casabase Cube Application Access

Casabase Cube uses its existing application roles for cube access.

The two primary roles are:

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

For a general analyst role:

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_PUBLIC
TO ROLE ANALYST_ROLE;

For an administrator:

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_ADMIN
TO ROLE CUBE_ADMINISTRATOR;

Replace CASABASE_CUBE with the installed application name in your account.

General users should normally receive CUBE_PUBLIC. Grant CUBE_ADMIN only when the user requires administrative Casabase Cube capabilities.

See Roles and Privileges.

Step 2: Enable the Required Cortex Agent Access

Users who invoke Cortex Agents require access to Snowflake’s Cortex Agent capability.

Snowflake provides:

SNOWFLAKE.CORTEX_AGENT_USER

for Cortex Agent access without granting the broader set of Cortex capabilities.

For example:

GRANT DATABASE ROLE SNOWFLAKE.CORTEX_AGENT_USER
TO ROLE ANALYST_ROLE;

Snowflake also permits Cortex Agent access through:

SNOWFLAKE.CORTEX_USER

which grants access to a broader set of Snowflake Cortex features.

Use the narrower CORTEX_AGENT_USER role when users only require Cortex Agent access and your organization’s Snowflake access model calls for least privilege.

Important: Snowflake evaluates Cortex Agent permissions using the querying user’s default role, not merely the role currently selected in a session. Ensure the required Cortex Agent privileges are available through the user’s default role.

Step 3: Verify the User’s Default Warehouse

Each user who invokes a Cortex Agent must have a default Snowflake warehouse.

The user’s default role must also have:

USAGE

on that warehouse.

For example:

GRANT USAGE ON WAREHOUSE ANALYTICS_WH
TO ROLE ANALYST_ROLE;

If the user does not have a default warehouse, or the default role cannot use that warehouse, Cortex Agent requests can fail even when other privileges appear correct.

A Snowflake administrator can review a user’s defaults with:

DESC USER <user_name>;

Verify:

DEFAULT_ROLE
DEFAULT_WAREHOUSE

when troubleshooting agent access.

Step 4: Enable the Casabase Cube Agent

Use the Casabase Cube administrative interface to enable or configure the agent according to the options available in the installed application version.

Casabase Cube provides the agent definition and its cube-aware tools as part of the Native App integration.

The exact administrative workflow can evolve as Snowflake’s Native App and Cortex Agent capabilities evolve, so use the controls presented by the current Casabase Cube version rather than relying on a manually maintained standalone CREATE AGENT script.

At a high level:

Casabase Cube
     │
     ▼
Agent Configuration
     │
     ▼
App-Created Cortex Agent
     │
     ▼
Snowflake Agent Experience

Step 5: Approve Required Native App Capabilities

A Snowflake Native App can request access to Snowflake capabilities that are required by particular application features.

For the Intelligence integration, the Snowflake administrator should review and approve only the capabilities required for the configured Casabase Cube agent.

These can include access related to:

• Cortex Agent functionality
• Snowflake compute
• Session context
• Consumer-owned objects used by approved agent tools

The exact requests depend on the installed Casabase Cube version and the agent capabilities being enabled.

Review requested privileges and references in Snowflake before approving them.

Step 6: Grant Caller Access Where Required

An app-created Cortex Agent does not automatically gain unrestricted access to customer-owned Snowflake objects.

When an agent tool requires a consumer-owned object outside the application, Snowflake uses caller grants to define what the app-created agent is permitted to access.

Examples can include:

Warehouse
Database
Schema
Table
View
Semantic View
Other Supported Consumer Object

Grant only the caller access required for the intended Casabase Cube functionality.

Conceptually:

App-Created Agent
       │
       ▼
Needs Consumer Object?
       │
       ├── No ──► Use App-Owned Capability
       │
       └── Yes
              │
              ▼
       Explicit Caller Grant
              │
              ▼
       Approved Consumer Object

This creates an explicit trust boundary between the Native App and customer-owned Snowflake objects.

Do not broadly grant caller access to databases, schemas, or tables merely to make an agent error disappear.

Step 7: Delegate the Agent to User Roles

Snowflake’s app-created agent model grants USAGE on the agent and its app-owned tools to an application role. The consumer administrator then grants the appropriate application role to the Snowflake account roles that should use the agent.

For Casabase Cube, general analytical users should normally receive CUBE_PUBLIC; administrators who require administrative capabilities receive CUBE_ADMIN.

For example:

GRANT APPLICATION ROLE CASABASE_CUBE.CUBE_PUBLIC
TO ROLE ANALYST_ROLE;

The user’s default role must be the role, or inherit a role, that has the required Cortex Agent privileges, warehouse access, application role, and any privileges required on consumer-owned objects used by the agent’s tools.

Grant access only to roles that require the Casabase Cube conversational experience.

The intended access model is:

User
 │
 ▼
Default Snowflake Role
 │
 ├── Cortex Agent Database Role
 ├── Default Warehouse USAGE
 ├── Required Consumer-Object Privileges
 └── Casabase Cube Application Role
             │
             ├── CUBE_PUBLIC
             └── CUBE_ADMIN
                    │
                    ▼
             App-Created Agent

For tools that use consumer-owned objects, the user’s object privileges and the application’s approved caller grants are both required.

After the application role is delegated, Snowflake can surface the app-created agent through supported agent experiences such as Snowflake Intelligence / Snowflake CoWork, the Cortex Agents API, and SQL, subject to the capabilities enabled in the account.

Step 8: Verify Casabase Cube Session Access

Casabase Cube uses Snowflake session context for functionality that depends on the executing user’s identity.

The Native App requires:

READ SESSION

for capabilities including user-context evaluation used by Casabase Cube row-level security and supported interactive query functionality.

Verify that the application has the required privilege:

SHOW GRANTS TO APPLICATION CASABASE_CUBE;

If required and not already approved:

GRANT READ SESSION ON ACCOUNT
TO APPLICATION CASABASE_CUBE;

Replace CASABASE_CUBE with the installed application name.

Step 9: Configure Documentation Search if Available

Casabase Cube agent configurations can include a documentation or knowledge-search capability for product questions.

This allows the agent to distinguish between requests such as:

How do I rebuild a dimension?

and:

Show revenue by entity.

Conceptually:

Product / How-To Question
          │
          ▼
Documentation Search

Cube Data Question
          │
          ▼
Casabase Cube Query Tool

If the installed Casabase Cube version provides an AI or Intelligence setup action for creating or refreshing the documentation-search capability, complete that setup through the application interface.

Do not assume that documentation search is required for basic cube querying unless the installed version identifies it as a prerequisite.

Step 10: Test Discovery

Start with a low-risk discovery request.

For example:

What Casabase Cube cubes are available?

or:

What dimensions are in the Finance cube?

A successful response confirms that:

• The user can access the agent.
• The agent can invoke the applicable Casabase Cube discovery capability.
• The user’s Casabase Cube application access is sufficient for discovery.

If discovery fails, resolve access or agent configuration before testing more complex analytical questions.

Step 11: Test a Simple Query

After discovery succeeds, test a small known query.

For example:

Show Revenue for January FY26.

Use a cube and members whose expected result is already known.

Then compare the agent result with the same analytical request executed through another supported Casabase Cube query path.

Conceptually:

Known Casabase Cube Query
           │
           ▼
Expected Result
           │
           ▲
           │
Agent-Generated Cube Query

The values should be consistent because both requests are evaluated by the Casabase Cube query engine.

Step 12: Test Row-Level Security

If Casabase Cube row-level security is configured, test the agent using a user with a known restricted scope.

For example, if a user is permitted to see only:

North America

ask a question that would otherwise include a broader Entity population.

Verify that the agent-generated query returns only the data permitted to that user.

The agent is not a security bypass. Casabase Cube security continues to apply through the supported query path.

See Governance and Security.

Step 13: Test Conversational Refinement

After a simple query succeeds, test a follow-up sequence.

For example:

Show actual revenue by region for FY26.

then:

Break North America down to the next level.

then:

Compare it with FY25.

This validates both the Casabase Cube tools and the conversational orchestration layer.

Recommended Role Design

A typical deployment can separate general users from administrators.

General Users

Snowflake Role
    │
    ├── Cortex Agent Access
    ├── Default Warehouse USAGE
    ├── Access to App-Created Agent
    └── Casabase Cube CUBE_PUBLIC

Casabase Cube Administrators

Snowflake Role
    │
    ├── Required Cortex / Agent Access
    ├── Required Warehouse Access
    ├── Access to App-Created Agent
    └── Casabase Cube CUBE_ADMIN

Do not grant CUBE_ADMIN simply because a user needs to use the agent.

Agent access and Casabase Cube administrative access are separate decisions.

Feature Policies

Snowflake allows administrators to control whether Native Apps can create objects such as Cortex Agents or MCP servers through feature policies.

If the Casabase Cube agent cannot be created or enabled even though other prerequisites are satisfied, determine whether an account-level or application-level feature policy blocks agent creation.

This is a Snowflake governance control.

Do not attempt to work around an organizational feature policy. Have the appropriate Snowflake administrator review whether the Casabase Cube agent should be permitted.

Cross-Region Inference

Cortex Agent model availability can vary by Snowflake region.

Snowflake can use cross-region inference when the required model is not available in the account’s region, subject to account configuration and organizational policy.

If agent creation succeeds but model execution fails, review the current Snowflake Cortex model availability and cross-region inference configuration.

Cross-region inference is a Snowflake platform setting and should be evaluated according to your organization’s data-governance requirements.

Troubleshooting Agent Access

When a user cannot access or invoke the Casabase Cube agent, check the access layers in this order:

User Default Role
        │
        ▼
Cortex Agent Database Role
        │
        ▼
Default Warehouse + USAGE
        │
        ▼
Access to App-Created Agent
        │
        ▼
Required Tool / Caller Access
        │
        ▼
Casabase Cube Application Role
        │
        ▼
Casabase Cube Security

Common causes include:

• Cortex Agent access was granted to a role other than the user’s default role.
• The user has no default warehouse.
• The default role lacks warehouse USAGE.
• The app-created agent has not been delegated to the user’s role.
• Required caller access has not been approved.
• The user lacks CUBE_PUBLIC or CUBE_ADMIN.
• A Snowflake feature policy prevents the required agent capability.
• Cross-region inference or model availability prevents execution.

See Access & Permission Issues for general Casabase Cube access troubleshooting.

Security Recommendations

Use least privilege when configuring the integration.

In particular:

• Grant CUBE_PUBLIC rather than CUBE_ADMIN to general users.
• Use the narrower Snowflake Cortex Agent role when broader Cortex access is unnecessary.
• Grant only required warehouse access.
• Grant caller access only to consumer objects the agent legitimately requires.
• Review Native App capability requests before approving them.
• Test row-level security using representative restricted users.
• Review agent activity using the monitoring capabilities provided by Snowflake where appropriate.

Do Not Create Parallel Business Logic

The setup should preserve Casabase Cube as the analytical authority.

Avoid configuring a parallel agent path that independently calculates governed cube metrics directly from relational tables when those metrics depend on:

• Cube hierarchies
• Dynamic aggregation
• Member formulas
• Solve order
• Time balance
• Casabase Cube row-level security

For cube analysis, configure the agent to use Casabase Cube’s cube-aware tools.

Validation Checklist

Before making the agent broadly available, verify:

[ ] Casabase Cube is installed and configured
[ ] At least one cube is built
[ ] Required Native App capabilities are approved
[ ] Required Cortex Agents and Snowflake CoWork / Snowflake Intelligence capabilities are enabled
[ ] App-created agent is available
[ ] Users have Cortex Agent access through their default role
[ ] Users have a default warehouse
[ ] Default roles have warehouse USAGE
[ ] Agent access is delegated to intended user roles
[ ] Users have CUBE_PUBLIC or CUBE_ADMIN as appropriate
[ ] Required caller access is limited and approved
[ ] READ SESSION is available to Casabase Cube
[ ] Discovery works
[ ] A known cube query returns the expected result
[ ] Row-level security behaves as expected
[ ] Conversational follow-up works

Related Topics

• Intelligence Overview
• How Casabase Cube Works with Snowflake Intelligence
• What the Casabase Cube Agent Can Do
• Using Casabase Cube in Snowflake Intelligence
• Governance and Security
• Tips and Limitations
• Roles and Privileges
• Access Control
• Access & Permission Issues