Security Whitepaper

Huckleberry Signals — Security Overview

Product: Huckleberry Signals (Huck) — AI-powered data analytics for agriculture Last updated: July 4, 2026 Contact: [email protected]

Introduction

Huckleberry Signals provides an AI-powered data analytics platform that lets agricultural companies ask questions of their own data in plain language and receive trusted, governed answers. Because our customers entrust us with sensitive business data, security and privacy are foundational to how we build and operate the platform.

This document summarizes the security practices, controls, and infrastructure that protect customer data. It is intended for customers, prospects, and partners evaluating our platform.

For real-time compliance status, our subprocessor list, and access to security documentation (including our SOC 2 report under NDA), visit our Trust Center at trust.huckleberrysignals.ai. For other questions, contact [email protected].

Compliance and certifications

We are actively pursuing SOC 2 and have implemented a control framework mapped to the SOC 2 Trust Services Criteria (Security, Availability, and Confidentiality). Our controls cover access management, change management, vulnerability management, logging and monitoring, incident response, and periodic control review.

• SOC 2: In progress. Current audit status and the report (under NDA) are available through our Trust Center at trust.huckleberrysignals.ai.

• Control reviews: Security controls are reviewed on a documented monthly cadence, with findings and actions tracked in an internal review log.

Infrastructure and hosting

Our platform is built entirely on Google Cloud Platform (GCP), a provider with industry-leading physical and infrastructure security certifications (including ISO 27001, SOC 1/2/3, and PCI DSS). We do not operate our own data centers.

We use managed, fully-hosted Google Cloud services for compute, data storage, and application hosting. Compute runs in isolated, sandboxed environments with no persistent local state; all durable data lives in managed, access-controlled Google Cloud services that inherit Google's underlying security and compliance posture.

Data protection and encryption

• Encryption in transit: All connections are encrypted in transit over HTTPS/TLS. HTTP Strict Transport Security (HSTS) is enforced across our web application and APIs, and traffic is redirected to HTTPS.

• Encryption at rest: All customer data is encrypted at rest using Google-managed encryption keys (AES-256).

• Data minimization: We collect and process only the data required to deliver analytics and answer customer questions.

Multi-tenant isolation

The platform is multi-tenant by design, with strong logical separation between customers:

• Each customer's data is isolated at the infrastructure boundary, not merely by an application-level filter.

• Every request is bound to an authenticated tenant context; there is no anonymous access to tenant data.

• Cross-tenant access attempts are actively monitored and alerted on in real time, with automated escalation for anomalous patterns.

Identity, authentication, and access control

• Authentication: End-user authentication is handled by a managed, Google-backed identity provider. Sessions are represented by short-lived, signed tokens that are validated server-side on every request.

• Authorization: Access is role-based, and all customer data access is scoped to the authenticated tenant.

• Brute-force protection: The identity provider throttles repeated failed login attempts.

• Account lifecycle: Deactivated accounts are enforced server-side and access is revoked promptly.

• Least privilege: Internal roles and service identities are provisioned to the minimum permissions required and reviewed periodically. Human access to production systems is limited to authorized personnel.

Network and application security

• Edge protection: Production traffic is fronted by a web application firewall (WAF).

• Reduced exposure: Backend services are not exposed directly to the public internet; access is mediated through our protected edge.

• Rate limiting: Multiple layers of rate limiting protect the platform at both the network edge and the application layer.

• Browser security controls: Our web application enforces a Content-Security-Policy, strict transport security, and standard anti-clickjacking and content-type protections. These have been validated by third-party penetration testing.

Secrets management

All application secrets and credentials are stored in a managed, encrypted secrets service:

• Encrypted at rest with Google-managed keys.

• Access controlled by fine-grained, per-secret permissions.

• Every secret access is logged for audit.

• Secrets are never committed to source control.

• Credentials are rotated on a defined schedule and immediately upon any suspected compromise.

Vulnerability management

We maintain a documented vulnerability management program with continuous detection and defined response SLAs:

New CRITICAL and HIGH findings trigger real-time alerts. Remediation is prioritized by severity against defined service-level targets, and any accepted risk is formally documented with compensating controls and a scheduled re-review.

Secure development and change management

All changes follow a controlled software development lifecycle:

• Version control: All source code is managed in Git (GitHub).

• Peer review: Every change to production requires a pull request with at least one approving review. Direct pushes to the protected main branch are not permitted, and protections apply to administrators as well.

• Automated gates: Pull requests must pass automated tests, linting, static analysis, and a successful build before they can merge.

• Automated deployment: Deployments are fully automated through CI/CD; no one deploys by hand. Every production release is tagged in Git on the exact commit that shipped.

• Rollback: Post-deploy health checks run automatically, and failed deployments roll back to the last known-good version.

• Traceability: Every deployment is logged with its commit identifier and posts a notification to our internal channel.

Logging, monitoring, and audit

• Audit logging: Administrative activity and data-access events are captured through centralized logging. Administrative activity logs are retained long-term and are written by cloud infrastructure (not application code), so they cannot be tampered with by the application.

• Monitoring and alerting: Automated alert policies watch for security and availability signals — including new critical vulnerabilities and anomalous cross-tenant access — and route to on-call channels.

• Retention: Log retention meets or exceeds our compliance requirements, and incident records are retained for a minimum of three years.

Incident response

We maintain a documented incident response process with defined severity levels and escalation paths. Key elements include:

• Real-time detection and alerting on security-relevant events.

• Defined acknowledgment and remediation timelines by severity.

• Evidence preservation and export of relevant logs during any incident.

• Post-incident review, with each material incident converted into a permanent regression test or control improvement.

• Customer notification for incidents affecting customer data, consistent with contractual and regulatory obligations.

Availability and resilience

• The platform runs on managed, auto-scaling Google Cloud services that provide built-in redundancy.

• Customer data benefits from Google Cloud's durability and replication guarantees.

• Automated health checks and rollback reduce the risk of a bad deploy causing an outage.

Reporting a security concern

We welcome reports from customers and security researchers. To report a vulnerability or security concern, please email [email protected]. We aim to acknowledge reports promptly and will work with you on responsible disclosure.

This overview describes our security program as of the date above and is provided for informational purposes. It does not create contractual obligations. For our SOC 2 report, subprocessor list, and live compliance status, visit trust.huckleberrysignals.ai, or contact [email protected] for a security questionnaire response.