Clear about the controls. Clear about the gaps.
A factual view of the current Jirify Builder implementation. This is not a security audit, compliance certification or guarantee of production readiness.
No privileged key in the browser. Generation stays disconnected.
Implemented in the application.
The browser uses a client-safe publishable key, never a privileged service key. Email sign-in and confirmation checks protect creation actions in the UI. Requests use the authenticated session.
- A single account provider drives the visitor and builder experience.
- Post-auth redirects are restricted to the builder.
- Workspace-scoped queries and current-user created_by fields are implemented.
Database access rules are the authority.
Project and workspace requests go through the existing database under row-level security. Effective membership, insert and read policies must be checked against the live configuration by the owner. Browser filters are not a replacement for RLS.
- Unverified here: actual production RLS and tenant isolation.
- Unverified here: full signup → confirmation → creation with a real account.
- No claim of a complete RBAC policy audit.
What still requires verification.
A production security assessment, monitoring review, retention policy, operational recovery plan and legal review remain pending. No SOC 2, ISO or GDPR certification is claimed.
- Owner action: allowlist the exact email verification callback URLs.
- Owner action: rotate any previously exposed privileged key.
- Not enabled: connected AI, app deployment, MCP and payments.
Give it somewhere to begin.
Your next project starts with a few words.
Start BuildingProject setup available. Generation on the roadmap.