Found something? Tell us.

We're a small, founder-led company — one operator, no security team. If you've found something that could harm our users, our drivers, the integrity of our audit chain, or the regulatory data we publish, we want to hear about it. We read every report, fix what we can quickly, and credit you publicly if you'd like that.

Email: zackary@haulguard.ai
Please put [security] in the subject line so it doesn't get triaged with general inbound.
Or use the form: haulguard.ai/contact
Languages: English
Policy in force until: May 22, 2027

Our commitments to you

Safe harbor. We will not pursue legal action against good-faith researchers who follow this policy.
We'll actually read it. Reports go straight to the founder, not into a ticket queue nobody watches.
Credit where you want it. There's no formal bounty program yet, but we're glad to provide public acknowledgment, swag, and a recommendation letter where that's useful to you.

What we ask of you

Give us a window before going public. Ninety days is the standard floor.
For audit-chain issues, reach out before posting. The integrity of that chain is a claim our customers rely on in inspections — please give us the chance to fix it first.
Don't access data that isn't yours. If a proof of concept would require real driver data, describe the path instead and we'll reproduce it ourselves.

What we care about most

In rough priority order — these are the findings we'd drop everything for.

Audit-chain integrity. Anything that lets an attacker silently modify, insert, or delete events in the evidence ledger, or forge the SHA-256 hash chain.
Driver-data leakage. Any path that exposes CDL fields, scan payloads, or per-tester data across ownership boundaries.
Authentication bypass. Admin credential compromise, session-cookie forgery, geo-block evasion (we are US-only beta), or IDOR on scan endpoints.
Public verifier bypass. The verifier re-computes SHA-256 verification client-side; any way to make a tampered chain render as valid is a critical bug.
SSRF or credential leakage. Our API keys and service credentials live in environment variables only — please report any path that puts them in an attacker's hands.

Out of scope

Please don't spend your time on these — we already know, or they're not ours to fix.

Missing security headers on the public marketing pages. We know; the API surface is locked down separately.
Self-XSS that requires the attacker to type into their own console.
Denial of service via legitimate rate-limit exhaustion.
Third-party services we depend on — Microsoft Azure, Anthropic, Stripe, Google Workspace, among others. Please report those directly to them.

Thanks for taking the time. — Zack Foster, Founder

Machine-readable version. This policy is also published as security.txt, the plain-text format defined by RFC 9116 that automated scanners and researcher tooling look for. That file is deliberately unstyled — the spec requires plain text — and this page is its human-readable equivalent. If the two ever disagree, security.txt is canonical.