Security you can read.
How Ngenaire protects program data, written by the engineers who built it: what each control does, how it is implemented, and what we do not claim.
Found a vulnerability? security@ngenaire.com
- 1Request contextRequest id and client address for every log line
- 2Security headersCSP, HSTS, frame denial, no-store
- 3Body limitsSize caps enforced while streaming
- 4AuthenticationSession cookie or bearer access token
- 5CSRF defenceOrigin check and session-bound token
- 6Token scopeRead-only tokens can never write
- 7Auth gateClosed unless a route is explicitly public
- 8Access lockAccount and plan state
- 9ThrottlePer-user request ceiling
Sign-in and identity
Passwords are hard to steal and slow to guess, a passkey can be required as a second step, and repeated guessing is stopped twice over.
argon2id password hashing
Passwords are hashed with argon2id at the OWASP baseline and must be at least 10 characters. An unknown email still costs one full verification, so response time does not reveal whether an account exists.
argon2id, m = 19 MiB, t = 2, p = 1
Passkeys as a second step
Add a WebAuthn passkey (Touch ID, Windows Hello or a hardware key) and every sign-in, including Google sign-in, must also complete the passkey challenge. Ten single-use recovery codes are shown once and stored only as hashes.
WebAuthn, 10 recovery codes, SHA-256 at rest
Lockout and rate limits
Ten failed passwords lock an account for 15 minutes. Separate limits apply per account, per address, per second-factor challenge, and to sign-up, password reset and verification email. Counters live in the database, so they hold across every server.
10 failures / 15 min per account, 30 attempts / 15 min per address, 5 second-factor tries / 15 min
Single-use email links
Verification and password-reset links are random, single-use, expiring and stored hashed. Asking for a reset never reveals whether the address has an account, and completing one signs out every existing session.
256-bit tokens, SHA-256 at rest
Sessions
Browser sessions are opaque, server-side and revocable. Nothing that could act as you is readable by page scripts.
HttpOnly session cookie
A 256-bit random token in an HttpOnly, SameSite=Lax cookie, Secure and __Host- prefixed in production. The database stores only its SHA-256 hash, so a database read alone cannot hijack a session.
__Host-ngn_session, HttpOnly, Secure, SameSite=Lax
Idle and absolute expiry
Sessions expire after 7 idle days and 30 days in total. Deactivated accounts lose access on their next request.
idle 7 d, absolute 30 d
You can see and end every session
Security & sign-in lists each device with its last activity. Sign one out, or all the others at once. Changing your password signs out every other session automatically.
Security activity
Sign-ins, failed attempts, password changes, passkeys, recovery codes and access tokens appear in your own security activity log.
Request integrity
Every API request passes the same pipeline before it reaches a feature. Cross-site forgery, framing and script injection are closed at the edge.
Layered CSRF defence
The session cookie is SameSite=Lax; any state-changing request from a browser origin other than ours is rejected; and cookie-authenticated writes must echo a token bound to the session with an HMAC. Bearer-token requests carry no ambient credentials and need none of this.
Origin check, Sec-Fetch-Site, HMAC-SHA256(session)
Strict Content Security Policy
No inline scripts and no eval. Third-party code is limited to what payments and Google sign-in require, the app cannot be framed, and plugins are disabled.
script-src 'self' js.stripe.com accounts.google.com; frame-ancestors 'none'; object-src 'none'
Hardened headers
HSTS with preload in production, nosniff, frame denial, a strict referrer policy, a permissions policy that disables camera, microphone and location, cross-origin isolation of resources, and no-store on every API response.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Size limits and throttling
Request bodies are capped while they stream, not just by their declared length: 2 MB for JSON and a configurable cap for uploads. A per-user ceiling stops runaway scripts and scraping.
JSON 2 MB, uploads 50 MB by default
Approvals, baselines and audit
Configuration management you can defend in a review: who approved what, in which role, and exactly what they approved.
Signed approvals
Approving a requirement, an engineering change-request stage or a baseline records the approver, the time and the role they held, with a signature computed over a canonical form of the content. Approved and signed artifacts are marked in gold throughout the product.
canonical JSON, versioned signature scheme
Immutable baselines
A baseline is a frozen snapshot of requirements and their trace links. Each captured item carries a content hash, and approved baselines cannot be edited; later changes go through change requests.
per-item SHA-256 content hash
Audit trail
Security and governance actions are appended to an audit log with the actor, address and user agent: sign-ins, second-factor changes, membership and role changes, approvals, project lifecycle and access tokens. Owners and admins review it as the governance log. Secrets are never written to it.
auth.*, org.*, project.* actions
Access tokens and MCP
Scripts and MCP clients such as Claude Code, Claude Desktop and Cursor authenticate with personal access tokens that are narrow, short-lived and easy to revoke.
Scoped, expiring tokens
Tokens are read-only or read-write and expire after 7, 30, 90 or 365 days. A read token is refused on every write, on every route, whatever your role allows.
ngn_pat_ prefix, read | write, 7–365 d
Shown once, stored hashed
The token is displayed once at creation and stored only as a SHA-256 hash. Each token records when it was last used, and revoking it takes effect on the next request.
256-bit random, SHA-256 at rest
AI and your data
The co-engineer is useful because it reads your project. Here is exactly when that happens.
Only when you ask
Project content is sent to our AI provider, Anthropic, only when you use an AI feature, and only what that request needs. We never use your content to train models.
Metered to the person who acts
Every AI action debits the credits of the person who ran it and is itemized with its project and feature, so usage is always attributable.
People sign, not models
The co-engineer drafts, critiques and proposes. Approvals, baselines and signatures always require a person with the right role.
Optional external services
Where web search is enabled, the co-engineer can search the public web. PlantUML diagrams are rendered by a PlantUML server, which receives the diagram source; Mermaid diagrams render in your browser.
Data handling
Plain statements about transport, portability and the limits of what we claim.
Encrypted in transit
Production traffic is served over TLS only, with HSTS so browsers never fall back to plain HTTP.
Yours to take with you
Export requirements as CSV, ReqIF or DOCX and reports in standard formats at any time. Ask privacy@ngenaire.com for a complete export or for deletion of your data.
What we do not claim
Ngenaire holds no SOC 2, ISO 27001 or similar certification today, and it is not suitable for ITAR or EAR controlled technical data or for classified information. Keep that material out of your workspace.
Report a vulnerability
Email security@ngenaire.com with the steps to reproduce and the impact you observed. Please give us a reasonable chance to fix the issue before disclosing it, and do not access, modify or delete other people’s data while testing. Privacy requests go to privacy@ngenaire.com.
Related: Privacy policy, Passkeys and account security, Roles and permissions.