Passwords. PBKDF2-SHA256, 16-byte random salt, 32-byte key, 210,000 iterations by default (minimum 100,000 in staging and production). Verification uses a fixed-time comparison. Policy: at least 12 characters with upper case, lower case and a digit.

Tokens. HS256 JWTs signed with BALLAST_SECRET_KEY (at least 32 characters, enforced at startup). Each token carries a typ claim, so a refresh token cannot be used as an access token or the reverse. Validation checks the algorithm (so alg: none is rejected), compares signatures in fixed time and checks expiry. All of this is covered by tests, including a tampered payload, a token signed with a different secret, and an expired token.

Sign-in. Failed sign-ins return the same message whether or not the account exists, and a dummy hash is verified for unknown accounts to reduce timing differences. Five failures from one client address lock that client out of that account for five minutes, so a stranger guessing a victim's email only locks out their own address. A much higher ceiling (25 failures across all clients) stops a distributed guessing run. Failure counts decay after 15 quiet minutes and the tracker is capped at 10,000 entries (expired entries are swept first, active locks are evicted last), so it cannot be grown without bound. Auth endpoints are rate limited per client IP (30 per minute by default). Forwarded headers are honored only from the networks in BALLAST_TRUSTED_PROXIES (loopback and private ranges by default), so a client that reaches the API directly cannot choose its own IP.

Authorization. Role policies on endpoints, plus business rules in the workflow: a payment creator cannot approve it, an approver cannot approve twice, the releaser must not be an approver, and larger or flagged payments need two distinct approvers. These rules are unit tested and exercised through the API.

Registration. Open in development. Outside development the first account becomes Admin and after that only an Admin can create users.

Payments and balances. Creating a payment is one atomic step under a lock: duplicate check, id allocation, insert, audit entry and snapshot, so simultaneous identical requests cannot both pass the duplicate check and the audit order matches the order of state changes (a regression test races eight threads over forty rounds). Release is checked against the account balance net of payments already released through the system (releasedAt), so several approved payments cannot together overdraw it.

Audit. Authentication, payment, hedge, netting and role events are appended to a SHA-256 hash chain. Editing or deleting an entry makes GET /api/v1/audit/verify fail (tested).

Transport and browser hardening. X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Cache-Control: no-store on API responses, restricted CORS origins, and a Content-Security-Policy in the nginx image. Terminate TLS at the ingress or load balancer and add HSTS there.

Model service boundary. The Python service validates every request with typed schemas (bounds on sizes and ranges) and returns errors in the platform's {code, message} shape without leaking exceptions. It binds to 127.0.0.1 by default and the Kubernetes network policy admits only the backend. It does not authenticate callers (see the gaps below).

Fail-closed configuration. The API refuses to start with a weak secret, with demo seeding plus the public demo password in a production-like environment, or with low PBKDF2 iterations in one. A bug found during testing (production-like settings built directly still seeded demo users) led to the environment-derived defaults now in place.

Mobile. Tokens are stored in the platform keystore through SecureStorage, Android backup is disabled, and cleartext HTTP is permitted only for the emulator host and localhost (this part of the host is unverified, see its README).

Open a private security advisory on the repository rather than a public issue.