Security

How we build and verify trustworthy software.

Security philosophy

We build verifiable computing infrastructure. Our security posture reflects that: minimize attack surface, maximize auditability, prove correctness where possible.

Zero dependencies

AIIR has zero runtime dependencies. No supply chain to compromise. The entire codebase is auditable in one sitting.

Content-addressed

Every receipt is identified by its SHA-256 hash. Change any field — receipt_id, timestamp, AI attestation — and the hash breaks.

Adversarial testing

We run structured adversarial rounds against every release: fuzzing, homoglyph injection, path traversal, TOCTOU attacks, and more.

Transparency logs

Sigstore integration provides keyless signing, Fulcio certificates, and Rekor transparency log entries. Non-repudiation without key management.

Threat modeling

AIIR ships with a public THREAT_MODEL.md that covers the full STRIDE/DREAD analysis:

STRIDE CategoryCoverage
SpoofingContent-addressed hashes + Sigstore identity binding
TamperingSHA-256 integrity + Rekor transparency log
RepudiationKeyless signing with Fulcio certificates
Information DisclosureReceipts contain only commit metadata (no source code)
Denial of ServiceZero network calls in default mode
Elevation of PrivilegeNo filesystem writes outside specified output dir

Each threat is scored using DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) with concrete mitigations and residual risk documented.

Adversarial testing program

Every AIIR release goes through structured adversarial rounds. These are not unit tests — they're attacks. Each round attempts to break a specific security property:

  • Receipt forgery — can an attacker produce a valid-looking receipt for a commit they didn't make?
  • Homoglyph evasion — can Cyrillic/Greek lookalikes bypass AI detection?
  • Path traversal — can --output escape the intended directory?
  • TOCTOU races — can git state change between read and receipt?
  • JSON injection — can commit messages inject fields into receipt JSON?
  • Large input handling — what happens with 10K-file commits or 1MB messages?
  • Signature stripping — can an attacker remove Sigstore signatures undetected?

Results from each round feed back into the test suite as regression tests. The test suite includes these adversarial scenarios alongside functional and fuzz tests.

Responsible disclosure

We welcome security reports. If you find a vulnerability, please report it responsibly. We do not have a bug bounty program yet, but we credit all reporters (with permission) and will work with you on coordinated disclosure.
ChannelDetails
Emailnoah@invariantsystems.io
security.txt/.well-known/security.txt (RFC 9116)
GitHub Security AdvisoriesReport via GitHub
Response timeAcknowledgment within 48 hours
Disclosure timeline90-day coordinated disclosure

See SECURITY.md in the AIIR repository for the full policy.

What we don't do

  • No telemetry. AIIR makes zero network calls in default mode. Plausible analytics on this website only (no cookies, GDPR compliant).
  • No source code collection. Receipts contain commit metadata and diff hashes, never source code.
  • No key management burden. Sigstore signing is keyless — uses OIDC identity from your CI provider.
  • No vendor lock-in. Receipts are plain JSON. Export, migrate, or self-host anytime.

Audit the code yourself

AIIR is Apache 2.0. The entire codebase is one pip install away.

View source → Threat model