Security is a core requirement, not a feature.

This website

The site holds no tax data. It still has to set the example.

• Strict transport security and a content-security policy

  In place

  HTTPS 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 place

  A 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 place

  Every 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 site collects nothing

  In place

  No form, no analytics, no advertising or tracking script, no cookie. An account is created in the application, which has its own sign-in; this site only describes it.

  The waitlist form and its endpoint were removed when Keep opened; the content-security policy allows no third-party script.

The product's data

Keep is running, in early access. Each item says what is true of it today.

• Tenant isolation as a hard boundary

  In place

  Every 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.

  Every table but the sign-in's carries its account, the data layer refuses to run without one, and a test fails a schema that would let it. An account that is not yours answers as one that does not exist.

• Encryption in transit and at rest

  In progress

  TLS 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.

  In place: TLS everywhere; the database and the document store encrypted at rest by their providers; the SSNs, ITINs and EINs Keep holds about a person or business each sealed under a key of its own, every opening logged. Not yet: the master key is a deployment secret, to be replaced by a managed key service; and a payer's EIN or an account number as read from a document sits in that document's reading, not sealed separately.

• Raw documents protected at least as strongly as the database

  In progress

  Original uploads live in object storage under per-account keys, served only through signed, time-limited links, never publicly cacheable, never at a predictable address.

  In place: a private store with no public address, random names nobody could guess, and a read link that lasts five minutes and is issued only to a signed-in member of the account. Not yet: an encryption key per account; the store's own encryption at rest covers every document alike.

• Sensitive-data minimization

  In progress

  Nothing is collected because it might someday be useful. Identifiers are not duplicated across records, are kept out of logs, and are redacted from diagnostics.

  In place: from a document, only the last four digits of your own number are kept; a copy you export carries last four digits only; the application is written to log that something failed, never what was in it. Not yet reviewed by anyone outside the team.

• Backups that restore

  Planned

  Encrypted, 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.

  Not done. No restore has been rehearsed, and the objectives (recovery point within 24 hours, recovery time within 4 hours, a restore tested quarterly) are not yet met. Until they are, keep your own copy of anything you upload.

Who can get in

Strong authentication for customers; narrow, logged access for everyone else.

• Multi-factor authentication

  In progress

  Available to every customer and required for Business Keep accounts and for every administrator. Account recovery that does not become the weak door.

  In place: two-step verification with an authenticator app and backup codes is offered to every customer, and a business account opens only for a sign-in that has it. A password is at least 15 characters and checked against known breaches. Not yet: Keep has no administrator accounts of its own to hold to the rule, and account recovery has not been reviewed.

• Internal access without a god mode

  In progress

  Employees, 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.

  In place: the application has no administrative screen — nobody at Gideon can open an account through Keep — and one application, Gideon Tax, reaches an account only while its owner has that turned on, every read of an identifier logged. Not yet: logged, reviewable access for the people who operate the database and the hosting.

• Background checks for people with access to taxpayer data

  Planned

  Anyone 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

  In progress

  No 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.

  In place: no AI system has any access to Keep, and documents are read by ordinary software inside Keep, not by a model. The permission model for an AI agent is designed and not built, because nothing uses it.

Assurance

Claims are cheap. Audits and tests are what make them worth reading.

• A Written Information Security Plan

  In progress

  The 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

  Planned

  A third-party test of the product before launch and annually after, with findings tracked to closure.

  Not yet engaged. Keep opened in early access without one; it is to be done before billing begins.

• SOC 2

  Planned

  A Type 1 report on the design of controls, then a Type 2 on their operation over time.

  Not yet engaged. Type 1 targeted after billing begins; Type 2 after a full period of operation.

• A written incident-response plan, and honest notification

  In progress

  Who 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

  In progress

  Structured 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.

  In place: the owner of an account takes one documented file of everything Keep holds, with its history; the export is logged, and identification numbers leave by their last four digits. Each document's file is downloaded from its own page. Not yet: the files inside the export, a second factor before it, and a notice when it happens.

• Deletion, and what retention honestly means

  In progress

  Customer-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.

  Done by hand today: write to privacy@gideonkeep.com from the address you sign in with. A button in the application, and the written retention schedule, are not done.