Security Practices

Accounts are authenticated with email and password or Google sign-in. Sessions use short-lived signed access tokens with refresh rotation. Anonymous sign-ups are disabled, and every request to the application's server functions is verified against the identity provider rather than trusting a client-supplied token.

Row-level security is enabled on every application table. Policies scope each record to the authenticated owner, so one customer cannot read or modify another customer's growers, farms, fields, lab results, assessments or recommendations.

Elevated access is granted only through a dedicated roles table, never a flag on a user profile, and is evaluated by a security-definer function in a private schema that is not callable from the client. The lead agronomist's administrator role grants read access for case review and the ability to record a professional correction; it does not permit silent edits to customer-entered data.

• All traffic is served over HTTPS/TLS.
• Data is encrypted at rest by the managed database platform.
• Uploaded lab report files are stored in access-controlled buckets tied to the owning account.
• Server credentials are held as server-side secrets and are never exposed to the browser bundle.
• Backups and point-in-time recovery are handled by the managed infrastructure provider.

Lab values entered manually, imported from CSV/XLSX, or extracted from PDF reports are schema-validated before they reach the database. Implausible values (for example salinity reported in the wrong unit) are flagged by the data-quality layer rather than silently used, and agronomic validity is recorded as verified or self-entered so every finding can be traced to its source.

The Agronomic Advisor is interpretive only. It receives the field context needed to explain a determination and cannot write to your records or alter a recommendation. The agronomic engine — not the model — produces every determination, and each answer cites the field data it relied on.

The application is scanned for security findings on an ongoing basis, including database policy gaps, privilege escalation paths and dependency vulnerabilities. Findings are triaged and remediated, and accepted risks are documented.

If you believe you have found a security issue, email John.Olivas@BioSci.com with steps to reproduce. Please do not publicly disclose the issue until it has been addressed. We aim to acknowledge reports within three business days.