01 · Edge
Cloudflare WAF
DDoS protection, geo-blocks, common-payload filtering at the edge.
Security & governance
Constitutional governance, per-answer provenance, and a refusal mechanism that’s itself reviewed.
Most coding agents make security choices with the same model that wrote the code. Krentix doesn’t. On the full-power tier, answers are reviewed by up to twelve verifiers from eight labs (3-persona default council expands on flagged or escalated requests), governed by a Constitutional Tribune with veto authority, and the Tribune’s vetoes are themselves reviewed by a Supreme Court (cross-provider check) so the refusal mechanism cannot become a denial-of-service. Speed-tier answers ship faster with the default 3-persona council.
For enterprise buyers: every answer carries a cryptographic provenance trail showing which model contributed, which verifier passed, which were overruled, and why. Internally usable and externally auditable.
01 · Defence in depth
Eight layers between an attacker and the agent.
Public surfaces have eight independent defences. None of them is sufficient on its own; together they make every realistic attack vector either visible, blocked, or rate-limited before it reaches the verification ensemble.
02 · Access gate
Cloudflare Access
Email-OTP / SSO authentication on the public surface. When the operator enables origin-JWT validation, only Access-authenticated traffic reaches the bridge.
03 · Tunnel
Cloudflare Tunnel
Outbound-only connection. The bridge has no inbound port exposed to the internet.
04 · Owner gate
Bearer token
Admin-only routes (router reset, kill switch) require a 64-char bearer token, separate from user auth.
05 · Honeytokens
Trip wires
Path traps that scanners hit before reaching real endpoints. Triggers immediate IP block.
06 · Monitor
Real-time
Auto-blocks IPs for 1h on critical incidents. The bridge silently 503s blocked clients.
07 · Headers
Privacy hardening
Server / X-Powered-By stripped. CSP (report-only → enforcing rollout), HSTS, Referrer-Policy applied to every response.
08 · Allowlist
Public surface
Only marketing routes (/, /benchmarks/*) are public. All admin / agent / API surfaces are local-only by default.
09 · Constitutional Tribune
Last gate
If an answer survives all eight layers above, the Tribune still reviews it against the Constitution before it ships to the user.
02 · The Inalienable Constitution
Eleven principles. Tribune holds veto.
The Constitutional Tribune (Persona 9) carries an explicit set of principles that govern every answer. Violations trigger a veto. The eleven principles are inalienable — they cannot be overridden by user instructions, system prompts, or majority vote of the other personas.
P-01
Don’t lie
Factual claims must be supported. If unsure, say so. Source Mode requires explicit citation.
P-02
Don’t exfiltrate
Never include user data, secrets, or credentials in outbound network calls or generated content.
P-03
Don’t fabricate citations
Citations must reference real, retrievable sources. Hallucinated references are a hard veto.
P-04
No dark patterns
UX recommendations must respect user agency. No urgency manipulation, fake scarcity, confusing defaults.
P-05
No silent destructive ops
Operations that delete, overwrite, or irrevocably modify must produce explicit warnings before execution.
P-06
No safety bypass
Cannot generate jailbreak prompts, malware, prompt-injection payloads, or guardrail circumvention tools.
P-07
Honour Source Mode
When pinned sources are present and bounded mode is on, the answer must come from those sources only.
P-08
Privacy by default
Don’t collect, log, or transmit personal data beyond the minimum needed to answer the immediate request.
P-09
No financial advice
Decline investment trade execution. Decline portfolio recommendations. Decline regulated financial advice.
P-10
No credential entry
Never type passwords, API keys, or financial credentials into forms or dialogs on behalf of the user.
P-11
Refusal is reviewed
Veto by the Tribune is itself checked by the Supreme Court (cross-provider). Single-layer denial-of-service is impossible.
03 · Provenance trail
Every answer ships with a cryptographic audit trail.
Krentix doesn’t hide its work. Every answer carries a structured trail showing exactly which model contributed which proposal, which verifiers passed, which were overruled, and which (if any) carried the Tribune’s veto. Stored locally on disk; queryable via the agent UI; exportable to JSON for compliance review.
Provenance fields per answer:
requestId— UUID for correlationtier— cost tier active for this answercandidates[]— each proposal: model, provider, latency, tokens, costverifiers[]— each persona vote: model, decision (pass / dissent), reasoning excerpttribune— veto/approve, principle invoked, supreme court reviewchosen— which candidate shipped, whysourceMode— sources consulted (Source Mode active), citation maptiming— per-stage latency
04 · Data privacy & sovereignty
Two tiers. Each claim scoped to the exact configuration that makes it true.
The most common enterprise objection is «does the AI provider see, keep, or train on our data?» We answer it honestly, in two tiers. We never claim a hosted provider cannot view your data — on hosted models a provider necessarily decrypts your prompt in memory to run inference. What we do is control, minimise, and cryptographically attest exactly where your data went and under which terms — and, in Sovereign, take every third party out of the path entirely.
Tier A · Enterprise Privacy
Hosted frontier models, hardened — dispatched only to vetted no-retention / no-train endpoints.
Honest framing. The model provider processes your prompt transiently to generate the answer — that is inherent to hosted inference, and we don’t pretend otherwise. What Tier A guarantees is enforced, attested control over that exposure:
· In Enterprise mode, data is dispatched only to providers contractually bound to zero data retention and no training on inputs (asserted per provider terms); non-eligible endpoints are refused before egress, and failover is filtered the same way (it never silently falls back to an excluded provider).
· Available on deployment: an in-tenant tokeniser that replaces detected secrets / PII of the structured classes the active engine covers (emails, API keys, cards, JWTs, PEM blocks, …) with stable surrogates before egress — the provider receives [PERSON_1], not the value — with an in-memory, one-request de-tokenisation map that is never written to disk, never logged, never sent to any provider. The redaction gateway + reverse-map lifecycle are built and unit-tested; wiring them into the hosted egress branch is an enable-on-deployment step, not on by default. Detection recall is best-effort, not 100% — we name the engine that ran, we don’t claim «all PII removed.»
· Krentix does not persist your prompt or response bodies; log lines carry only a length and a hash.
· Available on deployment (flag-gated): document bodies can be encrypted at rest under authenticated AES-256-GCM with a per-tenant BYOK envelope key; crypto-shredding that wrapping key renders the tenant’s at-rest ciphertext unrecoverable. This is off by default and enabled per deployment; external KMS / customer-managed-key integration is on the roadmap, not yet available.
Retention / no-train are configuration we asserted and signed, not cryptographic proof of provider behaviour. We prove what we sent and configured; honouring the contract is the provider’s obligation.
Tier B · Krentix Sovereign
Open-weight ensemble running entirely on infrastructure you control — no third-party AI provider in the path.
Available for VPC / on-prem deployment. Sovereign is the configuration in which the literal claim «no third party can view your data» becomes true — because no third-party AI provider is ever contacted. This is shipped as code + config (enforcement, sovereign provider entries, Helm + default-deny NetworkPolicy, signed model registry, attestation verify-logic), deployed into your VPC or on-prem cluster. It is not a Krentix-hosted service — your data only runs sovereign once you deploy it in an environment you control.
· In Sovereign mode, inference runs entirely in your environment; outbound calls to any non-local provider throw before the network call — including every failover hop — and a Kubernetes default-deny NetworkPolicy drops outbound traffic to public AI hosts, verifiable by your own packet capture.
· The model weights that run are the weights shipped, sha256-pinned in a signed registry and verified before load.
· N distinct open-weight model families cross-check every answer locally — same disagreement-resolution pipeline, no outbound key. (Per-model quality trails frontier; we disclose the measured delta, we don’t claim parity.)
Confidential-computing (TEE) roadmap. A hardware-TEE profile — where not even the cloud operator can read enclave memory, gated on a silicon-vendor-signed attestation verified before any key release — is on the roadmap; the attestation verify-logic is built and tested, real TEE hardware-quote collection is the deployment step. We don’t sell it as live until a quote verifies.
None of the above is «trust us.» The proof mechanism is a per-request ed25519 signed attestation — designed to record which providers received the data, under which retention mode and region, with what redaction — that you verify with our published public key (attest-public-key.pem, also served at /api/attestation/pubkey) against the signed audit-export, without trusting our servers: tamper one byte and verification fails. The signing + verification + tamper-evidence are built and tested today; on deployment, populating the per-request egress-hop record (which provider, retention mode, region) is the enable step that makes every field of that attestation live. We describe what is signed honestly — the crypto is real now; the per-hop egress content is enabled per deployment.
05 · Compliance posture
What we have today vs. what’s on the roadmap.
Krentix is pre-launch on enterprise compliance. We’re honest about that. Below is the current state per common framework. Items marked «in progress» have a real workstream; items marked «gap» are roadmap candidates if a buyer needs them.
| Framework | Status | Notes |
|---|---|---|
| SOC 2 Type II | Roadmap · Q3 2026 | Will be audited once production traffic justifies the spend |
| GDPR | In progress | Privacy-by-default per principle P-08; data export endpoint shipping with self-hosted release |
| HIPAA | Self-hosted only | Hosted version not BAA-eligible. Self-hosted with bridge on customer infrastructure can support HIPAA workloads |
| ISO 27001 | Roadmap | Aligned controls in place; certification deferred until commercial scale justifies audit |
| SLSA Build Provenance | v1 · per tagged release | SLSA v1 build provenance is generated + gh attestation verify-ed on every tagged release (GitHub-OIDC Sigstore attestation, fail-closed in-pipeline). Commits and release tags are signed once the repo’s signed-commit / signed-tag rulesets are enabled. See docs/SUPPLY-CHAIN.md |
| OWASP LLM Top 10 | All 10 mitigated | Prompt injection / output handling / training data poisoning / model DoS / supply chain - see governance architecture above |
| NIST AI RMF | Aligned | Govern / Map / Measure / Manage all addressed; formal mapping document in progress |
06 · Disclosure
Found a security issue?
Email security@krentix.com with details. We respond within 48 hours, fix critical issues within 7 days, publish a writeup on /changelog after the fix ships.
No bug bounty yet (pre-revenue). Public credit on the changelog if you’d like it.