01
The browser never touches the database
Browser sessions are refused at the database, full stop. Queries live in your server functions; the page only ever calls your own endpoints. There is no client key to leak because there is no client path.
A browser session cannot query the database at all. Data moves from the page to a function you wrote, and the function, running server-side, is the only place a query can run.
By construction
What the platform enforces so you don't have to.
These are not settings you remember to turn on. They are how the platform is built, and they hold whether or not your code asked for them.
02
Functions run server-side
Your server code runs on the platform, never in the visitor's tab. Anything that needs a key, a role check, or the database happens there, in the same place your secrets live.
03
One isolated database per project
Every project gets its own database. There is no cross-project query path: a query in one app physically cannot reach another app's rows, yours or anyone else's.
04
Your schema is the contract
One declaration describes every table and who may reach it. The platform reads it and enforces it on every path: the browser client it generates for you, direct requests to the data endpoint, and the default path inside your own functions. A table you haven't declared is refused, not guessed.
05
Secrets never reach the page
Environment values are server-only unless you mark one public. Every deploy scans what would land in browser code and flags credentials before they ship.
06
Preview data stays out of production
A draft runs against its own isolated copy of the database. If a draft cannot be isolated, the platform refuses to run it rather than quietly touching live data.
07
Every deploy is reviewed
Deterministic checks run on every deploy: secrets in browser code, private files being served, known-malicious packages. Paid plans add an AI security review that reads your functions and explains each finding in your security dashboard.
08
Your functions can't be aimed at the inside
Outbound requests from your code go to public hosts only. A request to a private address, an internal hostname, an embedded password or an unusual port is refused before it leaves, with a named error. Preview functions cannot make outbound requests at all.
09
Refusals are typed, never silent
When the platform says no, it says why: a named error your agent can read and act on. Never an empty result that looks like success, never a fallback that hides what you should see.
10
Every sign-in is its own session, revoked instantly
Each device your agent signs in from is a session of its own: which device, where it was approved, what it may touch, when it was last used. Revoke one from Settings and its very next call is refused.
11
Identity is decided server-side
End-user sessions are signed per project, so a token from one app is invalid in another, and your own dashboard session lives in an HttpOnly cookie. Passwords are hashed with bcrypt. Nothing stored in the browser is trusted as proof of who someone is.
12
Uploads are private by default
A stored file is not a guessable URL. Every file serve passes a visibility check, and public is something you opt into per file, never the default for a whole folder.
13
Nothing sensitive exists before you sign in
A first deploy from your agent is anonymous: the app gets hosting, a database, files and logs, and nothing else. Secrets, email, payments, AI, schedules and custom domains switch on only after a human opens the claim link and signs in. An unclaimed app is removed, with its data, 3 hours after it was created.
14
Proven live, not just declared
Every sensitive route is probed with every kind of credential: anonymous, end user, your server code, you. The exact response is asserted in production. When policy and reality drift, we find out, not your users.
Your part
Your agent is told the rules.
The platform owns the boundaries above. Which of your users may do what is your app's own logic, and the seven rules for writing it safely are published where your agent reads, so it follows them without you asking. Your part is the human sign-off: claim the app, and decide who may do what.
What we tell your agent →Straight answers
What we don't claim.
No certification we don't hold
We don't carry our own SOC 2 certification and aren't pursuing one today. The services underneath us maintain theirs; we'd rather say that plainly than imply otherwise.
Not for regulated health data
somewhere is not intended for HIPAA-regulated protected health information, and we don't offer a BAA.
Card data never touches us
Payments go straight to the payment processor. Card numbers never reach our servers or your app, so that scope stays with them.
Nothing is unhackable
What we promise is narrower and real: the boundaries above are enforced by the platform, tested live, and where something is yours to handle we say so instead of pretending it isn't.
Security research
Found something? Tell us privately.
Good-faith testing helps us improve the platform. The following policy defines what is authorized under our Terms.
Good-faith security research is welcome and authorized when it follows this policy. You may test Somewhere-operated websites and APIs using accounts and projects you control, or whose owners have explicitly authorized your testing. Use synthetic data. You may test isolation between your own test accounts and projects; no advance approval is needed for testing within these boundaries.
This permission does not cover other customers' accounts, applications or data, or the systems of our infrastructure providers and other third parties. Do not perform denial-of-service or load testing, social engineering, credential theft, or actions that disrupt the service or damage data outside your own disposable test projects.
Use the minimum testing needed to demonstrate an issue. If you encounter someone else's data, credentials or secrets, stop immediately, do not explore further or retain or share the data, and report the issue privately. A report should include the affected URL, reproduction steps using your own test data, and redacted evidence. Never include working credentials or customer data.
We treat research that follows this policy as authorized under our Terms and will not pursue legal action against you for that research. This permission applies only to systems we operate; we cannot authorize testing on behalf of other parties. Please give us a reasonable opportunity to investigate and fix a reported issue before public disclosure. This policy does not offer a paid bug bounty.
Email security supportEmail us with "Security report" in the subject; no account is needed. You can also use Feedback in the dashboard or ask your agent to file a support ticket. Mark sensitive reports as such.
Want every rule and every boundary, written for technical scrutiny?
Security referencethe full text. Paste it into your AI and ask "is this good enough for what I'm building?"docs › security modelthe developer documentation for the model above
Try an anonymous deploy →