SnowPro Specialty: Gen AI Question 231
Single answerData safety and security considerationsA financial services company is building an internal chatbot on Snowflake that uses Cortex AI functions to summarize customer support cases. The source tables can contain personally identifiable information (PII), and the security team requires that analysts only see data they are already authorized to access. They also want to reduce the risk of exposing sensitive values in prompts sent to the model. Which approach best meets these requirements?
- A
Create a secure view that masks or excludes sensitive columns, enforce row-level access with Snowflake governance policies, and have the chatbot query only that governed object before passing the minimized prompt to Cortex functions.
- B
Grant analysts broad SELECT access to the raw support tables because Cortex functions run inside Snowflake, which eliminates the need for masking policies or row access policies.
- C
Export the support data to an external application, remove PII there, and then send full case histories back into Snowflake for summarization so Snowflake governance does not interfere with model quality.
- D
Rely on prompt instructions that tell the model not to reveal sensitive data, while allowing the chatbot to read directly from the base tables because prompt engineering is the primary control for data security.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to apply Snowflake-native governance controls to the data before it is used in generative AI workflows. For sensitive workloads, best practice is to combine least-privilege access, row-level and column-level protections, and data minimization. In Snowflake, this commonly means using role-based access control together with governance features such as row access policies, masking policies, and secure views so that only authorized data is exposed to downstream applications and AI functions. For GenAI use cases, reducing the amount of sensitive information included in prompts is also an important security measure. Prompting alone is not a reliable protection mechanism; security should be enforced through governed data access and policy controls. This aligns with Snowflake guidance around data governance, access control, and secure use of Cortex AI capabilities.
- A. Correct.
Correct. This approach applies Snowflake's native data governance controls before inference occurs. Using a secure view with masking or omitted columns helps minimize sensitive data exposure, while row-level governance ensures users only access records they are authorized to see. Restricting the chatbot to governed objects instead of raw tables follows least-privilege and data minimization best practices. Sending only the necessary, already-governed context to Cortex functions is the strongest option for reducing sensitive data exposure.
- B. Incorrect.
Incorrect. Although Cortex functions execute within Snowflake, that does not replace standard access-control and governance requirements. Analysts still should not receive unrestricted access to raw tables containing PII. Snowflake security features such as masking policies, row access policies, and secure views remain important controls for limiting exposure based on role and need-to-know.
- C. Incorrect.
Incorrect. Moving data to an external application increases operational complexity and can expand the attack surface. It also bypasses the advantage of applying Snowflake-native governance close to the data. The statement that Snowflake governance would interfere with model quality reflects a misconception: proper data minimization and policy-based protection are security best practices and can be implemented without unnecessarily exposing raw sensitive data.
- D. Incorrect.
Incorrect. Prompt instructions are not a security boundary. Telling a model not to reveal sensitive information does not reliably prevent exposure if the underlying prompt or retrieved context already contains that information. Direct access to base tables with PII violates least-privilege principles and leaves sensitive data unnecessarily exposed to both users and the model context.