security
What we hold, and what we don't.
Last updated 12 July 2026
Shoti carries one sentence from your agent to your team. That sentence is the whole payload. This page says exactly what reaches us, where it lives, how long it stays, and who can reach it — including the parts that are not finished yet.
the payload
What your agent sends us
When your agent calls shoti_broadcast, we receive:
- The intent string your agent wrote. One line, plain English. For example: "Refactoring auth.ts to use JWTs instead of session cookies."
- File paths, if your agent sends them. Paths only.
- A timestamp, your team identifier, and the repository name.
- Optionally, a decision category and which tool the agent is running in.
This is a property of the wire format rather than a policy we promise to honour: there is no field in the broadcast schema that can carry file contents. The files array is a list of paths, capped at 200 entries of 1024 characters each. There is nowhere for a diff to go.
the catch
Scope detection stays inside your team
When a second agent declares a scope that overlaps one already active, Shoti raises a catch and holds that agent's next tool call until a human on your team acknowledges it.
That comparison runs server-side, inside a single database transaction, against your own team's rows and nothing else. It does not call out to any other service, and it does not compare your team's scopes against anyone else's.
storage
Where it lives
- Broadcasts are stored in a Postgres database hosted on Neon, in AWS
us-east-1(Northern Virginia). - The API runs on Fly.io. All traffic between your agents and
api.shoti.aiis encrypted in transit; plain HTTP is redirected to HTTPS. - We do not sell your broadcasts, share them with a third party, or use them to train a model.
retention
How long we keep it
Honestly: for as long as your team exists. Shoti does not currently delete broadcasts on a schedule. There is no automatic expiry, and we would rather say so than publish a retention window we do not yet enforce.
A scheduled retention window is work we intend to ship, not work we have shipped. When it lands, this page changes first.
access
Who can see your broadcasts
Only members of your Shoti team. Every read and every write is scoped to the team you are authenticated against, checked server-side on each request.
To be precise about the mechanism, because the distinction matters to anyone evaluating this seriously: that scoping is enforced in the application layer, on every query. We do not currently rely on database row-level security. If your threat model requires isolation enforced by the database itself, that is a fair question to put to us, and the honest answer today is that we do not do it.
There is no shared, team-wide API key that could be copied out of a config file and reused. People sign in with Google or GitHub, which issues a session token bound to that person. Agents authenticate with a separate bearer token bound to that one agent, and revoking it takes effect within about a minute.
the desktop app
What the app talks to
The desktop app connects to two hosts, both ours:
api.shoti.ai— everything the product does.dl.shoti.ai— checking whether a newer version of the app or the CLI exists. This runs quietly on launch.
There is no third-party analytics, telemetry, session-recording, or crash-reporting service in the app. Nothing about what you broadcast reaches anyone but us and your team.
disclosure
Reporting a vulnerability
Write to hello@shoti.ai. We acknowledge within 72 hours, and we will agree a disclosure timeline with you before publishing anything.
If you would rather talk to a person first, that is Abry.