Your AI-Built Demo Is Online. Who Gets Access?

cloudflared tunnel --url http://localhost:3000

The command gives you a public URL. Your app keeps running on your computer; your colleague reaches it through that link.

That is convenient for reviewing a layout or trying a button. It also means an app you were testing locally now has an entrance from the internet.

## A public URL needs access rules

Two separate questions matter here. **Authentication** checks who someone is. **Authorization** determines which data and actions that person can access.

Creating a Quick Tunnel does not automatically give your app either. If the app has no login or permission checks, someone reaching it through the public URL may get the same screens and functions you do.

Imagine a customer-management demo with three fictional customers on screen and an “Export all customers” button. If that button connects to real customer records, the harmless-looking demo can expose far more than three made-up names.

Reviewing the screen is only part of the job. The API endpoints behind it—the routes that retrieve or change data—need permission checks too.

**HTTPS** encrypts traffic. It does not decide whether the person requesting a customer list should receive it. That decision belongs in the app or a separate access-control layer.

## Give the agent a sharing policy

A coding agent with permission to execute commands can start the app and connect the tunnel. Your instructions need to define the conditions for sharing.

“Give me a link my colleague can open” leaves several decisions unresolved: who should get access, which data the demo should use, and whether visitors should be able to change anything.

A more useful request would be:

> Prepare a demo using only fictional data. Allow viewing, and reject requests that modify or delete data. Check the screens and functions available through the public URL.

If access should be restricted to particular people, specify that requirement as well.

The distinction between hiding an edit button and blocking an edit request matters. A hidden button changes the interface. If the server still accepts the request, the underlying data can still change.

Clear instructions do not guarantee a secure implementation. They give you concrete behavior to verify.

## Test access, then close the tunnel

A working link proves that the connection works. You still need to check whether visitors get only the access you intended.

For an app that requires login, start with a fresh browser session that is not signed in. Check the data endpoints and administrative functions as well as the landing page. Then verify that an authorized user cannot retrieve another user’s data.

When the demo ends, stop the tunnel. That closes this route into the app, but it cannot retrieve data someone has already downloaded. Connecting only the data the demo needs makes that boundary easier to manage.

Quick Tunnels removes much of the friction from showing someone a local app. When you ask an agent to create the link, include who may enter, what they may see, and what they may do—the URL alone answers none of those questions.