QgenticQgentic
Qgentic / security & evidence
Information Security & Vendor Risk

Cryptographically Verifiable Security.

Enterprise vendor risk management requires more than attestations; it requires verifiable proof. Qgentic is architected to exceed the scrutiny of regulated institutions (including DORA's own ICT third-party requirements). Every security control detailed below is technically reproducible within your own environment, against your own data, during technical validation.

Request the security dossier See the evidence, end to end
The evidence view · read-only
The Qgentic compliance run report: the named-human approval recorded on the audit chain, the run's platform, tenant and timestamps, a verdict of succeeded with zero validation errors and zero warnings, and eleven audit chains each verified VALID with its entry count — a read-only window over the compliance data plane that cannot change the record. The Qgentic compliance run report: the named-human approval recorded on the audit chain, the run's platform, tenant and timestamps, a verdict of succeeded with zero validation errors and zero warnings, and eleven audit chains each verified VALID with its entry count — a read-only window over the compliance data plane that cannot change the record.
The compliance run report is a read-only cryptographic verification of one processing run: who approved it and when the decision hit the audit chain, the deterministic validation result, and every SHA-256 hash chain re-verified with its entry count. The presentation layer is strictly decoupled from the mutable data plane; the same report prints to PDF for an auditor.
Architectural Determinism Boundary

Strict Isolation of Non-Deterministic Execution.

Our platform enforces a strict architectural boundary. AI/LLM models are relegated exclusively to data extraction and synthesis. All validation, classification, and final schema compilation are executed by static, deterministic logic gates. Non-deterministic output cannot corrupt a regulatory record because it must successfully traverse the deterministic validation layer prior to commit.

Deterministic Layer (Validation & Logic)Non-Deterministic Layer (Extraction & Synthesis)
Cryptographic checksums: ISO 17442 LEI (MOD 97-10), VRN mod-97, FRN regexUnstructured data extraction (contracts, policies) to JSON schema
ISO 3166 / 4217 validation · Regime-specific static rules enginesAutomated generation of vendor outreach communications
Mathematical derivation: VAT aggregation, SLA/tolerance-breach calculationsAgentic exploration and data correlation
SHA-256 audit chaining · IAM/JIT token issuance · Payload hashing— (Note: MTD module operates strictly deterministically without AI)
The determinism boundary: what the model may do, and what only code decides Untrusted input — contracts, system exports, vendor replies — meets the model inside a contained, non-deterministic layer that may extract, draft, correlate and explain but has no path to the record: its output is a proposal until code verifies it. Deterministic code re-derives every field — LEI and VRN checksums, recomputed totals, ISO code sets, breaches by arithmetic — and a failed rule refuses the run; degradation costs latency, never validity. High-privilege actions require a named approval, then an HMAC-signed grant with a 120-second lifetime and a single action. Every action lands as a hashed entry on tamper-evident chains, re-verifiable offline, and the evidence view reads the chain but cannot change it. § UNTRUSTED INPUT § THE MODEL — PROPOSES § THE CODE — DECIDES § THE RECORD Contracts & policies PDF · DOCX · free text unstructured, untrusted System exports JSON · CSV · XLSX structured, still untrusted Vendor replies async outreach responses arrive when they arrive NON-DETERMINISTIC · CONTAINED extracts documents to schema drafts vendor outreach correlates master data explains what changed NO PATH TO THE RECORD Model output is a proposal until the code verifies it. MTD runs with no model at all EVERY FIELD RE-DERIVED LEI MOD 97-10 · VRN mod 97 totals recomputed, not read ISO 3166 · 4217 code sets breach = arithmetic, not a flag A failed rule refuses the run. Degradation costs latency — never validity. APPROVE → MINT → ACT HMAC · ttl=120s · one action The record sha256(prev + entry) every action an entry on a tamper-evident chain five chains re-verified offline, with independent tooling — no vendor needed The evidence view is decoupled and read-only. print it for the auditor The boundary in one line: the model may read, extract and draft; only deterministic code may validate, commit or file — and both sides land on one audit chain.
The determinism boundary, drawn. Untrusted input meets the model inside a contained layer with no path to the record — its output is a proposal until deterministic code re-derives every field and lets it pass. High-privilege actions need a named approval and a 120-second, single-action HMAC grant. Model degradation can slow a run; it cannot alter a filed record.

Model degradation impacts processing latency (via retry loops) but cannot alter the cryptographic integrity or validity of the finalised regulatory payload.

Cryptographic Integrity

Tamper-Evident SHA-256 Audit Chains.

Continuous Cryptographic Verification

Microservices append state changes to isolated SHA-256 hash chains. Each node hashes the preceding hash concatenated with the canonical payload. Chains undergo continuous integrity verification and support offline verification via independent tooling.

entryHash = sha256(prevHash + canonical(entry)) → STATUS: VERIFIED

Execution verifies five distinct service chains. In SaaS deployments, a sixth chain audits API gateway activity and IAM approvals. Execution evidence is packaged as a hashed archive with a human-readable attribution report. Complete dataset export capability keeps the platform portable.

Zero Standing Privileges (ZSP) via JIT Tokens

High-privilege actions (e.g., regulatory submission, bulk export) require ephemeral, HMAC-signed capabilities with tight TTL boundaries. Tokens are minted strictly following IAM-authenticated human approval. The approval, minting, and execution are recorded as discrete, auditable events.

iam.approval → token.mint(HMAC, ttl=120s) → action.execute
Deployment Topologies

Flexible Infrastructure and Data Boundaries.

SaaS

Multi-Tenant Cloud

Logical multi-tenant isolation. API credentials hashed (SHA-256) at rest, shown once at generation. Regional data residency (UK/EU), enforced. Every sub-processor documented, with contractual notice before any change.

Dedicated

Single-Tenant Cloud

Physical isolation within a dedicated VPC. Integration with enterprise KMS for customer-managed encryption keys (CMEK). Change management controls including named maintenance windows.

Air-gapped

Zero-Trust / Air-Gapped

Statically compiled binary deployment. Zero external telemetry, zero sub-processors, and disabled API access (enforcing local deterministic processing). In-process egress controls actively block and log outbound requests. Fully verifiable via standard enterprise network monitoring.

The delivery mechanics behind the on-premise topologies — cosign-signed images, pinned digests, IT-run updates and the pre-answered change request — are documented on the deployment & updates page.

Secure Integration Patterns

Zero-Impact ERP Integration Architecture.

Asynchronous File Ingestion

Support for watched-directory integrations within the enterprise perimeter. Compatible with legacy ERP exports (e.g., SAP AL11 output). Unidirectional data flow; Qgentic never requires write access to the source ERP.

REST API Polling

Read-only integration against REST endpoints you expose, authenticated with scoped bearer tokens. Pull model only: nothing external ever writes into your ERP.

Enterprise Middleware Compatibility

Works with the iPaaS you already run — SAP CPI, MuleSoft, Boomi. Standardised boundary contracts make integration configuration, not an engineering project.

Vendor Risk Artifacts

Bring Your Due Diligence.

Pre-Contractual Artifacts

A full security dossier, a lockfile-generated SBOM, signed binaries with published SHA-256 hashes, source-code review under NDA, and local technical validation. Everything your security team will ask for, ready before they ask.

Get-FileHash qgentic.exe # Verification of published SHA-256

Contractual Security Commitments

Pre-populated DORA register documentation (B_05.01, B_02.02, B_07.01). Schedules incorporating Article 30 audit/access rights, defined exit/export protocols, sub-processor limitations, and explicit, documented capability boundaries.

Request Due Diligence Pack

Verifiability. Trust claims are worth nothing without a way to check them. Qgentic gives you the way: deterministic execution, full auditability, and air-gapped deployment if you want it. Send your security team. We built this for them.