Built to be trusted with your instructions.
Your prompts, agents, and skills are the working knowledge of your team. Rubrkit treats them that way: single sign-on with no passwords to store, server-only data and secrets, scoped and revocable API keys, and AI runs that keep your content out of logs. Here is how that works — and how to report anything that looks wrong.
Sign in, no passwords to leak
Authenticate with Google or GitHub. Rubrkit never stores a password, so there is no password to leak or breach.
Identity tokens are verified server-side before any access, behind a narrow auth boundary that maps each provider account to your Rubrkit user.
A provider identity only links to an existing account when its email is verified — an unverified sign-in cannot attach itself to your account.
Your instructions stay yours
Artifacts, versions, audits, and proof reports are kept in a single source of truth, with uploaded files held in dedicated, access-controlled storage.
All data access is server-side only. The browser talks to scoped, authenticated endpoints, never directly to your stored data.
Ownership is enforced on every read and write — your bundles, history, and reports are scoped to your account.
API keys built to be revoked
Keys are created from your dashboard and shown once. We store only a hash, a short prefix, the owner, scopes, and timestamps — never the raw key.
Each key carries its own scopes and rate limits, and you can revoke any key at any time.
The same authorization and credit checks apply whether a request comes from the web app, the REST API, or the MCP server.
Careful AI handling
Model-provider credentials are server-only and never reach the browser.
Your artifacts and raw model responses are kept out of logs unless explicitly and safely redacted for debugging.
Every run passes authorization, credit, and limit checks first, and a global circuit breaker pauses AI work gracefully instead of failing silently.
Security is part of the build, not a bolt-on.
The same discipline Rubrkit applies to instructions, it applies to itself: review the surface, verify the change, and fix what the review finds.
Backend code is covered by tests as part of the same work that changes it, so security-relevant logic does not ship unverified.
We run security reviews of the server surface and remediate what they find — the most recent review’s findings were all fixed before release.
Rate limits use a server-derived client identity rather than client-controlled headers, and production links are HTTPS-only.
Secrets stay in server-side configuration; the identity provider sits behind a replaceable boundary so it never leaks into product authorization.
We describe what Rubrkit actually does today. We do not claim certifications or audits we have not completed; as the product matures this page will say so plainly.
Found something? Tell us.
If you believe you have found a security issue, report it privately so we can fix it before it is public. We will acknowledge your report and keep you updated through remediation.
Report to
security@rubrkit.comPlease give us a reasonable window to remediate before any public disclosure, and avoid testing that degrades the service or accesses data that is not yours. Prefer a form? Use the contact page and pick a security topic.