Security, and how to report a problem

You sign in with an eight-digit code emailed to your address, each time. There is no password to choose, to forget, to reuse somewhere else, or for anyone to steal from us — because we never hold one.

That is enforced rather than merely offered. The database rejects any sign-in that came from a password, so even if something managed to set one on an account, the session it produced would read nothing and write nothing here. The same goes for any other route in: only a Giraffe email-code sign-in is treated as you, and every other kind of session is refused rather than given the benefit of the doubt.

The emailed code is short-lived rather than open-ended: an hour after Giraffe sends it, it stops working. And there is a ceiling on how many sign-in codes can go out in an hour, so the sign-in form cannot be turned into a way to fill someone’s inbox.

Every project, item, Document and piece of history carries the account that owns it, and the database refuses to return a row to anyone else. It is not a check the app remembers to make before answering — it sits underneath the app, on the tables themselves, so a request that skipped Giraffe’s code entirely would get the same nothing.

There are three of those layers, and each one holds on its own so a mistake in one is not a breach. The first decides what a signed-in visitor can touch at all, and the answer is: read their own things, and nothing else — no signed-in account has permission to write to a table directly. Someone who isn’t signed in gets less than that: no table at all, and one thing they may ask for — a Document whose owner turned on a share link, fetched by the link itself. It comes back as the Document and nothing around it: not the project it came from, not who wrote it, nothing else in the account. Every other answer to a signed-out request is nothing.

The second decides which rows, by owner. The third is that a change cannot be made by writing to a table at all: it has to go through one of a short, fixed list of named pieces of database code, each of which checks ownership itself. There is no other way to write.

Every change to a project — yours or a connected assistant’s — writes a permanent entry saying what changed and who changed it. There is no button in the product that edits or deletes a past entry, and no request that asks for one: the history table accepts new rows and refuses everything else. Replacing an answer stops it being the current one; it does not stop it being part of the record.

Connecting Claude or ChatGPT hands it a key, and that key is deliberately much smaller than yours. It can read your projects, search them and change what is in them. It cannot delete a project, manage your connections or even learn that another connection exists, and it cannot tidy away the mark that tells you it wrote something. Privacy lists all six limits.

Each connection is a separate thing with its own Disconnect, identified by the signed token it presents rather than by the name it gives itself. Disconnect is checked on every single request afterwards, so a connection cannot get back in by fetching itself a fresher key, and it cannot let itself back in at all — only you can, signed in to Giraffe.

Deleting is irreversible, so a valid browser session on its own is not enough to do it. Giraffe emails a code to the account address and asks for that code and the word DELETE typed out, together, on one submit.

The typed word is a speed bump against a mis-click. The emailed code is the actual control: it means someone who got hold of an unlocked laptop or a copied session still cannot destroy the account without also holding the inbox.

Traffic between your browser and Giraffe is encrypted, and the browser is told never to try the site over a plain connection. What is stored is encrypted at rest by the cloud providers Giraffe runs on.

Everything you save is stored in the United States, on the US East coast. Privacy names every company Giraffe relies on, and is honest about which of them we can pin to a region and which we cannot.

To be direct, because a security page is exactly where this gets glossed over: this is not end-to-end encryption. Giraffe staff with database access could technically read stored content. We don’t use that access for anything beyond running and supporting the product, and we’d rather say it plainly than let you assume otherwise.

No security certification, and no audit by an outside firm. What has actually happened is a red-team pass: before opening the product up we attacked our own permission system and had outside AI reviewers attack it too. Five serious findings came out of that; all five were reproduced and closed first. That is a useful thing and it is not a certificate, and this page will not describe it as one.

No bug bounty and no payment for reports. Saying so up front is fairer than letting you find out after the work.

And no claim that your data is safe in the absolute. Everything above is a description of specific mechanisms, which is the strongest honest thing a page like this can be.

If you have found a way to reach data that isn’t yours — or anything else that breaks one of the mechanisms described above — email security@withgiraffe.com. Please tell us before you tell anyone else, and give us a reasonable chance to fix it.

A useful report contains: what you did, step by step, in enough detail that we can do it again; what you saw that you shouldn’t have been able to see; roughly when; and which address you were using — the website, the app, or the connection endpoint. A request and response, or a short recording, is worth more than a paragraph of description. If you think you know the cause, say so, but the reproduction is the part we need.

What happens next: one person reads that mailbox, and you will get a written reply from a person rather than a ticket number. Realistically that is a couple of working days — it is one person, so treat it as an intention rather than a guarantee, and do send a second message if you hear nothing. We’ll tell you what we found and what we are doing about it, and we’ll credit you by name if you would like that and the fix is public.

Use your own account. Stop at the point where you would be reading, changing or deleting someone else’s data — demonstrating that you could reach it is the finding; actually reading it isn’t needed and isn’t welcome.

Please don’t run load or denial-of-service tests, don’t send bulk automated scans, and don’t try to get at the people who work on Giraffe rather than the software — social engineering, phishing and anything physical are all out of scope. Don’t degrade the service for the people using it.

Report it privately first, and give us time to ship a fix before writing it up. If you stay inside all of that, we will treat your report as help, which is what it is.

What Giraffe stores and who it goes to is on Privacy. The agreement for using it is on Terms. Anything that isn’t a security problem — support@withgiraffe.com, or the form on Support.