Would ansible meet some or all of your needs?

Unfortunately, only LDAP is currently supported. There is no implementation of Enterprise SSO like Oauth/SAML. It's planned for the future, but not in priority for now.

I have never tested Cinnamon, but it should work in theory, because it stores most of it's settings in dconf.

Custom scripts: deliberately not, so far. Once a management agent runs arbitrary scripts as root, it stops being a policy system and becomes remote-code-execution-as-a-service — the security review, the audit story, and the "what exactly is enforced on this machine?" It may be implemented in the future, but with a ENV variable/config property from the application configuration. The same goes for configuration management systems like Ansible.

Thank you for the interest! I'm interested in developing a community around the software.

I would hope that it locks some of these policies. No user should be able to make changes to policies set by the administrator

Delivery is push, not pull. Each agent holds a persistent gRPC stream to the server (mTLS). Policy changes are broadcast over that stream the moment they're released — agents apply them in real time. If the connection drops, the agent reconnects with backoff and sends its last-known revision; the server replays exactly what it missed (or a full snapshot). So there's no "check every N minutes" anywhere in the design. Most user changes never stick in the first place. Where the desktop stack has a native lockdown mechanism, Bor uses it: dconf keys are written together with a dconf locks file, so a locked setting simply can't be changed from GNOME's UI; KDE settings are written with the Kiosk [$i] immutability marker, which KDE itself enforces; and everything else (Firefox/Chrome/Edge policies.json, polkit rules, firewalld zones) lives in root-owned files under /etc that an unprivileged user can't touch. Those applications treat managed policy as non-overridable by design. Root-level drift is caught by inotify, not a timer. For every file it manages, the agent watches the parent directory via inotify (parent dir, so atomically-renamed replacements are caught too). If anything external modifies or deletes a managed file — a curious admin with sudo, a config-management tool, a package postinstall script — the watcher fires immediately and the agent rewrites the file from its cached policy state and re-reports compliance to the server. In practice the revert happens within milliseconds of the write, and the tamper event is visible server-side, so drift isn't just corrected — it's auditable. (The agent suppresses events from its own writes, so it doesn't fight itself.)