Automatic system policies

TaruviBase attempts to synchronize a system policy when you create a supported resource. The unscoped policy has no-allow rules and therefore denies by default. A scoped policy contains the rules that apply to the site or app. Only the scoped policy is visible in the Console.

Automatic synchronization covers these resources. The initial scoped access is intentionally broad and requires immediate least-privilege review:

Database, Functions, and Analytics begin with wildcard access for every role. Storage uses category-specific defaults, shown below.

Product	Resource	Initial scoped access
Database	Non-system DataTables	Every role receives wildcard access; entity actions are read, create, update, and delete.
Functions	App and proxy Functions	Every role receives wildcard access; the entity action is execute.
Analytics	Saved queries	Every role receives wildcard access; the entity action is execute.
Storage	Assets buckets	read for all roles.
Storage	Attachments buckets	read, create, and update for all roles; Super Admin receives wildcard full access.

The precise action inventory is in System resource actions. System DataTables skip policy synchronization because they follow separate platform controls.

Synchronization is not the resource transaction

Resource creation can succeed while policy synchronization fails. The creation paths do not roll back the resource or return the synchronization failure to the Console or API caller, so check the policy yourself after creating a resource.

After creating a resource that gets an automatic policy:

1. Open Policy Editor and confirm that the expected scoped system policy is present and enabled. The Console exposes only this scoped policy.
2. Narrow the broad initial rules to only the access each role needs before assigning users or releasing the resource.
3. Open Live Testing and run one expected-allow and one expected-deny check.

If the policy is missing, stop the rollout and contact TaruviBase support with the site, app, and resource names so it can be resynchronized. Never create a duplicate custom system policy as a substitute: two independently maintained policies make it unclear which rules apply.

Updates and cleanup

System policies are edited, not recreated as custom policies. Review the full replacement definition before every save, then repeat both Live Testing checks.

Resource deletion and policy cleanup are separate steps, and their order varies:

Product	Deletion order	Failure state to reconcile
Functions and Storage	Policy cleanup first, then resource deletion	A cleanup failure is suppressed and resource deletion continues, leaving an orphan policy. If cleanup succeeds but resource deletion fails, a surviving resource is left without its policy.
Database and Analytics	Resource deletion first, then policy cleanup	A cleanup failure can leave an orphan policy after its resource was removed.

If a resource and its policy get out of step, contact TaruviBase support to reconcile them. Don't create a duplicate policy or re-create the resource to hide the mismatch. See Troubleshooting access policies for what to collect.