Which Snowflake Role Should an AI Agent Use Through the MCP Server?

The role decision comes first

When an AI agent connects to Snowflake through the Model Context Protocol server, every action it takes is bounded by the role it operates under. That choice sets the maximum data and capabilities the agent can reach, so it should be made deliberately and not left to whatever default a connection happens to pick up.

The recommended model has three parts. First, a dedicated role per agent function, for example one role for an agent that answers questions over a defined set of reporting views and a separate role for an agent that searches a defined document corpus. Second, a dedicated service identity that holds only that role, so the agent never borrows a person's session or credentials. Third, least-privilege grants: the role receives access to the specific objects its tools need and nothing else.

This follows the general guidance that each role should carry the fewest privileges needed for its function, that roles should be reviewed periodically, and that system accounts should be audited. It also supports separation of duties, which keeps one agent from holding conflicting privileges.

Why administrative and inherited human roles are unsuitable

ACCOUNTADMIN and SYSADMIN exist to administer an account and its objects. An agent that runs under either one can reach far more than any single task requires, and it may be able to change configuration or permissions. OWASP describes this pattern as excessive agency: write access to permission-management interfaces that the primary task does not need, and no distinction between read operations and privileged writes when a request comes from an agent.

A human user's inherited role is a quieter version of the same problem. Roles accumulate over a person's tenure, and the agent inherits all of them. Agent behavior is non-deterministic, so the practical question is not what the agent usually does but what it could do if prompted or manipulated into trying. OWASP also notes that MCP servers operate with delegated user permissions, dynamic tool-based architectures, and chained tool calls, which raises the impact of a single weakness.

The OWASP MCP Top 10 names two relevant risks. MCP02, privilege escalation via scope creep, describes loosely defined permissions that expand over time and give agents excessive capabilities. MCP07, insufficient authentication and authorization, covers servers, tools, or agents that fail to verify identities or enforce access controls during interactions. A dedicated role does not remove either risk, but a narrow starting point leaves far less to creep.

Building and scoping the dedicated role

Work from the tools outward. Decide what the agent must do, expose only the tools that serve that purpose, and derive the role's grants from those tools.

• 1. Inventory the tools: List every tool the MCP server would expose to this agent, such as analytics, search, or SQL execution. Remove any tool the function does not need.
• 2. Map each tool to minimum privileges: For each remaining tool, record the objects it touches and the lowest privilege that works. Prefer read access and keep write access out unless the task requires it.
• 3. Create a role per function: Create a role for this function only. Do not reuse a role across agents with different trust levels, for example internal and user-facing.
• 4. Bind it to a service identity: Assign the role to a dedicated non-human identity. Avoid long-lived static secrets where possible and prefer short-lived, task-scoped access that can be revoked quickly.
• 5. Exclude permission management: Grant no ability to alter roles, grants, or configuration unless the agent's task is administrative, which it should rarely be.
• 6. Test isolation: Attempt to reach objects and records outside the intended scope through the agent interface, and confirm the responses are restricted.

What a role does not constrain

NIST describes role-based access control as predefined roles that carry specific privileges and to which subjects are assigned. Attribute-based access control, by contrast, evaluates rules against attributes of the subject, object, operation, and environment for each request. A Snowflake role is the first kind of control: it answers whether this identity may access this object. It does not evaluate the circumstances of an individual call.

That leaves gaps inside the permitted scope. A role that can read a table cannot limit how broadly an agent queries it within one interaction. It cannot redact sensitive values that sit in an otherwise permitted result. It does not limit how often an agent calls a tool, and it does not pause a high-risk action for a person to approve.

OWASP Cornucopia describes a related failure as missing per-request authorization checks: the agent receives broad data-access credentials at initialization and never re-validates permissions before each retrieval. The recommendation is to enforce authorization at query time, not only at initialization, and to provision data connectors with the minimum access needed. NIST makes a similar point about runtime verification: without it, an agent holding a valid token cannot be interrupted if it is hijacked or manipulated mid-task.

Where runtime policy on MCP tool calls fits

OWASP guidance says authorization should be enforced in an execution component outside the agent's context, with an independent policy service validating scope, privilege, and approval state before execution. The agent can propose an action, but it does not decide whether the action proceeds. Snowflake roles provide the ceiling; a separate layer applies that decision to each call.

Trussed provides this layer for MCP servers. It enforces policy in the execution path on individual interactions and tool calls, with five outcomes: allow, redact, block, rate limit, and escalate for human approval. Policy is enforced at runtime, not reviewed after the fact. In practice, a call within the role's scope can be allowed, a result containing sensitive values can be redacted, an out-of-policy call can be blocked, a runaway call pattern can be rate limited, and a high-risk action can be sent to a person for approval.

Each enforcement decision produces audit-ready evidence, which gives a regulated enterprise a record of what its agent was allowed to do and what it did. Evidence maps to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act, and NIST. Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The dedicated role remains the foundation. Runtime enforcement does not replace least-privilege grants; it bounds how the access those grants allow is used.