Clearance and ACLs,
enforced by physics.

Astry maps every person to a workspace role and reads the access list on every file. Before the model runs, it builds a per-request projection of only what the asker is cleared to read. Missing membership means no access, by default.

How a request is authorized.

Authorization is decided in plain code, before the model exists for the request. The same order runs every time, whatever the question asks.

01
Verify identity
The asker signs in through your identity provider over OIDC: Okta, Microsoft Entra ID or Google Workspace. They are who their provider says they are, with no second login.
02
Resolve the role
Astry reads the asker's workspace membership and role: viewer, editor, admin or owner. Membership is the source of truth, and no membership means no access.
03
Read the access list on every file
Each file carries an access list, drawn from its document frontmatter and a database trust policy. Permissions inherit from the source system at ingest, so they match the original.
04
Build the projection
Only the cleared files are copied into a throwaway per-request sandbox. Everything else is physically absent, not filtered out after the fact.
05
Record the decision
The role, the files cleared and the action taken are written to an append-only log. The record outlives the request.

Clearance you can trace.

Access is not a policy the model is asked to honor. It is a boundary built from your workspace roles and the access lists already on your files.

Inherited, not duplicated

Each file's access list inherits from the source system at ingest. Astry reads it at request time and keeps no second copy to drift out of sync.

Absent, not hidden

Files you are not cleared for are never copied into the request. The model works inside a sandbox of cleared files only, so it cannot read or even name what it was not given.

Single sign-on

Sign in through Okta, Microsoft Entra ID or Google Workspace over OIDC. Directory provisioning keeps roles in step with your identity provider.

Four workspace roles

Viewer, editor, admin and owner set what a person can read, change and govern. File-level access lists scope sensitive material further still.

Physical enforcement

Enforcement happens when the projection is built, before any model is loaded. The model cannot read what was never copied into its sandbox.

See the Trust Layer

Every access logged

Every role check and every file cleared lands in an append-only record. Logging never blocks a request, so the trail stays complete.

See the audit log

The access model, on one page.

Identity: OIDC single sign-on (Okta, Microsoft Entra ID, Google Workspace).
Roles: Four workspace roles — viewer, editor, admin, owner.
File ACL: Document frontmatter plus a database trust policy, inherited from the source at ingest.
Default: Fail-closed. Missing membership means no access.
Enforcement: Per-request projection, built before the model runs.
Denied access: Uncleared files are absent from the request, never listed.

Good to know.

The file is simply never part of your request. Astry copies only cleared files into the sandbox and lists only those in the manifest, so the model cannot read or reference anything you were not given.

Access enforced by physics, not by trust.

See how a single request is projected, scoped and destroyed inside your own cloud.

Clearance and ACLs, enforced by physics.