Simulate access before you ship

A simulation sends real requests through your project's gateway, identity checks and policies as each kind of caller, and records what happened at every step. Nothing is written: SQL writes run with every check and are then rolled back, and other writes stop right after their access checks.

#Who is simulated

Project settings that open doors are reviewed in the same run — for example open sign-up combined with rules that let any signed-in user change data.

#In the console

Open Simulation. The System map draws your project as a diagram: user types on the left, then the gateway, identity and policy checks, then each service and every table, collection, function, bucket and channel. Dashed lines show which tables and collections each function uses.

• Whole system runs every user type against every resource and action at once. Each action chip shows the worst result over all user types; pick one to see the result per user type.
• Step by step simulates a single request — one user type, one action, one resource — or everything one user type can try, and lights up the path it took, with where it stopped and how to fix it. These single checks are not added to your run history.
• Who can do what, Issues and Changes list the results of full runs, the problems found and what changed since the previous run.

#From the CLI and in CI

Sign in with sov login, pick the project, and run a simulation. --fail-on makes the command exit with status 1 when there are findings at that level or worse, so it can block a deploy.

sov sim run --fail-on critical

#Try a change before making it

sov sim change answers "what would this do?" for a policy or an SQL script. For a policy it lists who gains and who loses access; for SQL it runs the script with every check, rolls it back, and lists what it would add, drop or change — including tables that would be rewritten under a full lock.

sov sim change --policy-file draft.spl --name "staff edit books" --fail-on warning

#From code

Simulations act on the project's configuration, so call them as a team member (a console session or CLI token), not with an app user's session.

import { SovariaSDK } from '@sovaria/sdk'

const sovaria = new SovariaSDK({ baseUrl: process.env.SOVARIA_URL!, accessToken: process.env.SOVARIA_ACCESS_TOKEN! })
sovaria.setScope({ orgId: process.env.SOVARIA_ORG_ID!, projectId: process.env.SOVARIA_PROJECT_ID! })

const run = await sovaria.simulate.run({ filter: { resource: 'public.orders' } })
console.log(run.cases_total, 'checked,', run.cases_fail, 'wrong')

const preview = await sovaria.simulate.change({ kind: 'sql', sql: 'alter table orders add column note text' })

#Reading the results

#Plans

Every run counts, including single-request checks. See Plan limits for every limit.

#Common mistakes

• Testing only as a signed-in user. Visitors (__guest__) are where most leaks are — always include them.
• Treating "Needs review" as fine. An unconditional rule is usually wider than intended.
• Running simulations after the deploy. Run sov sim change on the draft, and sov sim run --fail-on critical in CI before deploying.