For IT and security
People are already building these. Give them a safe place to put them.
TeamOnly hosts internal tools built with AI, behind your company’s Google or Microsoft login. Login is enforced before any app code runs, every app is isolated from the others, and you can see every app and who owns it.
01Right now
What’s happening now
Someone in finance built an approval tool over a weekend. It works. It is also running on a personal account, it may be public, and the link is in a group chat.
- Personal accounts. Apps live on whatever platform the builder signed up for, billed to their card. When they leave, so does your visibility.
- Public by default. Many AI app builders publish to the open web unless you pay for, or find, the private option.
- Links in chat. Access control is “who has the link”.
This is not hypothetical. In May 2026, researchers at RedAccess reported finding thousands of publicly reachable apps built with AI tools that exposed company or personal data, many of them indexed by Google. (Security Boulevard’s report.)
A door marked Staff only stands in front of the expenses app. Sam, signed in as sam@acme.com, is checked at the door and walks in. Next, randomperson@gmail.com and a bot are checked at the same door and turned away. They never reach the app, because the check happens at the door, before the app.
02Enforced first
Login before any app code runs
Every request to every app goes through our dispatch layer first. It checks the session, and only signed-in people on your domain are passed through to the app.
The dispatch layer also removes any identity headers a request tries to fake, then adds the verified name and email itself. Apps can trust who is signed in, and a builder cannot switch login off.
No app is reachable without login. There is no public setting.
03Identity
Sign-in limited to your domains
Your identity provider is the one you already run: Google Workspace or Microsoft 365. Only accounts on your company domains get in.
Sign-in is verified on our server, including the domain claim. We don’t rely on the hd hint, which anyone can remove.
Only accounts from your organization’s tenant are accepted, not work accounts from any company.
Several domains, like acme.com and acme.co.uk? Add them all. Disable someone in your directory and they can no longer sign in to any app.
04Isolation
Every app in its own room
Customer code is treated as untrusted. Each app runs on its own, with access only to what was created for it.
A floor plan with three rooms: the expenses, inventory and lookup apps. Each room holds its own data, files and secrets. The expenses app tries to reach into the inventory room and hits the wall. The inventory app tries to reach into the lookup room and hits the wall too. Data, cookies and secrets stay in their own room.
- Data
- Its own database. No app holds credentials for another app’s database.
- Files
- Its own storage area, reached only through that app’s own binding.
- Cookies
- Session cookies are scoped to the app’s exact address, never to the shared parent domain.
- Secrets
- Stored outside the code and given only to the app they belong to.
05Inventory
One list: every app, its owner, who has access, last deploy
The dashboard lists every app in your organization, who built it, whether it is open to the whole company or a named list, and when it last changed.
Builders sign up with a card, so apps may appear before IT is involved. That is the point: when you are ready, IT takes over the organization, and everything is already in one place.
An app register for acme.com fills in row by row. expenses, owned by dana@acme.com, open to everyone at acme.com, last deployed today at 9:41. inventory, owned by marco@acme.com, open to 6 people, deployed yesterday. lookup, owned by priya@acme.com, open to priya, marco and 3 others, deployed October 21. requests, owned by lee@acme.com, open to everyone at acme.com, deployed October 18. Then marco@acme.com is offboarded and every line that gave him access is struck through.
06Offboarding
When someone leaves
Turn off their work account and they can no longer sign in to TeamOnly or to any app. The people who used their apps are not separate accounts, so there is nothing else to remove.
Their apps keep running for everyone else. Moving ownership of those apps to someone new is a Business plan feature, coming later. Until then, email us and we will do it.
07Scope
Internal apps only, by design
TeamOnly does not host public websites or customer-facing apps. There is no setting to make an app public, so nobody can do it by accident.
Every response from an app, including the sign-in screen, asks search engines not to index it.
08Business plan
On the Business plan (coming later)
For when IT takes over. None of this is available yet, and we will build it as companies ask for it.
- SAML SSOOkta, Entra ID and other SAML providers
- Audit logsWho deployed, changed access or opened what, and when
- Ownership transferHand an app to a new owner when someone leaves
- Data regionChoose where app data is stored
- InvoicingPay by invoice instead of card
Planned at $899 a month. See planned pricing.
09Policy
Why this beats a ban
People build these tools because they solve real problems. A ban doesn’t remove the problem. It moves the tool somewhere you can’t see.
Giving builders one approved place to deploy means the tools end up behind your login, with your domain rules, in a list you can read. You get to say yes, and still know what is running.
How do we find the AI-built apps people already made?
Start with your SSO or Google Workspace sign-in logs for builder platforms (Replit, Lovable, Vercel, Netlify), and expense reports for their subscriptions. Then ask, without blame. Once you know who the builders are, give them TeamOnly as the approved place to move those apps.
Do we need Okta?
No. Google Workspace or Microsoft 365 is your identity provider. Coworkers sign in with those accounts, and only your domains are allowed. SAML for Okta and similar is planned for the Business plan.
Can apps see each other’s data?
No. Each app has its own database, its own file storage and its own secrets. An app has no credentials for anything else, and its session cookie is scoped to its own address. Details are on the security page.
What happens when the builder leaves?
Their work account is turned off, so they can no longer sign in to TeamOnly or to any app. The apps keep running for everyone else. Transferring ownership to someone else is part of the Business plan, which is coming later; until then, email us and we will move it.
Do you support SAML?
Not yet. SAML SSO is planned for the Business plan, along with audit logs. Google Workspace and Microsoft 365 sign-in work on every plan.
For the security review
- Security detailsSign-in, isolation, cookies, secrets, and what we don’t do yet.
- Company-only loginWhat users and outsiders see, and the DIY pitfalls.
- Planned pricingBuilder, Team, and Business (coming later).
- All questionsIncluding data, billing and support.
- DocsCLI, SDK and the skill file builders use.
Early access
Get on the list.
We are new and not open yet. Join the waitlist with your work email, and tell your builders where to deploy when we open.
Want to tell us what you are building? Use the longer waitlist form. Questions go to hello@teamonly.dev, and a person answers.