Setting share=True in Gradio creates a public link that anyone with the URL can open, served through Gradio share servers that proxy to your local app. The app keeps running on your machine, so whatever your functions can do, visitors can trigger. Add authentication and keep sensitive actions out of the app.
What the docs say
The Gradio sharing guide describes share=True as creating a public, shareable link you can send to anybody. Processing continues on your own machine as long as your device stays on. The share servers are described as only a proxy for your local server that do not store any data sent through your app. Share links expire after one week. By default share is false, meaning the server runs only locally, and Google Colab creates share links automatically.
For sharing with specific people, the guide suggests SSH port forwarding as an alternative.
The security warnings in the guide
The page is plain about the exposure. Anyone can use your model for prediction, so do not expose sensitive information through the functions you write, and do not allow critical changes to your device.
It then explains the built in access control. You can pass the auth argument to launch() with a username and password tuple, a list of tuples, or a function that returns true or false. You can read request.username to tailor content per user, and OAuth options exist. The guide also says this built in authentication provides a basic layer of access control, and lacks features like multi factor authentication, rate limiting or lockout policies. A login button on its own does not restrict anyone from using the app.
Where this goes wrong in notebooks
A demo built in a notebook often shares the same process as the analyst's work. That process may hold database connections, cloud credentials in environment variables, and files on disk. A Gradio function that calls a database, reads a path the user types, or passes the visitor's text to a model with tools is now reachable from the internet.
Colab matters here because the guide says it creates share links automatically, so people can publish an app without choosing to.
Before you share, ask
| Question | Safer answer |
|---|---|
| What data can the functions read? | Only a sample dataset made for the demo |
| Can a visitor change anything? | No writes, deletes or sends |
| Which credentials are in the process? | None beyond what the demo needs |
| Is auth on? | Yes, and the link goes only to named people |
| How long should it live? | Shut it down after the review rather than waiting for expiry |
| Does the app pass visitor text to a model with tools? | Restrict the tools, or avoid it |
A safer pattern
Run demos in a clean container with sample data and no secrets. Use the auth argument, or port forwarding for a small group. Stop the process when the session ends. If the app is going to live longer than a demo, deploy it properly behind your identity provider instead of using a share link.
Where Safeguard fits
For apps that connect models to tools, Safeguard offers MCP Guardrail and policies and gates, and its dependency scanning inventories the Python packages involved. You can try a free scan.
Quick check
Does the share server store my data?
The Gradio guide says the share servers are only a proxy and do not store data sent through your app. Your own machine still processes everything.
Is the built in password enough for sensitive data?
The guide says it is basic and lacks features such as multi factor authentication and rate limiting. Do not use it as the only protection for sensitive data.
Sources
Last reviewed: 19 October 2026.
