Security at TINIUN
Protections built into the platform, not bolted on.
Workforce data describes people's working lives. Here is how TINIUN keeps it separated, access-controlled and accountable.
Tenant isolation in the database
Every record belongs to one organization. Postgres row-level security enforces that boundary on every query the application makes, so a bug in a single screen can't expose another customer's data. The application connects with a restricted database role that can't switch these policies off; cross-organization access happens only on a few explicit system paths, such as sign-in and background jobs.
Authentication
Passwords are stored only as salted scrypt hashes. Sessions are server-side, stored as hashes, carried in HTTP-only secure cookies, and can be revoked at any time. Sign-in attempts are rate-limited, and state-changing requests require an anti-CSRF header.
Single sign-on
Organizations can sign in through their identity provider using SAML 2.0 or OpenID Connect (authorization code flow with PKCE).
Least-privilege access
Roles are scoped to the organization, a department, a team or the individual. A team leader sees their team; an agent sees their own data. Every API request is checked against those permissions on the server.
Tamper-evident history
Activity events, attendance corrections, schedule versions and audit logs are append-only: the database rejects edits and deletions. Administrative and sensitive actions are recorded with who, what, when and where.
Encryption
All traffic to TINIUN is served over HTTPS, and the application's connections to its database are encrypted with TLS. Stored data is encrypted at rest by our database provider.
Infrastructure
TINIUN runs on Vercel, with application data in a managed Supabase Postgres database in Singapore. Security headers are set on every response, and production secrets are kept out of source code.
Safe by default under load
Agent actions are idempotent and check the expected current state, so duplicate taps, retries and stale screens can't corrupt a timeline or create duplicate exceptions.
Report a vulnerability
If you believe you've found a security issue, email [email protected] with the details and steps to reproduce. Please give us reasonable time to fix it before sharing it publicly, and don't access data that isn't yours or degrade the service while testing. We'll acknowledge your report and keep you updated.
Privacy and data handling
What we collect, where it's stored, which providers process it and how long we keep it is covered in our Privacy Policy. For security questionnaires or a data processing agreement, contact [email protected].