Authorization

Scrydon's single in-process authorization decision boundary — multi-tenant, fail-closed, and auditable.

Every protected Scrydon operation crosses one in-process authorization decision boundary in the service that owns the resource. The same model applies to users, workflows, API clients, and service-to-service callers.

How a decision is enforced

Each protected operation:

authenticates the caller;
resolves the organization-scoped resource;
evaluates a typed policy for the requested action; and
consumes a decision proof before reading, changing, or returning protected data.

Authentication establishes identity. Roles, OAuth scopes, service capabilities, workspace membership, reviewer status, and resource policy are evaluated as authorization facts.

Policy evaluation returns one of three outcomes:

Permit — the operation receives a one-time proof bound to the caller, action, and resource.
Deny — policy evaluated successfully and rejected the operation.
Indeterminate — policy could not produce a trustworthy answer, for example because an evaluator failed or returned malformed data. Scrydon fails closed and does not fall back to a second evaluator.

Scalar, row, and field decisions

The boundary supports:

exact-resource decisions, such as changing a workflow;
governed row filters for managed-table and ontology reads; and
governed projection plans that allow, mask, hide, or deny requested fields.

The policy engines behind the boundary can include Rego, storage ACLs, and application-specific permission models. They are implementation details; a caller cannot bypass the boundary by selecting another engine.

Multi-tenancy

Every target carries its organization and, where applicable, workspace. The authorization proof is bound to that exact target and cannot be reused for a different tenant or resource.

Tenant boundaries are reinforced by application target resolution, database ownership columns and constraints, and organization-specific policy inputs.

Workflow grants

Workflow executions use short-lived, server-side grants rather than trusting authority supplied in a workflow payload. A grant is bound to the relevant workflow execution and tenant. Secret access remains separately delegated and does not follow implicitly from workflow authority.

Grant creation, binding, rejection, expiry, and revocation are recorded in the audit log.

Audit evidence

Every permit, deny, and indeterminate result makes one durable authorization evidence attempt. Evidence records the decision identity, safe policy provenance, resource type, outcome, and correlations without storing raw policy inputs, row predicates, secrets, or returned data.

Evidence is relayed through the Unified Event Log, including its per-organization integrity chain and configured SIEM delivery. Delivery degradation is monitored and recoverable without changing the original policy outcome.