Trust Center

Security you can verify, not just trust.

We are a non-human-identity security company, so we hold our own platform to the standard we ask of customers: agentless, read-only, least-privilege access, every action on a signed ledger, and proof that travels in open standards.

01 · Our posture

How we operate safely in your environment.

Read-only by default
TrustFix inventories non-human identities through least-privilege, read-only access. We do not require — and do not want — standing write credentials into your environment.
No long-lived secrets we hold
Cloud access uses temporary, scoped credentials via customer-created roles. We never ask you to hand us a long-lived access key, and remediation is delivered as a pull request you review and merge.
Every action is on the ledger
Scans, findings, and proposed fixes are recorded on a signed, append-only trust ledger — so what TrustFix did in your environment is itself auditable, not a black box.
Human approval for every fix
TrustFix proposes; people decide. No automated change lands in your infrastructure without a human merging it. That is an axiom of the product, not a setting.
02 · Controls we enforce

Not promises — enforced in code.

The primitives below are real mechanisms at the current build, each backed by CI gates. Every card links to the whitepaper section that describes exactly how it works — and states the honest boundary where one exists.

First-party auth + mandatory MFA
Login is first-party (TFID) — no third-party identity broker for our own auth, and no trust in any client claim. MFA (TOTP + WebAuthn) is mandatory, sessions are server-side and instantly revocable, and passwords use memory-hard scrypt.
Proof: Whitepaper §5
SSO (SAML + OIDC) & SCIM v2
Enterprise SSO via SAML 2.0 and OIDC, plus inbound provisioning/de-provisioning via SCIM 2.0 with an org-scoped bearer token. Provisioning events are anchored in the signed ledger.
Proof: Questionnaire · IAM
RBAC re-read from the database
Authorization re-reads the caller’s role on every request against a strict hierarchy (Viewer < Member < Admin < Owner). The super-admin privilege is gated by deployment config at module load, so database tampering cannot grant it. Three CI gates ratchet against regressions.
Proof: Whitepaper §5
Per-tenant KMS envelope encryption
Secrets are sealed with AES-256-GCM envelope encryption, the tenant’s identity bound into the encryption context (AAD) via a pluggable KMS (software or Vault Transit). A wrong-tenant decrypt fails at the auth-tag layer. Honest boundary: software-based, no HSM/FIPS L3 path.
Proof: Whitepaper §4
Drift-proof tenant isolation
Automatic query scoping + cross-tenant rejection at the data layer, Postgres row-level security on key tables, and a CI gate that fails the build if any new id-route is unscoped — backed by behavioral tests that prove cross-tenant reads return "not found".
Proof: Whitepaper §3
Signed Merkle trust ledger
Every scan, finding, and change is recorded on an append-only, hash-chained, Ed25519-signed audit ledger with inclusion proofs — tamper-evident and independently verifiable. Honest boundary: not third-party trusted-timestamped, and we say so.
Proof: Whitepaper §7
Seven-framework evidence export
A control matrix maps signed artifacts to SOC 2, ISO 27001, NIST 800-53, OWASP ASI, ISO 42001, NIST AI RMF, and EU AI Act Annex IV — each with an honest per-control status — and exports signed bundles plus a NIST OSCAL export. A control is marked satisfied only when a real artifact backs it.
Proof: Compliance feature
03 · Open standards

Proof that travels in open standards.

We build on open, published specifications instead of proprietary formats, so a receipt from TrustFix can be verified by you, your auditor, or your tools — without trusting our servers.

W3C Verifiable Credentials
Findings and attestations are issued as W3C VCs — portable, cryptographically signed, and verifiable by anyone, not just by us.
did:key
Decentralized identifiers anchor the keys behind each receipt, so a verifier can check a proof offline without trusting a TrustFix endpoint.
OSCAL
Compliance evidence exports use NIST OSCAL, the open control/assessment format auditors and GRC tools already understand.
OCSF
Identity and detection events are emitted in the Open Cybersecurity Schema Framework so they flow into your SIEM and data lake natively.
IETF AAT
Attenuating Agent Tokens follow the emerging IETF work for scoping and attesting AI-agent authority.
IETF Delegation Receipts
When authority is delegated between principals, we record it as a signed delegation receipt — a provable chain of who acted on whose behalf.
Token Status List
Credential revocation and validity use the IETF Token Status List mechanism, so a relying party can check whether a receipt is still good.
04 · Data handling

Agentless, read-only, least-privilege.

Agentless
No agent to deploy into your hosts. TrustFix reads identity metadata through cloud and code-host APIs, so there is no new running process inside your estate to maintain or trust.
Read-only
We read identity configuration — IAM roles and trust policies, OAuth grants, CI/CD tokens, workflow files, signing-cert metadata. We do not read application source code or customer business data.
Least-privilege
Access is scoped to exactly what the inventory needs, granted through roles you create and can revoke at any time. Your environment data is isolated per tenant and never visible to other customers.
05 · Compliance
SOC 2 — in progressWe do not claim a certification we have not earned.

We are honest about where we are: TrustFix is an early company, and our formal third-party attestations are works in progress, not completed certifications. We will say a framework is certified only once an independent auditor has signed off — and we will link the report here when that happens.

Separately, the product helps your team produce auditor-ready evidence mapped to SOC 2, ISO 27001, NIST and the EU AI Act — exported as OSCAL/OCSF and verifiable offline. That is a TrustFix feature for your compliance program; it is not a claim about TrustFix’s own certification status.

06 · Responsible disclosure

Found something? Tell us.

We appreciate the security research community. Report a vulnerability to the address below and we will acknowledge receipt promptly. We follow a coordinated, 90-day disclosure timeline consistent with industry norms, and we offer safe harbor for good-faith research that respects user data and service integrity.

security@trustfix.dev
  • A clear description and reproduction steps
  • Potential impact and any proof-of-concept
  • Do not access or modify other users’ data
  • Give us reasonable time to fix before public disclosure
01
Acknowledge
We confirm receipt of your report promptly.
02
Investigate
We validate and triage the issue.
03
Fix
We remediate, prioritising critical issues.
04
Disclose
We coordinate disclosure after the fix ships.
Trust Center | TrustFix