How is one customer's data kept apart from another's?
Isolation is structural, not a convention someone has to remember. Every tenant record is scoped to its workspace and site by design, so queries always filter by tenant: a query that forgot its tenant filter cannot be written, because the layer it goes through applies the filter itself. Deletions cascade, so a deletion leaves no orphaned record behind.
- Isolated search indexes. Each tenant's documents are searched separately, so a search cannot reach another tenant's documents.
- One permission layer. One shared permission layer checks every request, rather than each screen deciding for itself.
- Staff-only operator surfaces. Source, quality, serving and readiness interfaces require staff access and cannot be reached with a tenant role.
- Role-based access. A declarative matrix of eight roles, from taxpayer and bookkeeper to reviewer and a read-only auditor.
What is encrypted, and what is never logged?
Sensitive extracts are encrypted at rest: full national identifiers such as US Social Security numbers, and bookkeeper conversation content. Stored display fields keep only masked values, so a screen that shows an identifier shows the last few characters rather than the whole number.
Raw document contents, sensitive figures and conversation content are never written to logs. Taxpayer identifiers are redacted from prompts and from support surfaces before anyone or anything sees them, and bookkeeper message content is not visible in the administrative interface.
Can you see who did what?
Yes. Every high-risk action is logged with the actor, the tenant, the event type and the sources behind it, so an answer can be replayed later exactly as it was produced. Refusals are logged separately with their reason.
| Control | What it does |
|---|---|
| Hash-chained ledgers | Ledger entries are chained per tenant, and a command validates the whole chain. Altering one entry breaks every entry after it. |
| Signed export manifests | Export manifests are HMAC-signed. An unsigned or altered manifest does not verify. |
| Content-hashed proofs | A SHA-256 hash is recorded when a proof is generated; verification re-reads the stored PDF and compares in constant time. |
| Signed download links | Documents are downloaded through signed, expiring links rather than guessable paths. |
Logged actions include calculations, sourced answers, source releases and rollbacks, configuration changes, case finalisation and reopening, deletions, document downloads and privacy exports.
How are uploaded documents handled?
- Uploads are scanned for malware with ClamAV, with an option to refuse the file if the scan cannot run.
- Maximum upload size, maximum image dimensions and OCR timeouts stop oversized or malicious files from tying up the system.
- EXIF metadata is stripped from images on upload, so a photo cannot carry location or device data into the system.
- Rate limits on questions and generated answers bound abuse and cost.
What protects the AI from being misled?
TaxOrch treats uploaded and source text as data, never as instructions:
- Prompt-injection handling. Phrases such as "ignore previous instructions" and spoofed system lines are neutralised in uploads and in source documents, system and legal controls always take precedence, and bypass attempts are logged.
- Fetch guard. Source fetching allows public HTTP and HTTPS only. Localhost, loopback, link-local, reserved ranges and cloud metadata endpoints are blocked, and a name that cannot be resolved is refused.
- Output that fails safe. Model output is validated with bounded retries; output that cannot be repaired is discarded and never executed.
- Versioned, reversible changes. Every change is versioned and can be rolled back instantly, so an answer never shifts without a record.
- Numbers never come from the model. Every figure comes from a exact calculator, and nothing posts to the books without a person approving it.
Does TaxOrch hold security certifications?
How do I report a vulnerability?
- 1Email security@taxorch.comPlease do not use a web form or open a public issue.
- 2Describe itSay what you did, what you expected and what happened, with enough detail to reproduce it. If the detail is sensitive, say so first and we will arrange an encrypted channel.
- 3Hear backWe acknowledge within two business days, send an initial assessment with a severity and a plan within five business days, and update you at least every ten business days until it is closed.
In return we ask for reasonable time to fix the issue before publishing, a proof of concept rather than access to data that is not yours, no denial of service or social engineering, and testing against your own account wherever possible. Tell us how you would like to be credited.
Frequently asked questions
Is my tax data used to train AI models?
- Not without your explicit opt-in. The product is never improved with your data unless you opt in.
Is my data encrypted?
- Sensitive extracts, including full national identifiers and bookkeeper conversation content, are encrypted at rest, and stored display fields keep only masked values.
Can TaxOrch staff see my documents?
- Raw document contents and conversation content are never written to logs, identifiers are redacted from support surfaces, and access to sensitive documents is recorded in the audit trail.
Where do I report a security issue?
- Email security@taxorch.com. We acknowledge reports within two business days and send an initial assessment within five business days.