Security and trust
Know exactly what stays, and what can leave.
FusionWall is a security product, so it is built to be inspected, not taken on faith. Here is precisely how it handles your sensitive data: what never leaves your machine, what leaves only after you approve it, and how every step becomes proof you can verify yourself.
The core design
One governed turn, every single time.
There is one path between you and any AI model, and it is the same for a quick question and a multi-step automation.
1 · Mask locally
Sensitive values are detected and tokenized on your computer before anything is sent. The same value always maps to the same placeholder, so restoration is exact and the work stays coherent.
2 · Approve the exact view
You see the precise protected text that would leave, and nothing is sent until you approve it. At the true moment of sending, FusionWall re-checks against your current terms and refuses if anything changed.
3 · Restore and seal
The answer is restored on your screen and the whole turn is sealed into a tamper-evident ledger. An answer FusionWall cannot verify and restore is withheld rather than shown.
The boundary
What stays, and what leaves.
FusionWall runs entirely on your own machine, bound to loopback. It is not a cloud service that sees your data.
Never leaves your machine
These stay under your local authority, always.
- The cleartext behind every masked token
- The token-to-value mapping that restores answers
- Your original files and documents
- Your Vault secrets and your master password
- Your device's private signing key
- Your proof ledger and configuration
Leaves, only after you approve
One thing leaves, to the provider you chose.
- The masked prompt, with sensitive values already tokenized
- Sent to the specific model endpoint you configured
- Only after you reviewed and approved that exact text
- Re-checked at the moment of sending, and refused if your terms changed
- Recorded as a receipt that carries hashes and references, never originals
Customer-owned evidence
A record you can verify, that you own.
Every masking decision, policy outcome, send, and withholding is appended to a local, hash-linked ledger. It is tamper-evident: any rewrite, reorder, or truncation breaks verification against a keyed seal. Receipts carry content hashes and references, never the cleartext behind them, and you can export the whole chain for independent review.
- Append-only hash chain with a keyed tip attestation
- Verify the chain yourself, any time, with no vendor and no model provider involved
- If the ledger fails to verify, no prompt can leave until integrity is restored
- One-click CSV export for auditors and independent review
Defense in depth
Controls at the edge, and at rest.
Model-agnostic egress
You choose the provider. FusionWall talks to a pinned endpoint, follows no redirects, honors no environment proxies, and caps request size. The prompt is masked and policy-checked before it can go.
Encrypted local Vault
Keys, logins, and secrets are encrypted at rest with AES-256-GCM under a key only your master password derives. Auto-lock, per-item reveal, and no browser autofill. Your secrets stay out of prompts entirely.
Add-only policy floor
A built-in standards safety floor maps controls to recognized frameworks, and every custom policy or industry pack can only tighten it. Weakening a protection is privileged and is itself sealed to the ledger.
FusionWall Pro
Team oversight that cannot read your content.
When a company runs many seats, it can host one Company Controller on infrastructure it owns and enroll each seat as a node. Federation is opt-in and off by default. The design gives an organization real oversight of governance activity while so the controller receives only metadata receipts, and there is no code path that sends the work itself.
- Only metadata-only receipts leave a node: sequence, event type, hash, and time
- The export path refuses to include payloads, actors, cleartext, or secrets
- A controller can only add restrictions, never weaken a node's built-in safety floor
- Ed25519 mutual verification with replay and impostor protection on every exchange
Separation of duties
Who can act is separate from who can review.
FusionWall separates duties locally with distinct roles, and at the fleet level through controller admission.
- Owner, operator, and auditor roles are enforced on every request path
- An auditor can review and verify evidence but cannot send or change anything
- Every node is admitted by a controller administrator, a role separate from the node's own operator, and can be revoked at any time
- Per-turn approver separation across people is a defined FusionWall Pro capability on the roadmap, not yet enforced per send
Straight talk
Protection is a control, not a guarantee.
We would rather earn your trust with precision than lose it with a slogan.
- Detection is conservative. No detector can promise perfect recall, which is why you review the exact outbound view before anything sends. Add your own terms and pilot with test data first.
- Standards-mapped, not certified. Policy mappings are technical controls, not legal advice, not an audit result, and not proof that you are compliant.
- Tamper-evident, not a notary. The ledger makes silent changes visible on your machine; the attestation key currently lives on the same disk, so it is not external attestation.
- Your provider relationship stays yours. The masked prompt still goes to the AI provider you choose; their terms and data retention remain between you and them.
Found something? Tell us.
We take security reports seriously and welcome responsible disclosure. Email support@fusionwall.io, or review the current public artifacts in the Trust Center.