An honest, point-by-point account of what AIF does today, what is in active development, and what falls outside the product's scope. Every live claim is backed by running, tested code — and adversarially verified.
Every audit row is canonicalised, SHA-256-hashed (with the previous row's hash chained in), and Ed25519-signed by the capability's key, with the deployment root's signature over that public key embedded inline. Each row is self-contained: any auditor with the root public key can verify it. Implemented in src/trust/attestation.ts and exercised by 1,341 vitest tests.
The W3C DID document at /.well-known/did.json publishes the deployment root public key. Anyone can fetch it, recompute every hash, and verify every signature. No access to our servers required. No trust in Predict AI required. The maths is the contract.
Set OPENAI_BASE_URL (or the equivalent) to point at the AIF spine, and OPENAI_API_KEY to the spine’s own token — the real provider key never leaves your secret backend. LangChain, CrewAI, AutoGen, custom code — anything that calls an LLM works as-is. The spine intercepts, governs, audits, and forwards. src/cockpit/proxy.ts.
One Docker Compose deployment (AIF spine + OpenBao vault). Runs on any Linux host — European cloud, on-premises, air-gapped. Reference deployment runs on Hetzner Frankfurt. No outbound calls beyond the LLM provider and optional anchoring.
OpenBao (HashiCorp Vault-compatible). Vault tokens live in Docker secrets mounted on tmpfs — they vanish on reboot by design. Zero secrets on disk in plaintext. The pluggable backend supports env, file, and vault modes.
The spine validates JWTs from Azure AD, Okta, Keycloak, or any standard OIDC provider against the IdP's JWKS endpoint, and puts the subject it reads on every audit entry that call writes. One configurable claim identifies the caller (sub by default, appid or any other claim if you say so); the remaining claims are carried into the audit context. We don't build identity. We read the identity your IdP already issues. Honest limits: the token authenticates the caller of /proxy/* and nothing else. There is no role or scope model, and no mapping from an IdP identity to a registered agent's W3C DID. The DIDs the spine issues are its own deployment and capability keys.
The ApprovalGate blocks any capability flagged requiresApproval until a configured set of approvers explicitly authorises it — on every path into the pipeline, streaming included: a streamed request to such a capability ends on a terminal approval-required event before the model provider is contacted, so no output is generated. Each request is bound to an actionHash — SHA-256 over the canonical namespace, capability and full message — and by default an approval clears that action and nothing else, so approving one request does not authorise the next one. The binding is carried in the audit chain (it survives a restart) and through the Slack, Teams and Telegram approve/deny round-trip; a callback whose payload no longer matches is refused and audited. Single-approver and M-of-N quorum (2-of-3, 3-of-5, configurable TTL up to 90 days) both supported. Every vote audited. A deployment can opt into a standing per-capability window instead, which the sample configuration spells out in full.
/api/v1/audit emits signed JSON. /api/v1/compliance/report?regulation=eu-ai-act-art12 emits a regulation-mapped report (JSON or rendered HTML), with gap-analysis listing any required actions that have zero matching audit entries.
The RetentionEnforcer applies per-namespace retention windows. Entries beyond retention are pseudonymised in place — the hash chain is preserved, but personal-data fields are replaced with deterministic salted hashes. GDPR Article 17 right-to-erasure compatible while keeping cryptographic integrity intact.
The ComplianceSelfTest runs end-to-end checks at every boot: simulates a tamper event, verifies detection fires; tests the kill-switch; verifies the trust-level state machine; exports a self-test attestation. Catches drift before customers do.
Three regulation templates ship: EU AI Act Article 12 (10 requirements), ISO 42001 (13 requirements), NIST AI RMF (15 requirements). YAML-driven — add a new regulation by dropping a YAML file in regulations/. No code changes required.
A guided questionnaire classifies any AI use case against EU AI Act risk levels (Prohibited / High-Risk / Limited / Minimal). Output drives default trust levels, approval-gate requirements, and audit verbosity. Configurable per namespace.
The FederationRegistry lets multiple AIF deployments report Merkle-root anchors to a parent instance. Group-level compliance oversight for holding companies and conglomerates without forcing centralisation of the audit data itself — only the cryptographic proofs travel up.
SQLite by default (the operational store). Enterprise customers can configure MongoDB for the compliance data layer — audit entries, attestations, intents, memory all flow through pluggable interfaces. Adapters load via dynamic import — only the configured one runs.
The Intent layer (third pillar) makes every action a two-phase commit: the agent declares purpose + expected outcome before it acts, signs the declaration with Ed25519, and links every resulting audit entry back via intent_id. The gap between stated intent and actual action becomes queryable — the most valuable signal for AI alignment audits.
M-of-N voting on flagged capabilities: 2-of-3 for board-level operations, 3-of-5 for regulatory submissions, any combination you configure. TTL up to 90 days. Quorum status is itself a signed audit entry.
The IntentEnclave stages all side effects (file writes, API calls, database mutations) and either commits them atomically on successful intent finalisation, or discards them on abandonment. Irreversibility-gated effects require an explicit permitIrreversible flag that itself requires an approval-gate clearance.
The AuditorAgent is a read-only LLM agent over the intent + audit + provenance surface. A regulator submits a question in plain English ("Show me all decisions involving customer data in Q3 where the agent's stated intent diverged from the action"). AIF answers with the actual records.
Every answer the Auditor Agent returns is wrapped as a W3C Verifiable Credential, signed by the deployment root with the eddsa-rdfc-2022 data-integrity proof suite. Independently verifiable by any VC-aware verifier (eIDAS 2.0, EUDI Wallet).
The spine publishes its Merkle root to Sigstore Rekor as a rekord entry, on an interval, on an entry-count threshold, or on demand. Rekor is the same public transparency log the software supply chain runs on. Every attempt is persisted to anchor_records, success or failure, with the Rekor entry UUID: that UUID is the handle anyone needs to fetch the entry back, and without it an anchor cannot be verified at all. src/trust/anchor-verify.ts replays the RFC 6962 inclusion proof against the log's signed checkpoint and reports each individual check rather than a single boolean, exposed at GET /api/v1/anchoring/verify/:id and as npm run verify-anchor. A third party can reproduce the whole verification from the anchor record alone. The procedure is written out in docs/ANCHOR-VERIFICATION.md. Anchoring is opt-in per deployment (anchoring.enabled, default off); the staging reference deployment runs it against the public Rekor instance.
AIF ships the technical mechanics that map to record-keeping requirements (EU AI Act Article 12, ISO 42001, NIST AI RMF). Certification is your auditor's job. We give them the foundation that makes their review straightforward — we are not the auditor.
AIF does not compete with LangChain, CrewAI, AutoGen, or Microsoft's Agent Framework. It governs whatever agents you've already built in any of them. The DECIDE module ships five optional starter agents — those are reference, not competition.
AIF makes AI decisions accountable. The decisions themselves are made by your agents using your LLM provider. If the model hallucinates, AIF will sign the hallucination into the audit chain — and the regulator will see that. The signed record is the evidence, not the safety.
AIF is model-agnostic infrastructure. It works with Claude, GPT-5, Mistral, Gemini, and Ollama-hosted models — all of which can be wrong, biased, or out-of-date. AIF makes that fact visible and auditable; it does not make it go away.
We do not build identity — your existing Azure AD, Okta, or Keycloak does that. AIF reads the JWT your IdP issues and maps it to a verifiable agent DID. Don't migrate your identity stack to use AIF. Don't need to.
Why this page exists: every product claim in this market is a regulatory exposure for the customer. AIF's claims register is the discipline that makes the architecture trustworthy — if it isn't on this page, we won't tell you it does it. If you see anything overclaimed, tell us and we'll either fix the claim or remove it.