Security & privacy
Built so institutions can share safely
Security and privacy are Masenu Pro's operating premise, not a feature bolted on later. Three principles govern the whole design:
- 1.Raw personal data never crosses institutional boundaries. Identifiers are hashed at the member's edge before they reach us.
- 2.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.
- 3.AI proposes; deterministic systems dispose. No AI output is ever authoritative or drives a customer-affecting decision on its own.
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 Masenu Pro 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.
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.
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.
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.
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.
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 — honest status
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 |
Evaluating Masenu 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 security@masenu.app.