Access control
Rules for who can open which apps and what they can do once they are signed in.
Definition
After you share an app with your team, you still need to decide who gets in and what they can do. That is access control: policies that grant or deny permissions per person, role, or app. Sign-in proves identity (company login / SSO). Access control uses that identity to limit apps, screens, or data sources. Without it, every signed-in person can see everything, which is rarely what you want for finance or client information.
Why it matters
Internal tools spread. The person who vibe-coded a margin model may need edit rights; the wider team may need view-only; contractors may need one app and nothing else. Access control makes private hosting usable at team scale. It also reduces the chance that an AI-generated app accidentally exposes a data source it should never touch.
How Croft fits
Croft is built so you share apps with named people and roles, not with the open web. Who can open which apps is the first question; the formal name for that pattern is often RBAC (role-based access). Apps and data sources start locked down; you grant access on purpose. Team plans add roles and permissions for admins, creators, and members. See Security, the roles docs, and the RBAC glossary entry.
Keep reading
FAQ
Frequently asked questions
What is access control?
The rules that decide who can open which apps and what they can do after they sign in.
How is access control different from SSO?
SSO (company login) proves who someone is. Access control decides what that person is allowed to use.
How do I share an app with only some of my team?
Invite those people and grant them access to that app. Keep everyone else without access. Croft supports that per-app model.
Stake out your croft.
Your team's first app could be live before lunch.
Get your croft7 days free, no card to start. From $24/month - cancel anytime and take everything with you.