Understand who can access which Snowflake data.
Define access boundaries before changing permissions.
Review users, roles, service accounts, BI and integration tools, and AI agents based on the data they can access and the actions they can perform. We connect current permissions with access paths, records, and approval responsibilities, then agree whether changes or verification are needed, what should happen next, and who is responsible.
A role matrix alone does not show how data is actually accessed
Data may also be accessed through service accounts, connected applications, BI and integration tools, APIs, and AI agents. Reviewing user roles alone can miss those paths.
Roles and grants have accumulated
Identify who requests, approves, reviews, and revokes access, and whether the permissions are still used.
Protected data and allowed actions are not clearly defined
Review which read, change, and sharing actions are needed for each business purpose and data-sensitivity level.
A shared service account has broad access
Distinguish the permissions each application or integration requires from permissions that are no longer used.
AI agent access boundaries are unclear
Define whose authority the agent uses, what it may retrieve or combine, and which activities must be recorded.
Review identities, data, permissions, access paths, and records as one system
A permission name does not reveal the full access path. The review connects each identity to the data and actions available through its access paths, the records captured, and the owners responsible for approval and change decisions.
Access Identities
Distinguish users and roles, service accounts, applications, external tools, and AI agents.
Data & Protection Level
Identify the databases, schemas, tables, fields, sensitivity levels, and business uses within the agreed scope.
Permitted Actions
Define which identities need to read, change, execute, own, or share data and which actions must remain restricted.
Access Paths
Review login methods, network paths, BI and integration tools, APIs, and the authentication used to access the data.
Access & Change Records
Define which login, query, execution, and permission-change records need to be reviewed and retained.
Approval & Lifecycle Ownership
Clarify responsibility for access requests, approvals, periodic reviews, revocation, and exception handling.
Review scope — The accounts, data, roles, access paths, and period covered by access records are agreed before work begins. The review does not assume that every data set and connected system will be included at once.
Define the identity, data, tools, and stop conditions for each AI agent
An AI agent may use several data sources and tools in one workflow. The access review must therefore consider both individual permissions and what combined results or follow-on actions may expose.
Which identity does the agent use?
Decide whether the agent uses a dedicated identity or operates within the requesting user’s permitted scope.
Which data and tools may it use?
Define the data and the query or execution tools required for the business purpose, together with actions that are not allowed.
What may the output reveal?
Review not only source-data permissions but also what may be exposed when results from multiple data sets are combined.
Which activity must be recorded?
Define the records needed for user requests, data references, tool calls, and processing results.
When must the agent stop and escalate?
Set conditions for stopping and handing work to an owner when a request exceeds the agent’s authority, the user’s identity cannot be confirmed, or an exception occurs.
Who changes or revokes access?
Assign an approver to review, change, suspend, or revoke permissions when the agent’s responsibilities change.
Connection to AgentOps — This page addresses data-access boundaries. Agent evaluation, execution controls, deployment, and change management are reviewed separately under AgentOps & Managed Operations.
Establish current access before deciding what should change
Separate responsibilities — Current-state review, policy design, permission changes, and verification are distinct scopes of work. The required stages and responsible parties are defined after reviewing the client’s environment and approval process. Those responsibilities are then documented in the agreement.
If permissions change, define what must be allowed, denied, and recorded
The items below are examples of verification criteria that may be agreed when change and testing are in scope. The actual activities and responsible parties are defined in the agreement.
Allowed Access
Confirm that the designated identity can reach the required data and perform the intended actions.
Denied Access
Confirm that out-of-scope data, actions, and unapproved access paths are blocked as intended.
AI Agent Boundaries
Review how the agent stops when a request exceeds the user’s permitted scope or calls a tool that is not allowed.
Records & Traceability
Check whether the required level of detail shows who accessed which data, what actions they performed, and when.
Change & Revocation
Check whether permissions are updated or revoked through the agreed process after a role change or the end of an assignment.
Exceptions & Recovery
Review the procedure for stopping work and confirming the previous state if a change has an unexpected business impact.
Verification scope — Test scenarios, allow and deny criteria, accounts and data, and the acceptance owner are agreed before a change. Evidence formats required for a specific regulation or internal review are defined separately after the applicable requirements are confirmed.
Separate data ownership, approval authority, and implementation responsibility
Protection Criteria & Access Approval
The client confirms the protection level and business access requirements for its data, then names the final approver and operating owner.
Current-State & Role Review
Nex & Bridge documents the current environment and identifies priority review items. Responsibilities for later stages are defined in the agreement after the client’s environment and approval process are understood.
Change, Revocation & Exception Support
Determine separately whether ongoing access reviews, permission changes, revocation, and investigations of unusual access require operational support.
Operating support — Recurring access reviews and operating support may be agreed as part of Managed Services. The agreement defines the managed scope, support hours, change authority, responsibilities, exclusions, and any applicable service-level commitments.
Start with the identities and data that matter most
Tell us which accounts and data should be reviewed first, the current roles and service accounts, any planned AI agent use, and who owns access approval. We will help define the initial review scope.