Trust & Security

Last updated: March 2026

HAIEC is a tool that helps your organisation demonstrate AI governance. This page explains how we handle data, what infrastructure we use, and where our own security posture stands — honestly.

The most important thing to know

HAIEC does not require access to your production data, user data, or sensitive business data to perform analysis. Our static scanner reads source code structure and configuration. Our runtime engine sends pre-defined, safe attack simulations to your test endpoints. Analysis results — findings, scores, and evidence hashes — are what we store. Not your source code, not your users' data.

1. Data Handling

What we store

Scan metadata: scan ID, repository URL, branch, status, finding counts, timestamps.
Finding records: file path, line range, rule ID, severity, description. No source code content.
Evidence hashes: SHA-256 content hashes for tamper detection. Not the underlying content.
Assessment responses: your answers to compliance wizard questions, stored per your account.
Account data: name, email, organisation name, subscription tier.
NYC LL144 candidate identifiers: hashed using SHA-256 before storage. Raw PII is not retained.

What we do not store

Source code content is not retained after scan completion. Changed file contents are fetched via GitHub API for PR scans, analyzed, and not persisted as raw source.
GitHub App fetches changed file contents for PR security scans. Repository governance signals use metadata-only API calls.
Runtime test target responses beyond pass/fail outcome and extracted finding context.
Payment card data. Payments processed entirely by Stripe (PCI DSS Level 1).

Do we process PII?

For most customers: no. The platform operates on code structure and configuration. For NYC LL144 bias audit customers, candidate identifiers are processed but are hashed before any storage. We do not retain raw candidate PII.

Is analysis transient?

Yes. The scan engine processes your repository in an ephemeral Modal container. The container is torn down after the scan completes. Only the structured finding output is returned and persisted — not the code that was analysed.

Data retention

Scan results: retained until you delete them or your account is closed.
Assessment data: retained until you delete the assessment.
Account data: deleted within 30 days of account closure on request.
Audit logs: retained for 7 years per compliance record-keeping norms.

2. Deployment Options

HAIEC operates in two distinct deployment models. It is important to understand which components run where.

HAIEC SaaS Platform (current, cloud-hosted)

Hosted on Vercel + Neon + Modal. US region. Includes the dashboard, compliance wizard, evidence vault, badge generation, and API. The Kill Switch SDK (@haiec/kill-switch) is an npm package that integrates into your application but connects to the HAIEC cloud for compliance monitoring and audit trail. No setup required beyond npm install.

Local Verification Engines (current, open source)

Two open-source npm packages run entirely on your machine — no cloud connection, no telemetry, no network requests during scanning:

mcp-tenant-isolation — 57 deterministic rules for cross-tenant data leakage detection. Runs as an MCP server (stdio transport). Path boundary enforced. Provenance-signed.
ai-appsec — 122 detectors across 79 security checks for AI application source code. Semgrep engine. Runs as an MCP server (stdio transport). Deterministic findings with evidence receipts.

These are independent engines. They do not require a HAIEC account. They do not send results to HAIEC. They are MIT licensed.

Self-hosted HAIEC Platform (future roadmap, not available)

A fully self-hosted HAIEC platform — including the dashboard, evidence vault, and compliance monitoring — is on our roadmap. It is not available today. We will not advertise it until it is built and qualified. If you require on-premises deployment of the full platform, contact us.

Offline Kill Switch (not available)

The current Kill Switch SDK (@haiec/kill-switch) connects to the HAIEC cloud for compliance monitoring and audit trail. A fully offline Kill Switch — one that operates without any cloud connection — has not been built or qualified. We do not advertise offline Kill Switch capability.

3. Infrastructure

We leverage SOC 2–compliant infrastructure providers. HAIEC itself has not yet completed a SOC 2 Type II audit. We are working toward this.

Provider	Role	Certification
Vercel	Application hosting & edge network	SOC 2 Type II
Neon	PostgreSQL database (serverless)	SOC 2 Type II
Modal	Scan execution compute (ephemeral containers)	SOC 2 Type II
Stripe	Payment processing	PCI DSS Level 1
Resend	Transactional email	SOC 2 Type II
GitHub	Source integration & App platform	SOC 2 Type II
Sentry	Error monitoring	SOC 2 Type II
Upstash	Redis — rate limiting & caching	SOC 2 Type II

Full list with data processing details: Subprocessor List

4. Access & Security Controls

Encryption

In transit: TLS 1.2+ enforced on all connections
At rest: AES-256 (Neon database)
Evidence integrity: SHA-256 content hashing
HTTPS-only; HTTP requests redirected

Access control

OAuth 2.0 via GitHub / Google (NextAuth)
All DB queries scoped to authenticated user ID
API keys: HMAC-signed, rotatable, audit-logged
GitHub App: installation-scoped, minimum permissions
Tenant isolation enforced at query level

Logging

Every scan logged with user ID, repo, branch, timestamps
Evidence records include collection timestamp and rule version
All API key authentications logged
Webhook deliveries logged with delivery ID and outcome
Error monitoring via Sentry

Hardening

Zod schema validation on all API inputs
Parameterised queries via Prisma ORM (no raw SQL)
CSRF protection on all form submissions
Content Security Policy headers via middleware
Rate limiting: Redis-backed, fail-open (availability over security)

5. Our Certification Posture (Honest)

SOC 2 Type II: Not yet completed. Our infrastructure providers are SOC 2 Type II certified. We are building toward our own audit. We will not claim SOC 2 certification until an independent auditor issues the report.

ISO 27001: Not certified. Controls are designed with ISO 27001 principles in mind.

GDPR: We maintain data processing records (Article 30), support deletion requests, and our architecture minimises personal data collection. We are not claiming GDPR "certification" (no such certification exists) — we are describing design alignment.

Penetration testing: Not yet completed by a third-party firm. Customers requiring a penetration test report should contact us.