AffixIO/affix-huggingface

AffixIO for Hugging Face

Admission and evidence controls that sit in front of Hugging Face inference. The SDK checks and consumes an AffixIO proof before a request reaches a model. A denied request never reaches the provider. After a successful non-streaming response, AffixIO can issue a post-quantum signature over the model and receipt metadata.

The signature uses ML-DSA-65, the module-lattice digital signature standardised by NIST in FIPS 204. That keeps the provenance record verifiable against a future quantum adversary, which matters for retention rules that expect records signed today to still hold in ten to fifteen years. The approach is close in spirit to signed inference receipts described in recent IETF SPICE work: a compact, hardware-free attestation over what was requested and what came back.

Prompt text, message content, embeddings input, and model output are never sent to AffixIO. Only the admission decision and metadata cross the boundary.

Install

python -m pip install affix-huggingface
export HF_TOKEN="hf_..."

The package is published to PyPI. This repository mirrors the built wheel, the source, and this card.

Quick start

from affix_huggingface import AdmissionChecks, AffixHuggingFace, ModelRef

model = ModelRef(
    model_id="meta-llama/Llama-3.1-8B-Instruct",
    revision="replace-with-a-reviewed-commit-sha",
    provider="hf-inference",
)

with AffixHuggingFace() as client:
    result = client.chat_completion(
        [{"role": "user", "content": "Summarise this incident report."}],
        model=model,
        checks=AdmissionChecks(
            entitled=True,
            data_route_allowed=True,
            controls_satisfied=True,
        ),
        max_tokens=200,
    )

print(result.output)
print(result.receipt.gate.receipt_id)
print(result.receipt.completion.attestation)   # ML-DSA-65 (FIPS 204)

The three checks are decisions the calling application makes from its own records: whether the caller is entitled to the model tier, whether the input classification may reach this hosting arrangement, and whether required controls are active. Only these booleans go to AffixIO, not the records behind them.

Free allowance and your own key

Without AFFIX_API_KEY, the SDK runs on a published trial key and each subject gets 100 proofs. The count is held on api.affix-io.com against a subject digest, not in a local file, so deleting the cache or reinstalling does not reset it.

When the allowance is spent, TrialExhausted explains how to continue:

1. Register at https://hub.affix-io.com/ and request API access.
2. Access is granted after review, not instantly.
3. Once approved, create a key at https://hub.affix-io.com/credentials/.
4. Set AFFIX_API_KEY=aio_... and run again. Your own key has no cap.

Integrity guard

The wheel ships a signed file manifest. On import the package rehashes every shipped file and compares it to the manifest. If any file has been overwritten, edited, added, or removed, import fails and the client refuses to run. It is tamper-evident rather than tamper-proof, and the docs say so plainly: the guard runs on your machine, so it stops accidental or silent modification rather than a determined operator who edits the guard itself.

What this is not

It does not run the model, prove which weights executed, or mathematically verify the inference. Where an exact deployed revision must be provable, pin a dedicated Inference Endpoint. The attestation is a signed record over declared metadata, anchored to a standard that survives the move to post-quantum cryptography.

Licence

Apache-2.0. Copyright 2026 AffixIO.