Security & privacy
Built so institutions can share safely.
Security and privacy are Adoor's operating premise, not a feature bolted on later. Three principles govern the whole design:
01/Privacy
Raw personal data never crosses institutional boundaries. Identifiers are hashed at the member's edge before they reach us.
02/Provable
Every control is enforceable in code and provable in evidence. SOC 2 Type II-ready from the first commit; the system generates its own audit evidence continuously.
03/AI safety
AI proposes; deterministic systems dispose. No AI output is ever authoritative or drives a customer-affecting decision on its own.
Architecture
Six controls, each enforceable in code.
01
Privacy by design — raw PII never reaches us
- Identifiers are HMAC-SHA256 hashed at the member's edge with a KMS-held, versioned consortium pepper — we store one-way keyed digests, not personal data.
- A breach of Adoor cannot expose members' customers' numbers, accounts, or IDs, because we never hold them.
- The narrow lawful exceptions (dispute / law-enforcement) use an AES-256-GCM PII envelope, opaque at rest and never returned by any standard API.
- Aligned to Ghana's Data Protection Act (Act 843): the consortium processes pseudonymized data; raw personal data stays with the institution that collected it.
02
Multi-tenant isolation & access control
- Every record carries an org_id; every query is org-scoped by a dependency-injected filter — isolation is structural, not by convention.
- Shared intelligence never reveals who reported what — contributor identity is reduced to sector + country.
- Cross-tenant isolation is verified by an automated suite that attempts cross-org reads on every endpoint, on every change.
- API keys stored as SHA-256 digests with scoped permissions; portal users get Argon2id passwords and mandatory TOTP 2FA with no opt-out.
03
Tamper-evident audit trail
- Every lookup, report, and admin action is written to an append-only, cryptographically hash-chained audit log.
- Any retroactive insert, delete, or edit breaks the chain; UPDATE/DELETE are additionally rejected at the database layer.
- A scheduled worker re-walks and verifies the entire chain and raises a severity-1 alert on any discrepancy.
04
AI safety — the LLM proposes, deterministic systems dispose
- The LLM never touches risk scores. Scores come from transparent, versioned rules over database facts, and every decision returns human-readable explanations.
- A grounding gate drops any AI-extracted identifier that does not appear verbatim in the source text — a fabricated (hallucinated) identifier cannot enter the system.
- Analyzed content is treated as adversarial: the model has no tools, no database access, emits only a fixed schema, and a pre-model detector quarantines injection attempts.
- The model provider is pluggable and never authoritative — the safety architecture is what guarantees correctness, not the model.
05
Abuse & data-poisoning resistance
- Full-weight reports come only from KYB-verified member institutions; consumer/public submissions carry zero scoring weight until corroborated.
- High/critical risk bands require reporter diversity across multiple organizations and sectors — framing an innocent identifier means compromising several regulated institutions.
- Per-member trust scoring and submission-anomaly monitors down-weight and freeze suspicious contributors automatically.
- Every fact is traceable to (org, report, timestamp); one administrative action quarantines a compromised member and recomputes affected scores — poisoning is reversible.
06
Secure development & encryption
- Protected main branch and a CI gate that must pass before merge: tests, linting, SAST (bandit), dependency scanning (pip-audit), and secret scanning (gitleaks).
- Secrets and the consortium pepper live in a managed KMS with versioned rotation — never in code or committed env files.
- TLS 1.2+ with HSTS in transit; AES-256 at rest with column-level encryption for PII envelopes, TOTP secrets, and key material.
- Logs are PII-scrubbed by a filter that redacts identifiers, secrets, and tokens — verified by unit tests.
Compliance posture
Stated honestly — completed or planned, never overclaimed.
We state certifications as either completed or planned, and never claim what we do not hold. Fintech design partners can typically proceed on the architecture plus the whitepaper; banks will want at least a Type I report plus “Type II in progress.”
| SOC 2 control architecture implemented in code | Done |
| Continuous evidence generation (endpoints + logs) | Done |
| Automated security test suite in CI | Done |
| SOC 2 Type I (point-in-time) | Plannedonce design-partner data flows begin |
| SOC 2 Type II (observation window) | Plannedfollows Type I |
| Independent penetration test | Plannedannual cadence |
| Continuous-compliance platform (e.g. Vanta) | Plannedduring rollout |
For prospective members
Evaluating Adoor for your institution?
The full security whitepaper, subprocessor register, and data-processing agreement are available to prospective members — just reach out. Vulnerability reports go to fafa@masenu.com.