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.
How long authority lasts
A workflow never holds a standing credential. Each call it makes to the platform carries a new grant, minted for that one call, so no grant outlives the operation it was issued for.
| Credential | Lifetime | Bound to |
|---|---|---|
| Platform call grant (minted by a running workflow) | 60 seconds by default. The platform refuses any grant issued for longer than 5 minutes. | The calling service, the single operation and its scope, the organization, workspace and environment, and the Run As identity when one is set. |
Service-account token, client_credentials | 5 minutes, fixed. | The account's scopes and environment. |
| Service-account token, machine-token grant | 1 hour by default, 8 hours at most, until your organization sets its own policy. Always clamped by the organization's maximum and your deployment's ceiling. | The account's scopes and environment. |
A grant presented after it expires, by a different service, or for a different operation or scope is refused. Service-account token rules, including the credential policy, are in Service accounts → Token lifetime.
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 Audit Log, including its per-organization integrity chain and configured SIEM delivery. Delivery degradation is monitored and recoverable without changing the original policy outcome.