Hashes in, proof out.

Firmantia is in development. This page says how the record is built, how it is checked, and which parts are not built yet. Where something describes how Firmantia is built to run for a customer rather than something running today, it says so.

What the record holds

• Hashes, never content. A record names the agent, what it did, the tool or model it called, the policy decision, the time, and the platform's own reference for the event. Where the platform exports the input and output, the record keeps their SHA-256 hashes. It never holds prompt text, response text, customer data or personal data.
• No person in the agent's fields. Agent fields come only from what the platform reports about the agent. A value that matches the user on the event is dropped.
• Nothing is edited. Records are appended, never changed or deleted. The store refuses both.

Where it lives

• Built to stay in the customer's country. Firmantia is built to run inside the customer's own environment, so records, keys and the evidence packs stay where the customer keeps them. A hosted service is not built yet.
• Only a hash leaves. Each sealed batch is time stamped by an independent RFC 3161 time stamp authority. What is sent is the batch's SHA-256 hash, nothing else. The demo uses DigiCert's public time stamp authority; an in-country authority is a configuration change once one is designated.

Who holds the keys

• The customer holds the signing key. Firmantia is built so that it never holds a customer's private key. Today the key is a file on the machine that seals the record; hardware and cloud key storage are not built yet.
• People sign their own approvals. A human approval is signed with the approver's own key, never with the service key, and never by the person who requested the action: whenever the record names who requested it, the verifier refuses an approval by that person.
• Rotation by validity window. A rotated key keeps its window in the signed key registry, so entries it signed still verify.

How it is verified

• No network, no Firmantia service, no account. The check runs on the auditor's own computer.
• One readable file. The verifier is a single HTML file. Anyone who receives a pack can read the code that checks it.
• If Firmantia disappears, the packs still verify. Nothing in the check depends on us.

Cryptography

• SHA-256 for hashes, ECDSA P-256 with SHA-256 for signatures, RFC 3161 for time stamps.
• Built in cryptography only: Web Crypto in the browser verifier, Node's crypto module in the tools. No third party cryptography library.

Not built yet

A hosted service, hardware and cloud key storage, an in-country time stamp authority, connectors beyond Microsoft Agent 365, and an outside security review. Firmantia holds no certifications.

The longer list

The questions a security review or an auditor asks, answered one by one: Security answers.

Reporting a problem

Tell us through the early access form and say it is a security report; a person reads it. A security contact address and a disclosure policy will be published before launch.