Security
Security is a core requirement, not a feature.
Every commitment, with its status.
This page does not describe a finished system. It lists what Keep is committed to, and for each item whether it is true today, being built, or planned with its prerequisite named. Marketing copy does not get to promote an item — only doing the work does.
- In place
- 4
- In progress
- 2
- Planned
- 14
This website
The site holds no tax data. It still has to set the example.
Strict transport security and a content-security policy
In placeHTTPS is required for two years including subdomains and the site is eligible for browser preload lists. The content-security policy refuses every third-party script, every frame and every form target but our own; clickjacking is refused twice over.
Set in next.config.mjs; verifiable with curl -I on any page.
A published vulnerability-disclosure channel
In placeA security.txt at the standard well-known address names the contact, the policy and an expiry, so a researcher does not have to guess where to write.
/.well-known/security.txt, RFC 9116.
Dependency and supply-chain scanning
In placeEvery pull request and every week, the dependencies are audited for known vulnerabilities and the build is run; dependency updates arrive as reviewable pull requests rather than surprises.
GitHub Actions on pull requests and a weekly schedule; Dependabot for npm and Actions.
The waitlist form is not an open door
In placeBots that fill every field fill a field people never see and are quietly dropped; oversized requests are refused; the address is never written to a log in full.
Honeypot and size limit in the API route. Platform rate limiting is a firewall rule, listed below.
Platform rate limiting on the form
PlannedA per-IP limit on the waitlist endpoint at the edge, so a flood never reaches the function.
A Vercel firewall rule on /api/waitlist; set in the project dashboard, not in code.
The product's data
Keep is being built. These are design requirements, not descriptions of a running system.
Tenant isolation as a hard boundary
PlannedEvery data-access path carries the owning account and checks it server-side; nothing relies on front-end filtering. Compromise of one account, token, link, credential or integration must not expose another taxpayer.
Product architecture requirement; row-level ownership enforced in the data layer from the first table.
Encryption in transit and at rest
PlannedTLS for every connection. Every stored field encrypted at rest. Especially sensitive identifiers — SSN, ITIN, EIN, bank details — encrypted at the field level with envelope keys, decrypted only on demand, with each decryption logged.
Product architecture requirement; the identifiers get a separate key hierarchy from the rest of the record.
Raw documents protected at least as strongly as the database
PlannedOriginal uploads live in object storage under per-account keys, served only through signed, time-limited links, never publicly cacheable, never at a predictable address.
Product architecture requirement.
Sensitive-data minimization
PlannedNothing is collected because it might someday be useful. Identifiers are not duplicated across records, are kept out of logs, and are redacted from diagnostics.
A rule for every schema review, written into the data-model guidelines before the first migration.
Backups that restore
PlannedEncrypted, cross-region backups with the same per-account keys as the data, and a restore that is actually tested on a schedule — with recovery objectives written down and met.
Committed before launch: recovery point within 24 hours, recovery time within 4 hours, restore tested quarterly.
Who can get in
Strong authentication for customers; narrow, logged access for everyone else.
Multi-factor authentication
PlannedAvailable to every customer and required for Business Keep accounts and for every administrator. Account recovery that does not become the weak door.
Product requirement, with the identity provider chosen for it.
Internal access without a god mode
PlannedEmployees, support staff, automated services and AI systems receive no broader access than the task needs. Administrative reads of taxpayer data are limited, strongly authenticated, explicitly authorized, logged and reviewable.
Product requirement; the audit log is the first internal tool, not the last.
Background checks for people with access to taxpayer data
PlannedAnyone who can reach identifying or financial information is checked before they can.
An organizational policy, adopted before the first hire with production access. Written into the information-security plan.
AI access scoped, and documents treated as data
PlannedNo AI agent receives unrestricted access by default. Grants are scoped by taxpayer authorization, category, action, duration, application and purpose. Text inside an uploaded document is never an instruction.
Product requirement; the permission model is designed before any model touches a document.
Assurance
Claims are cheap. Audits and tests are what make them worth reading.
A Written Information Security Plan
In progressThe plan the FTC Safeguards Rule requires of tax preparers and that IRS Publication 4557 describes: named responsible people, a risk assessment, administrative, technical and physical safeguards, an incident-response procedure, and a review schedule.
Drafted against the IRS template; under review before adoption.
Independent penetration testing
PlannedA third-party test of the product before launch and annually after, with findings tracked to closure.
Engaged before the product opens to customers.
SOC 2
PlannedA Type 1 report on the design of controls, then a Type 2 on their operation over time.
Not yet engaged. Type 1 targeted after launch; Type 2 after a full period of operation.
A written incident-response plan, and honest notification
In progressWho does what when something goes wrong, including the notifications the IRS, the FTC and state law require — and a commitment to tell affected customers plainly.
Part of the information-security plan draft.
Your controls
Export and deletion are customer features, with retention stated plainly.
Export of everything, in a documented form
PlannedStructured records, tax attributes and carryforward histories, Gideon's interpretations, provenance, filing history — and copies of the raw documents. Comprehensive exports may ask for recent reauthentication or a second factor, use expiring links, and notify you.
Product requirement; the export format is designed alongside the data model, not after it.
Deletion, and what retention honestly means
PlannedCustomer-owned Keep data can be deleted where legally and operationally permitted. Records Gideon must retain as an e-file provider, filing logs, compliance and payment records may differ, and Keep will say which is which.
Product requirement; the retention schedule is part of the information-security plan.
What we will never do
- Sell your data, or share it with advertisers or data brokers.
- Use your tax records to train AI models — ours or anyone else's.
- Read your documents for anything beyond the tax interpretation you asked for.
- Respond to a subpoena without first notifying you, unless legally prohibited.
- Let convenience weaken a security boundary around taxpayer data.
Reporting a vulnerability
Found something? Email security@gideonkeep.com, or read /.well-known/security.txt. We respond quickly, and we do not pursue researchers acting in good faith. This page is updated as each item changes status.