Standards & Regulations

Built on the standards auditors require

FIOR AI Gateway aligns with FIPS, ISO, SOC 2, EU AI Act, NIST AI RMF, GDPR and NIS2, so you can deploy autonomous AI without rewriting your compliance programme.

Framework Coverage

Each framework is mapped to specific FIOR controls. Request the full compliance pack for auditor-ready evidence.

Need an auditor-ready compliance pack?

We provide control-by-control mapping documents, architecture diagrams and evidence samples for your assessment.

Common audit questions

Quick answers to the questions auditors and security teams ask most often about FIOR’s cryptographic posture and regulatory scope.

Yes. FIOR’s cryptographic stack supports the NIST post-quantum standards: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) for digital signatures, and FIPS 205 (SLH-DSA) as a stateless hash-based signature alternative.

These are used for agent identity certificates, mutual authentication handshakes and policy signing, providing quantum-safe protection against “harvest now, decrypt later” attacks on AI agent traffic.

Yes. Policies can require hybrid suites that combine ECDSA/RSA with ML-DSA, or ECDH with ML-KEM, so deployments stay interoperable with legacy PKI while gaining quantum resistance. Enforcement is per-policy and can be tightened over time.

FIOR is designed to operate with FIPS 140-3 validated cryptographic modules. Customers requiring validated modules deploy FIOR against an approved provider (e.g. a FIPS-validated OpenSSL provider, HSM or cloud KMS) and FIOR consumes its primitives through that boundary.

Validation status of any specific deployment is determined by the chosen module and operating environment. We provide a configuration guide and module attestation references in the compliance pack.

Agent identity keys are bound to hardware roots of trust where available: TPM 2.0 on Linux/Windows hosts, Secure Enclave on macOS, and network HSM / cloud KMS for gateway and CA keys. PCR measurements are included in attestation evidence.

FIOR operates at the network and identity layer. It authenticates agents, signs policies and records connection metadata (agent ID, certificate serial, timestamp, decision). It is not designed to inspect or store the content of agent payloads.

Where metadata constitutes personal data (e.g. an agent acting on behalf of an identified user), FIOR acts as a processor under the customer’s instructions. A DPA, records-of-processing template and data-flow diagram are included in the GDPR compliance pack.

Yes. FIOR is offered as a self-hosted gateway (K3s/Kubectl) and can run entirely within customer infrastructure or a chosen cloud region. No agent traffic or audit logs leave the customer boundary unless explicitly configured.

For essential and important entities under NIS2, FIOR contributes to Article 21 risk-management measures – cryptography and access control, supply-chain security (signed agent identities) and incident detection, and supports Article 23 incident reporting through the audit and incident pipeline (early warning, 24h / 72h notifications, final report evidence).

Yes. Every agent, internal or third-party, must present a valid X.509 identity issued under your policy. Revocation propagates network-wide in milliseconds, so a compromised supplier agent can be cut off without redeploying applications.

The framework-specific Compliance Pack typically covers initial auditor walkthroughs without bespoke documentation.