According to Snowflake's Python UDF documentation, the database role that allows use of the default PyPI Artifact Repository is granted to PUBLIC by default. That means any role can use it unless an administrator changes the grant or applies a packages policy. Review it if your account holds sensitive data.
What the documentation says
Snowflake's default Artifact Repository installs packages from PyPI. To use it, the role creating a function needs the SNOWFLAKE.PYPI_REPOSITORY_USER database role. The page states that this role is granted to PUBLIC by default.
In Snowflake, PUBLIC is a role every user holds. So, out of the box, anyone who can create a Python function can reference packages from the public index.
The page also explains defaults. If a function does not set an artifact repository, Snowflake uses the account's default Python artifact repository setting, which can be set at schema, database or account level.
Why this deserves a look
This is not a flaw. It is a default that favors convenience, and many data teams rely on it. The question for security is whether that default matches your risk.
Consider what a Python function in a warehouse can touch. The docs note that UDFs run in a restricted engine, which limits what code can do, but your function code can still process the data you pass to it. A package pulled from a public index becomes part of that processing. And Snowflake states it does not check or curate the security of packages from external sources.
How to review your account
Ask your Snowflake administrator these questions, using the object names from the docs.
- Is the PYPI_REPOSITORY_USER database role still granted to PUBLIC? If so, is that intended?
- Which roles can create Python functions or procedures?
- Is a default artifact repository set at account, database or schema level?
- Is a packages policy in place? The docs state packages policies can set account-level allowlists and blocklists for Anaconda and PyPI packages.
Options if you want tighter control
- Revoke the role from PUBLIC and grant it to a named role used by the data platform team. Test first, because existing workflows may depend on it.
- Apply a packages policy with an allowlist of reviewed packages. A blocklist is weaker, since it only names what you already know is bad.
- Limit who can create functions at all.
- Keep function definitions in version control and scan their package lists.
Any of these changes can break jobs, so make them in a test account first and warn the teams that use Python functions.
What a policy cannot do
A policy limits which package names are allowed. It does not review the code inside an allowed package, and it does not update a function when a version has a flaw. Resolution happens when a function is created, so a vulnerable pinned version stays in place until the function is recreated.
Safeguard's SBOM and dependency scanning can check the package lists you keep in repositories against known advisories, which gives your allowlist a basis for review. The free scan at https://gold.safeguard.sh/scan is a quick way to try it.
Quick check
Does this mean everyone can run any PyPI package?
Per the docs, the role that enables the default PyPI repository is granted to PUBLIC by default, so broadly yes, unless you have changed grants or applied a packages policy.
Should I revoke the role right away?
Test first. Existing functions and pipelines may depend on it, so plan the change with the teams involved.
Sources
Last reviewed: 19 October 2026.
