# Admin Series: Snowflake Multi-Party Approval > Source: > Published: 2026-08-07 11:03:19+00:00 A few years back, I sat in on a post-incident call with a customer who had just watched a single compromised ACCOUNTADMIN account turn their weekend into a nightmare. Multi-factor authentication got switched off in seconds. Encryption keys were touched next. By the time anyone noticed, the damage was already done, and the worst part was that none of it needed a second person to sign off. One login was enough to bring an entire account to its knees. That conversation stuck with me, and it is exactly why I have been paying close attention to Snowflake’s Multi-Party Approval feature, or MPA as most of us in the community are already calling it. It is not a flashy AI capability and it will not show up in a keynote demo reel, but if you run a Business Critical or Enterprise account, it might be the single most important governance release Snowflake has shipped in a long time. MPA introduces a mandatory second set of eyes for the operations that could otherwise cause irreversible damage to your Snowflake account. Once a policy is active, no single administrator, however senior or trusted, can execute a protected change on their own. The action gets intercepted, a request is created, and at least one other authorized approver has to review and sign off before anything runs. Snowflake built this specifically as a defense against ransomware and catastrophic data loss scenarios. Think about what a compromised admin credential can do today: disable MFA, rotate or deactivate Tri-Secret Secure customer-managed keys, or hand out ACCOUNTADMIN to a rogue role. Any one of those actions alone could lock your organization out of its own data or open the door wide for an attacker. MPA enforces a four-eyes principle so that an attacker cannot just compromise one account and walk away with the keys to the kingdom. They would need to compromise multiple distinct administrators, and that is a much harder problem to solve on their end. I keep telling clients that the threat surface around Snowflake has changed shape over the last two years. It is no longer just about who has SELECT access to a schema. With Cortex AI features, external integrations, service accounts, and an ever-growing list of privileged roles, the blast radius of one bad login has grown considerably. Ransomware groups have also gotten smarter. They are not just encrypting data anymore, they are going after the administrative controls themselves, because disabling MFA or rotating out encryption keys does more damage in far less time than ex-filtrating a few tables. Regulators have noticed this shift too. Dual-control and four-eyes requirements show up constantly in SOC 2, ISO 27001, and industry-specific frameworks like PCI DSS and HIPAA. Until now, most Snowflake customers were building their own workarounds, usually a mix of change tickets, Slack approvals, and a lot of trust. MPA finally gives you a native, auditable mechanism instead of a process built on goodwill. The mechanics are refreshingly simple once you have seen it in action, and it follows a clean four-step cycle. **•** **Intercept: **A requester tries to run a protected SQL statement or the equivalent Snowsight action. Snowflake blocks it immediately and returns an MPA_APPROVAL_REQUIRED error along with a unique request ID. **•** **Justification: **The requester explains why the change is needed, either through the Snowsight prompt or by calling SYSTEM$UPDATE_MULTI_PARTY_APPROVAL_JUSTIFICATION with the request ID. This moves the request to a pending state and notifies the designated approvers by email. **•** **Review: **Approvers log into an active Snowsight session, look at the justification, and cast an approve or reject vote. One rejection kills the request outright, which is a deliberate and, in my view, a sensible design choice. **•** **Replay: **Snowflake does not auto-execute anything once approved. The requester has to run the exact original statement again within a three-day window, and the engine matches it to the approved request before letting it through. That replay step is easy to overlook when you first read the documentation, but it is one of my favorite details in the whole design. It means approval alone is never enough to make something happen. The person who wanted the change still has to come back and consciously push the button, which removes any chance of an approval sitting around and getting exploited later. Snowflake grouped the protected operations into three buckets inside Snowsight, and the list tells you a lot about where the real risk lives in an account. **•** **Admin operations: **changes to MPA configuration itself, disabling MFA or resetting passwords, managing Tri-Secret Secure keys, granting or revoking privileged roles such as ACCOUNTADMIN, modifying Cortex AI guardrails, and adjusting data retention settings. **•** **Policy operations: **edits to network policies, session policies, authentication policies, and password policies. **•** **Security integration operations: **changes to Snowflake OAuth, External OAuth, and SCIM integrations. One detail I want to call out because it genuinely impressed me: every MPA policy is required to include a rule covering the MODIFY_MULTI_PARTY_APPROVAL operation itself. In plain terms, a compromised admin cannot quietly switch MPA off to clear a path for the rest of the attack. That self-protecting rule is what separates a real security control from a checkbox feature. ``` ALTER MULTI PARTY APPROVAL POLICY DB_MPA.PUBLIC.MPA_POLICYAS $$description: Standard MPA security policyrules: - name: Rajiv rule description: Protect editing Tri-Secret Secure keys, disabling multi-factor authentication, and modifying multi-party approval settings operations: - MODIFY_MULTI_PARTY_APPROVAL - MODIFY_TRI_SECRET_SECURE - DISABLE_MULTI_FACTOR_AUTHENTICATION - MODIFY_NETWORK_POLICY - MODIFY_SESSION_POLICY - MODIFY_AUTHENTICATION_POLICY - MODIFY_PASSWORD_POLICY - MODIFY_OAUTH_INTEGRATION - MODIFY_EXTERNAL_OAUTH_INTEGRATION - MODIFY_SCIM_INTEGRATION approvers: users: - '"RAJIVGUPTA780184"' required_approvals: 1 request_duration_days: 3 self_approval_allowed: false - name: L1 description: L1 operations: - MODIFY_DATA_RETENTION_TIME - MODIFY_PRIVILEGED_ROLE_GRANTS - MODIFY_CORTEX_GUARDRAILS approvers: users: - '"RAJIVGUPTA780184"' required_approvals: 1 request_duration_days: 3 self_approval_allowed: true$$ ``` A policy is really just a collection of rules, and each rule defines which operations it covers, who the approvers are, and how many approvals are needed before the request clears. You get to decide the minimum approvals required, anywhere from one to twenty, though Snowflake defaults to two and I would strongly recommend keeping it there for anything touching MFA or encryption keys. You also control the request duration window, capped at fourteen days, and whether a requester’s own vote counts toward the quorum if they happen to be listed as an approver as well. One operational nuance worth remembering is that Tri-Secret Secure changes get a 72-hour grace period after a policy is first attached to the account, after which the extra speed bump for those operations goes away. Plan your rollout with that timing in mind rather than being surprised by it later. I have implemented enough governance controls to know that nothing is free. MPA is genuinely valuable, but it is worth being honest about where it adds friction. **•** **Ransomware and insider threat defense: **protecting MFA settings and Tri-Secret Secure keys so that one compromised credential cannot render an entire account inaccessible or exposed. **•** **Privileged access governance: **requiring a second approver before anyone is granted ACCOUNTADMIN, SECURITYADMIN, or MANAGE GRANTS, which closes a gap a lot of security teams have been asking about for years. **•** **Regulated industries: **financial services, healthcare, and public sector accounts that need documented dual-control evidence for auditors without building a parallel ticketing process outside Snowflake. **•** **Managed service providers and large enterprises: **any account where more than one team touches ACCOUNTADMIN and a mistake by one person should never be a single point of failure for the whole organization. **•** **AI governance: **with Cortex guardrail changes now sitting inside the protected operations list, this becomes a practical control point as more teams push AI features into production and want a second opinion before guardrails move. • Keep the MPA self-protecting rule at least as strict as every other rule in the policy. • Require a minimum of two approvals everywhere. A single approver defeats the purpose. • Set the request duration window to one or two days for most rules so approvals do not linger indefinitely. • Make sure you have more than one ACCOUNTADMIN in the account, otherwise you can lock yourself out with no one left to approve. • Confirm every approver has MFA enrolled and a validated email address before you go live. • Revisit your approver list every quarter. People change teams and leave companies, and a stale approver list quietly weakens the control. I have watched Snowflake ship a lot of security features over the years, and most of them protect data at rest or in transit. MPA is different because it protects the administrative layer itself, which is exactly where the most damaging attacks tend to start. It will not eliminate risk on its own, and it does add a real step to how your team operates, but that friction is the point. The whole idea is to make sure no single person, however senior, can unilaterally take an action that could take your entire account down. If you are running Business Critical Edition and you have not looked at MPA yet, put it on your calendar this quarter. Start with the operations that protect MFA, privileged roles, and encryption keys, get comfortable with the workflow, and expand from there. It is one of those controls you genuinely hope you never need, right up until the day you are very glad you had it. I hope this blog helps you to get insight into the **Snowflake Multi-Party Approval.** Please don’t hesitate to ask a question in the comment section if you have any doubts regarding this. Give a clap if you like the blog. Stay connected to see much more such cool stuff. Thanks for your support. Disclaimer: Please note opinions expressed in this article are solely my own and do not represent the views or opinions of my employer. Rajiv Gupta is VP of Technology at Kipi.ai and a six time Snowflake Data Superhero. He writes and speaks regularly on Snowflake, Cortex AI, and the broader shift toward cloud native data platforms, drawing on hands on experience running migrations and modernization projects for enterprise clients. **Blog: **[https://medium.com/@rajivgupta780184](https://medium.com/@rajivgupta780184) **YouTube: **[https://www.youtube.com/c/RajivGuptaEverydayLearning](https://www.youtube.com/c/RajivGuptaEverydayLearning) **LinkedIn: **[https://www.linkedin.com/in/rajiv-gupta-618b0228/](https://www.linkedin.com/in/rajiv-gupta-618b0228/) **X :** [https://twitter.com/RAJIVGUPTA780](https://x.com/RAJIVGUPTA780) #Keeplearning #Keepsharing #Everydaylearning #RajivGupta #DataSuperHero [Admin Series: Snowflake Multi-Party Approval](https://blog.devgenius.io/admin-series-snowflake-multi-party-approval-b8110987f960) was originally published in [Dev Genius](https://blog.devgenius.io) on Medium, where people are continuing the conversation by highlighting and responding to this story.