Starting the policy engine…
Who is asking?
The role and store group come from the application's login, never from the SQL. Pick them here to see how the same query is treated differently.
Example queries
:tenant_id for the caller's tenant
Press Ctrl + Enter to run. Only queries the policy allows are executed, in a read-only sandbox.
Choose an example or write a query, then press Check & run.
One query, three store groups
Every tenant-owned table must be filtered on the caller's tenant through the trusted :tenant_id parameter. The same SQL then returns different, isolated results for each store group. Writing another group's id as a literal is refused.
What each role may read
Access comes from the policy file: table and column grants plus classification labels. Aggregate only means the value may appear inside COUNT, SUM, AVG and similar, but not row by row or as a group key.
About this playground
SQLGuard Ninja checks SQL produced by an AI agent before it runs. It checks the SQL against a policy: which tables and columns a role may read, how classified data may be used, and which tenant's rows are in scope. It is open source (Apache-2.0).
What happens when you press “Check & run”
- The query is parsed and analysed for the selected role and store group. Nothing in the SQL can change the role or tenant.
- If any rule blocks it, you see why and how to fix it. Nothing runs.
- If it is allowed, it runs against a small synthetic retail database. The database is in memory, read-only and private to this session. Its authorizer allows only table reads and safe functions, and engine limits and a time budget apply.
What this demo is not
- It is not a security guarantee. Static analysis is one layer. Production systems still need database permissions, row-level security and timeouts.
- The benchmark numbers are internal. See the Benchmarks tab.
- No real customer data exists here. Names, emails and card numbers are fabricated, and card numbers use a published test range.