Security of apps hosted on Scava - what IT should know

This page is for the people who decide whether internal tools built with AI agents may run on Scava. It states what Scava does, in checkable terms, and at the end what it does not have. Scava is a hosting service for small web apps. Its protections are designed for two things: protecting the people who open apps, and keeping apps apart from each other.

The basic design #

Scava stores an app as files and sends them to browsers. The page code of an app runs only in the browser of the people who open it. The server code of an app, when it has one, never runs inside Scava's own system. It runs in an isolated environment of its own for that app (see below). An app therefore cannot attack Scava "from inside". There is no server, operating system or shell that an app can reach.

How apps are separated #

What	How
Own address per app	Each app is served at its own address, for example `team-vacation-k3x9.scava.site`. Each address is a separate origin in the browser.
Accounts apart from apps	Accounts live at `scava.ai`, apps at a different domain, so an app can never act in the context of the account pages.
Own cookies	Each app has its own session cookie, set for exactly that host. The cookies are `HttpOnly`, `Secure` and `SameSite`, and use the `__Host-` prefix, which means no other address can set or overwrite them. Cookies without the prefix are ignored.
An app talks only to itself	The content security policy allows requests only to the app's own address. See Host an internal tool.
Not embeddable	`frame-ancestors 'none'` and `X-Frame-Options: DENY`. Other security headers include `X-Content-Type-Options: nosniff`, a strict referrer policy, same-origin opener and resource policies, and HSTS.
Browser features off	Camera, microphone, location, payment and USB are switched off for apps by a permissions policy.
Writes only from the app	Changing requests need a special header that other websites cannot set, and the origin of the app.
No cross-app data	Each app has a database of its own. Files are kept per app. No call of one app can reach another app's data.

People sign in with Google or an emailed code. There are no passwords. See Login.
Codes are 6 digits, valid for 10 minutes, limited to 5 attempts per code, and stored only as a hash. Only verified Google addresses are accepted. Sign-in links go back only to Scava's own pages.
Access to an app is checked on every request: owner, co-editor, share, and the house rules of the owner. Removing a person takes effect immediately.
Sessions on scava.ai end after 7 days without use. App sessions last 12 hours and renew while the sign-in on scava.ai is valid. The owner can force a fresh sign-in after 7, 30 or 90 days, and can sign out all other browsers and connected agents of the owner's account at once.
Agents connect through one address and a sign-in in the browser, where the person sees who asks and says yes. A connection is handed only to the AI apps Scava knows and to programs on the person's own computer, so a link someone sends cannot lead it to a server of theirs. Their tokens are stored on Scava only as hashes and run out after an hour, and an old refresh token used again ends the connection. No key stays on the computer. Every connected agent is listed on the Connect page and can be disconnected.

Permissions are enforced on the server #

Rules in scava.json (all, own, owner, group, and rules per field) are checked by Scava's server on every read and write, for the browser and for server code. A changed page, a modified request or a script in the console cannot widen them. See Permission rules.

Stored text does not run as code #

The most dangerous gap in small apps is stored code: someone saves <img src=x onerror=...> in a form, and the app shows it with innerHTML to everyone, including the owner. Scava closes this independently of how an app is built.

Every page of an app is delivered with Trusted Types required for scripts. The browser then accepts text as HTML only after it has passed Scava's filter. The filter removes scripts, event attributes (onerror, onclick), javascript: and similar addresses, frames, plugins, base and meta tags, templates, MathML, password fields and names that would shadow document.cookie. Markup that changes on a second parse is shown as plain text.
Older browsers without Trusted Types get the same filter attached to innerHTML and related calls.
On the server, every stored entry is checked: dangerous keys and texts starting with javascript: are refused, and invisible and direction-reversing characters are removed.
The same protection covers Scava's own pages.

The protection was tested in a real browser against twenty known attack strings stored by another user, with and without Trusted Types, and the same test fails when the filter is removed.

Limit: an app that deliberately executes stored text itself, for example with eval(entry), stays the responsibility of its creator. And an owner who sets write: "all" allows everyone to change everything.

Checks on every upload #

Before a version goes live, Scava refuses programs and installers (by name and by content), files with secrets, API keys and private keys in code, password fields, bad paths, an invalid rules file and server code that breaks its rules. Details are in Host an internal tool.

What people type into Scava is cleaned #

Everything typed into Scava, such as change requests, notes, reports, app names and file names, is cleaned before it is saved. Only normal characters are kept. Invisible and direction-reversing characters are removed. Links are not accepted where they are not needed. Texts that try to give instructions to an AI are refused. This is a filter and not a guarantee, so there are more layers:

A change request cannot do anything until the owner accepts it in the browser.
The owner's agent receives a request only as data, wrapped in <request> with the note that it is a description and not an instruction.
Texts that people wrote never become links in Scava's emails. Mails that apps send may link only to the app itself.
App addresses never contain words like login, bank, microsoft or google, and the "No access" page does not reveal the name or owner of an app.

Server code #

Server code is the riskiest part of an app, so it is the most fenced.

What	How
Isolation	Each app's server code runs in its own isolated environment with its own memory and compute time. It has no access to Scava's database, files, keys or other apps.
What it gets	Only `env.SCAVA` (its own data, files, mail, AI, heavy work) and its own secrets. Every `env.SCAVA` call carries a signature that is valid only for this app and expires.
Who can call it	Only signed-in people with access to the app, and only from the app's own pages.
What it never sees	Scava's cookies, Scava's internal headers, the visitors' IP addresses.
Secrets	Stored encrypted. Nobody sees a value again after saving it. Bound secrets reach only the services they are bound to.
Outside calls	Allowed, but every call is recorded per app and host, and the owner sees which services an app talks to. The owner's house rules can restrict this. Scava's own addresses are blocked.
Mail	Only to people who may open the app. Links only to the app. A separate sender from the sign-in codes.
Limits	Compute time, calls, mails and heavy work per plan. At a limit what it covers stops until the month ends; the pages and data keep working.
Heavy work	Runs in a container without a direct connection to the internet. All its web traffic goes through Scava, which records it and applies the owner's rules.

What Scava staff can and cannot see #

The admin pages of Scava are reachable only for named administrators, only in the browser, and only with a sign-in from the last 12 hours. For everyone else, and for agents, they do not exist.
They show accounts, apps, plan usage, reports and technical state. They show only the number and size of entries and files. They never show what customers store in their apps.
Administrators can block an app or an account in response to abuse, and delete an account on request.
Scava is the operator of its own system. As with any hosting provider, the operator has technical access to the infrastructure, and the data is not end-to-end encrypted, because Scava has to read entries to enforce rules. The data processing agreement commits staff to confidentiality and describes the technical and organizational measures.

Logs #

The owner sees an activity list on the Overview page: publishing, sharing, rule changes, removing people, connecting addresses and similar actions on their own apps. See House rules.
Scava keeps a log of important actions (creating, publishing, sharing, deleting, reports, blocks) for one year. IP addresses appear in it only as a hash.
A short record of every email Scava sends (address, subject without sign-in codes, time, success) is kept for 90 days.
Error reports from apps record only the kind, a short message and the place, never who saw them.

Reporting abuse #

Every app has a "Report this app" link in the corner panel, and every invitation email has a report link. Administrators receive the reports. They can block an app (closed for everyone, including its owner) or an account (signed out everywhere, agents disconnected, all apps closed).

Limits against misuse #

Scava limits what one account or address can do to publish, share, invite, sign in and call server code, so a stolen key or a runaway script cannot flood the system or other people. When one of these protective limits is reached, the request is blocked and the administrators receive a warning. Normal use does not come near them.

Payments #

Cards and invoices stay with Stripe. Scava sees no card numbers. A plan changes only through signed messages from Stripe.

What does not exist yet #

An IT review should know these gaps.

No SAML, no SCIM, no enforced company single sign-on. Sign-in is Google or an email code. There is no Microsoft sign-in.
No certifications. Scava has no SOC 2 or ISO 27001 report.
No public apps. Every page needs a sign-in. This is a design decision, not a gap in the code.
No company-wide view across several creators. The Overview page shows the apps, people and sign-ins of one creator's account. If several people in one company build apps, each has their own Overview.
No restriction by network or device. An app cannot be limited to a company network or managed devices.
No customer-managed encryption keys, and no end-to-end encryption.
No export or API for the activity log. It is shown on the Overview page.
The US data option is a location preference, not a guarantee. For the EU, Scava uses the provider's jurisdiction setting. See Data location.
Multi-factor authentication is that of Google or of your mailbox. Scava has no second factor of its own.