Access decisions

An access decision evaluates a principal, resource, action, and optional condition inside one app and tenant scope.

Input	Meaning
Principal	The caller ID, roles, and principal attributes used for the decision. Runtime checks use the authenticated caller. Console Live Testing uses the selected active site user.
Resource	An entity:name kind, record ID, and any resource attributes required by conditions.
Action	The exact operation being evaluated, such as read, update, or execute.
Condition	A comparison over principal attributes, resource attributes, or roles.
Result	EFFECT_ALLOW or EFFECT_DENY for each requested action.

Authentication and authorization are separate: a valid credential establishes the runtime authenticated caller, but it does not grant an action by itself. In Live Testing, an administrator can check a decision as any active site user. Application code always acts as the signed-in caller.

The site and app decide which policies apply. A site user with no App Role, an explicit deny, or an error while evaluating the policy is denied. One exception: if a conditional rule can't be turned into a row filter, a Database list can come back unfiltered. Check both Live Testing and an actual Database list before release, and if rows aren't narrowed, contact TaruviBase support. See Security and limits.

Use one concrete resource and action when testing. A condition evaluates the attributes supplied for that decision, not a broad assumption about a role.