Privacy policy

Draft v2 — prepared in-house; attorney review is scheduled before the paid launch.

Version 2.0 Effective: [operator-confirm: launch date]

SEE is run by [operator-confirm: Sai Arun Labs] ("we", "us"). This policy says exactly what information SEE holds when you use it, why, who else touches it, and what you can do about it. It is written from what the service actually does — if something is not described here, the service does not do it.

Who SEE is for, and where it operates

In short: SEE is a United States service, offered to people in the United States.

SEE is provided from the United States and is offered to users in the United States. If you are outside the United States, please do not create an account. We are a small operation: the people who build SEE are the people who read its messages and run its systems.

What we hold, and why

Your account

In short: your email address, a scrambled form of your password, and your workspace name if you set one.

• Your email address. It is your sign-in name, and how we tell your account from everyone else's.
• Your password — never in readable form. We store only a salted cryptographic hash of it, made with a modern password-hashing method. We cannot read your password, and neither could anyone who somehow got hold of the database.
• The name of your workspace, if you set one.

Your permission slips

In short: the spending limits you set for each agent, in every version you save.

The limits you set for each agent: the agent's name, the kinds of spending allowed, the most per spend, the most per period, the currency, when the slip starts and ends, the amount above which the agent must ask you first, and whether the slip is on, paused, or ended. Every version you save is kept, because each receipt points at the exact version it was checked against.

Your spend records

In short: a record of every spend an agent asks about — what the agent reported, what the decision was, and when.

Every time an agent asks to spend, we keep the record: the agent's name, the amount and currency, the kind of spend, and the seller name and description the agent reported — those come from the agent, not from us, and we do not verify them. We keep the decision (allowed, allowed by you, stopped, or waiting for you), the reason for it, and the times. When an agent marks a spend as completed, the record also seals what the agent reports at completion: any note it adds, the seller's own reference for the purchase if it gives one, and the completion time it claims. Like the seller name and description, these come from the agent, not from us.

Your approvals

In short: when you allow or refuse a spend, the record names your account as the one that decided. That is deliberate — a receipt is meant to prove who said yes.

When you allow or refuse a spend, that decision is sealed into the record, naming the approving account by its email address. If an API key approved it instead, the record names that key's label — use a label that does not identify you if you would rather it did not. Because approvals are sealed, this naming cannot be edited afterwards; the section on deleting your account explains what happens to it if you leave.

Messages you send us

In short: if you write to us, we keep the message and the name or address you chose to include.

If you use the feedback page or write to us, we keep your message and whatever name or email address you chose to include, so we can read it and reply. One caution: if you are signed in when you send a message from the feedback page, the message is linked to your workspace, even if you leave the name and email fields blank — so do not treat the feedback page as anonymous while you are signed in. Messages sent while signed out carry no such link.

Technical bits

In short: one sign-in cookie, abuse counters kept in memory, and request logs that never contain what you sent.

• One cookie. Signing in sets a single cookie named see_session. It holds a random token; we store only a cryptographic hash of it. It lasts 7 days, your browser sends it only to us, and signing out ends it on our side right away. It is how the service knows you are signed in — without it, sign-in cannot work. There are no other cookies.
• Abuse prevention. To slow down abuse and repeated sign-in attempts, the service uses the network (IP) address of a request while handling it and keeps simple abuse counters in memory while it runs. IP addresses are not written into the database.
• Request logs. Our logs record the method, the path, the result, and how long a request took — never request contents, passwords, or keys. Logs exist to run and secure the service, and for nothing else.
• Connection records. When an agent is set up with your account, we keep a small record of the setup request — the workspace and slip it names, when it happened, and the reference the connecting app supplied with it — so that a retried request cannot create a duplicate.

Card numbers and credentials

In short: SEE never processes payments, so never put a card number into it.

We never see or hold your card numbers or bank details through the service itself, and no field in SEE asks for them. Do not put card numbers, bank credentials, or passwords into a seller name, a description, a completion note, or any other text sent to SEE — agents should never be given such information to pass on. If a card number does reach us, tell us: before a record is sealed we will remove it, and we treat its arrival as a security incident and investigate how it got in. A record that has already been sealed cannot be edited — that is what makes it evidence — which is why keeping card numbers out matters.

What we never do

In short: no selling information, no trackers, no marketing email — in fact, no email at all.

• We do not sell your information. We have never sold it, and we will not.
• No advertising, no trackers, no analytics services. The pages we serve carry no third-party code at all — everything comes from us.
• We never hold your money. SEE checks spends; payments happen outside SEE, the way they do today.
• We send no marketing email. In fact the service sends no email at all — if you ever receive an email claiming to be from SEE that asks for your password or a key, it is not from us.

Who else touches the information

In short: our host, our signing-key service, and two timestamp authorities that only ever receive a fingerprint. Nobody else, unless the law requires it.

A few companies process pieces of it so the service can run:

• Render hosts the service and its database, so the information above is stored on Render's machines.
• Amazon Web Services (AWS KMS) holds one of our two signing keys. When a receipt or checkpoint is signed with that key, the statement being signed is sent to AWS over an encrypted connection so AWS can produce the signature. The key itself never leaves AWS.
• DigiCert and Sectigo run timestamp servers. When a record is sealed, and when a checkpoint is witnessed, they receive only a cryptographic fingerprint (a hash) of what is being timestamped — never the record itself and never your details. A hash cannot be turned back into the record.
• OpenTimestamps calendars are public servers that can witness a checkpoint fingerprint into Bitcoin. When that witnessing is used, they receive only the fingerprint, which reveals nothing about any spend.

Nobody else receives your information from us, unless the law requires it (a court order, for example). If that ever happens and we are allowed to tell you, we will.

Receipt bundles you share

In short: a bundle contains the sealed record, including who approved a spend. Bundles you paste into our checker are checked during that request and are not stored.

You can export a receipt bundle and check it yourself, or hand it to someone else — an auditor, say. A bundle contains the sealed record, including the approver named in it. Once you have exported a bundle, what you do with it is up to you. Bundles pasted into our public checker are checked during that request and are not stored.

How long we keep things

In short: while your account is active; sessions for 7 days; backups for no more than 30 days.

• Account, slips, and spend records: while your account is active.
• Sign-in sessions: 7 days, or until you sign out.
• Feedback and contact messages: while they are useful for reading and following up. Ask us to delete yours and we will.
• Backups: we back up the database nightly, and backup copies are kept for no more than 30 days before being replaced.

Deleting your account

In short: ask us, and a person does it within 30 days. The things that identify you are deleted or unlinked; sealed evidence is kept only in de-identified form, on the schedule below.

There is no delete button in the app yet, so a person does this, not a program. Email [operator-confirm: support@saiarunglabs.com] from the address on your account and ask us to delete it. Once we have confirmed the request is from you, a person carries out the steps below within 30 days:

• The identity layer is deleted or de-linked: your account, your sign-in sessions, and your API keys are removed, so nothing in SEE points from your records back to a live account.
• Your slips and spend records are deleted, or irreversibly unlinked from you. Where a record forms part of the sealed, verifiable history, it is retained in de-identified form: the account and its links are gone, and the record can no longer be tied to you through SEE. One honest exception: a name written inside a sealed record when it was made — the approver named on an approval — cannot be removed without breaking the record itself, so it stays in that sealed copy. A receipt you already exported still checks out, because checking never depended on us.
• De-identified sealed records are kept for five years from the date of the spend, because they may be needed to resolve a dispute about it. After that they are deleted, unless a dispute or a legal duty requires keeping a specific record longer.
• Backup copies age out within 30 days.

If you only want your agents to stop spending, you do not need to delete anything: pause all agent spends, or end each slip.

If your information is exposed

In short: we will tell you without unreasonable delay, and tell regulators where the law requires it.

If a security incident exposes your information, we will notify affected users without unreasonable delay, say what was involved and what we are doing about it, and notify regulators where the law requires it. In North Carolina, the Attorney General's Consumer Protection Division is notified whenever we notify users.

Your other rights

In short: everything is already on screen; email us for anything else, and we will honour the rights your law gives you.

• See your information. Everything in your account is already on screen — slips, receipts, approvals. You can export receipt bundles yourself at any time. If you want everything we hold about your account gathered in one place, email us.
• Fix it. Slips are yours to change at any time. If your email address needs to change, contact us.
• Depending on where you live, the law may give you further rights, such as objecting to processing or taking your information elsewhere. Email us and we will honor them.

Who can use SEE

In short: adults only.

SEE is for people aged 18 and over.

Keeping information safe

In short: hashes instead of readable secrets, encrypted connections, and two independent signatures on every receipt and checkpoint.

Passwords are stored only as cryptographic hashes. Keys are stored as a hash too, plus a short prefix so we can find the right one — the prefix alone cannot sign anything in. Connections to SEE are encrypted. Every receipt and checkpoint carries two independent signatures, made with two separately held keys, so no single key can rewrite history on its own. Access to the systems that run SEE is limited to the people who operate it.

Changes to this policy

In short: the new version appears here with a new effective date before it applies; big changes are also noted on the sign-in page.

If we change this policy, the new version will appear on this page with a new effective date before it applies. If a change is big, we will also note it on the sign-in page.

Contact

In short: one address for privacy questions; security reports have their own and go to the front of the line.

Questions about this policy or about your information: [operator-confirm: support@saiarunglabs.com]. For security problems, see the contact page — they have their own address and go to the front of the line.