Who should be able to open the app your agent built?

Your agent built a tracker for vendor renewals. You can open it on your laptop. Next week, the finance lead needs to check a contract, the account manager needs to update a date, and the rest of the company might want to look something up.

Before you send a link, there is one decision to make: who is meant to get in? “People with the link” sounds simple, but it leaves out whether they must sign in, whether the link can be forwarded, and what happens when someone leaves the project.

We make Spryloom, which runs apps built with coding agents for teams. Its access choices are the examples here. The same questions matter wherever you host the app.

Start with the smallest audience that can do the work

Ask who needs the app today. You can widen access later. A half-finished tool may need only its owner; a project tracker may need six named people; an office directory may genuinely need everyone at the company.

Only you: keep work in progress private

Spryloom starts a new app as private. The person who published it and any admins named in its manifest can open it. Other people cannot get in, even if you send them the address.

This is useful while you are still checking whether the app does the right thing. It also suits a tool you do not intend to share. “Private” does not mean a preview link for a teammate: Spryloom will refuse an invitation while the app is private. Change the app to invited when somebody else needs to use it, then send their invitation.

Named people: share a project app by invitation

Choose invited when you can name the people who should use the tool. They can be coworkers or people outside your company. Each person gets their own invitation, signs in with that address, and can return with an emailed sign-in link. Forwarding the app's address does not give someone else access.

This fits a vendor renewal tracker shared by finance and a few account managers, or a client approval tool with two people at the client. You can invite another person later or remove one when the work ends. The owner and admins remain able to manage the app.

Sometimes the right person finds the address before you invite them. On an invited app, Spryloom gives them a generic check-email response; it does not tell them whether the app or their address is valid. The owner and admins can see grouped sign-in attempts in the dashboard and choose Invite. Treat the address as something to check, not proof that the person who owns it asked for access: anyone can type an address into a form. Nothing is emailed to the owner for each attempt.

For the full invitation flow, see how to give a coworker access to one app.

Whole company: make a shared tool easy to find

Choose company when every person at your workspace's email domain should be able to open the app without an individual invitation. A staff directory or a company-wide request board may fit. People still sign in with their own email; merely knowing the URL is not enough.

This is a wider choice than it sounds. It includes a colleague you have never met who signs in with an address at that domain. Do not choose it for a project with a short list of participants just to avoid sending invitations. Spryloom requires a company workspace and its domain for this setting; a personal workspace uses named invitations instead.

What about “anyone with the link”?

Spryloom also has link access. Anyone who has the app's address can open it after signing in, while the app is listed only for its owner and admins. It can be handy when you cannot list every visitor in advance, but the address may be forwarded. Do not use it as a secret link for information that only named people should see. If the page is meant for the public internet without sign-in, use a public website host instead.

Access to the app is not access to every action

These settings decide who may reach the app. They do not, by themselves, decide who may approve a request, edit a record, or see a sensitive field inside it. Your app must apply those rules. Spryloom passes the signed-in person's email and role to the app so your agent can write them without building another login screen.

Before you publish, describe both decisions: “Finance and the account managers may open it; only finance may approve a renewal.” That is more useful than “make it secure.”

Start with a choice you can explain

If you are unsure, begin with private while you test, then change to invited and name the first real users. Use company only when the app's job is for the whole company. In Spryloom, the choice lives in spryloom.yaml:

access:
  visibility: invited

Publish after changing the manifest, then invite the people who need it. Open the app in a private browser window before sharing its address: the sign-in page should appear before any app content. The workspace and access guide has the full rules for all four settings.