Shadow AI? Give your team a place to build.
Apps can start anywhere in a company. A department has a problem, someone opens an AI agent, and a few days later there's an app for appointments, budgets or purchase requests. That's shadow IT, and AI makes it move faster than any rollout plan.
Trying to block it stifles good ideas. Pyrite gives teams a safe place to build and IT a single place to host the results and manage access, data and backups.
“People are already building. Give them a place to do it well.”
Pyrite for businessesFrom a team's idea to an app people use.
Follow five steps from idea to production and see what's already available in alpha 0.7.8.
A department has a problem.
The people who work there know it best. They might need one list of appointments, a way to sign off a budget or a workflow for approving purchase requests.
A standard to build on. Portable and open source.
We wrote a skill for AI agents. A team or consultant gives it to their preferred agent, which builds a standard PocketBase app with security rules and an app.json manifest declaring the app type, access and roles.
A compatible package.
The ZIP contains the manifest, pages and, for apps with data, hooks and migrations. It uses the usual PocketBase project folders. Live data and test accounts stay out of the package.
ZIP package for “Upload app”IT reviews and approves.
IT reviews the manifest and code and decides who gets access. An app uploaded by an Admin stays stopped until an Owner approves it.
available automated code checks: demonstration onlyThen you manage it alongside your other apps.
IT manages access, checks status and resource usage, makes backups and archives apps from the same console.
availableYou set the rules. The engine enforces them.
Manage access, roles and data for every department's apps in one place. The engine enforces the rules on every request to every app.
- 03.1Decide who gets in
- Grant access by app to people or groups in one directory. The engine checks every request, so revocations take effect immediately across all apps.
- 03.2Roles within each app
- Each app declares its roles from most to least privileged and defines a default role for first-time users. Server-side record rules determine what each role can see and edit.
- 03.3Four access levels
- Owner, People Admin, App Admin and User. Whoever manages sees only their own people or apps, and the apps an Admin uploads stay stopped until an Owner approves them. With units, one engine serves more customers and each sees only its own things. The console denies actions unless a rule explicitly permits them.
- 03.4Session controls
- Console keys live only in memory; a console session closes by itself after 30 minutes without use, never lasts more than 12 hours, and ends if the person is disabled or their access level changes. Two-factor authentication, with a code from the phone, can be added. Apps never receive the portal cookie.
- 03.5Centrally managed identities
- Names, email addresses and passwords come from the directory. Apps cannot create users, and users cannot change their own roles. The app token must belong to the person signed in.
- 03.6No hidden admin access
- Each app has a technical administrator account with a random password known only to the engine. The engine rejects administrative requests on app ports. Self-registration is disabled.
- 03.7An isolated environment for each app
- Each app has its own process, key and internal port. Scripts cannot start other programs. They can read only the app's folder, write only to its data and cannot modify the manifest. They cannot call the engine or another app. The fence is a defense inside the program, not a wall: apps of different customers on one engine are fine if whoever manages the engine writes or checks the scripts.
- 03.8Access reviews
- Review active users by day and app, each person's last activity and permissions unused for 30 days. The engine keeps its events in a history that nobody can delete from the console; by default it lasts one year.
- 03.9Recoverable data and verified archives
- Every restore first saves a copy of the current data. The engine removes an archived app's original files only after verifying the copy. Your data stays on your server.
For more detail, including the limits of what the engine checks, see security and operations.
Atomic updates. All or nothing.
Update an app by uploading a new package. The engine inspects the new version and tests it alongside the running one. It switches versions in one step only after all checks pass.
- 04.1Prepare the package
- Use the same ZIP layout as a first installation, with the manifest, pages, hooks and migrations. The person who built the app doesn't need access to the server.
- 04.2The engine inspects and tests it
- The engine checks the package and code, much like container image scanning. It tries the migrations on a copy of the data, starts the app in a test run and checks its health.
- 04.3Switch in one step
- If all checks pass, the engine backs up the app and switches versions. If anything goes wrong, the update stops and the previous version stays intact.
The engine follows the same principle for its own updates. Before each one, it saves a copy of its registry that it can restore.
On your servers. With nothing else to install.
Pyrite runs on Windows over the local network where small and midsize businesses already operate their servers. All it needs is an executable and a folder. People sign in with one account. Connecting the directory to Active Directory and Entra ID is the next step.