Your data is protected by design, not by policy

Every database query in Livestork is scoped to the requesting organisation. There is no global query that could accidentally return another organisation's records.

Tenant resolution happens at the middleware layer before any controller logic executes. The organisation context is injected and cannot be overridden by request parameters.

Cross-tenant data access is architecturally impossible, not just blocked by permission checks, but structurally absent from the system's data access patterns.

Livestork's permission system operates at the module and action level. Each capability (view, create, update, delete) is individually assignable.

Roles can be customised per organisation. Farm managers, finance staff, store keepers, and executive viewers each see only what they need.

Permission checks happen server-side on every request; the frontend visibility state can't be manipulated to bypass API-level access controls.

Every significant write operation is logged: who made the change, when, from what device, and what the data looked like before and after.

Audit logs are append-only. Records cannot be edited or deleted through the application. Deletion of a log record requires direct database access, which is restricted to system administrators.

The audit trail is queryable by date range, user, resource type, and action. Compliance reviews can be self-served without requiring engineering involvement.

All communication between client browsers and the Livestork API is encrypted using TLS 1.2 or higher. Plain-text HTTP connections are rejected.

API tokens are transmitted in Authorization headers, not query parameters, preventing accidental logging of credentials.

Tokens have configurable expiry. A compromised token has a bounded window of validity.

Each organisation's operational data is logically isolated within the database. Shared infrastructure does not mean shared data.

Database backups capture per-organisation state. Point-in-time recovery can restore a specific organisation's data without affecting others.

Sensitive fields (passwords, tokens) are hashed using bcrypt with appropriate work factors. Plaintext credentials are never stored.

Authentication uses token-based sessions rather than long-lived cookies. Tokens are invalidated on logout.

Password requirements are enforced server-side. Weak passwords cannot be accepted by manipulating client-side validation.

Failed login attempts are rate-limited to prevent credential stuffing attacks. Account lockout policies are configurable.

Database backups run on a scheduled cadence. Backup files are encrypted at rest.

Retention policy preserves multiple historical snapshots, not just the most recent backup.

Backup restoration is tested periodically to verify that recovery procedures work as expected, not just that backup files exist.

Livestork's target architecture includes redundant application and database tiers deployed across multiple availability zones.

Load balancing and auto-scaling ensure that traffic spikes during peak periods (harvest, reporting cycles) do not degrade performance.

Health monitoring and automated failover reduce the impact of component failures below perceptible thresholds.