fletchNothing leaves the building unless an administrator built the door.
Fletch is designed for organisations where data isolation is not a preference but an obligation: audit and advisory firms, regulated enterprises, teams running on their own cluster. The controls below are what ships, described from the code.
Directory groups are the groups
A Fletch Group is a directory group, bound by its identity-provider id. Membership is read from the OIDC groups claim, the SAML attribute or LDAP memberOf, and refreshed on every sign-in. A group dropped from the token is dropped from the user. Nothing is typed in.
Folder permissions
An owner or an administrator grants viewer or builder over a folder or an object to an AD Group or a single person. A non-admin can grant only on what they own. Administrators list every home; they read only by permission.
Owner and share
Every connection, workflow, query and schedule has an owner. Sharing conveys use, not change: a viewer cannot edit, delete or re-share. The super administrator may grant and reassign ownership, and may not read or change the asset.
Users cannot create a place for data to go.
Creating or reconfiguring any object store as a destination requires an administrator, and that rule is not expressed through a widenable connector-visibility setting. Stores that existed before the rule are kept, flagged, and refuse new writes until an administrator confirms them. Every destination is write-probed: a byte written, read back, compared and deleted before it is trusted.
- Publishing, Delta shares and Iceberg catalogs as outputs were removed, routes and all
- Results come back inside Fletch as a bounded, access-controlled preview
- A file sink writes only to an administrator-created, probed target
Defining a workflow and running it are different grants.
Running a workflow spends its owner's credentials, so the right to see a definition never implies the right to execute it. The Run area executes only the stored document, never one supplied in the request, and audits every run as the caller. An agent acting on someone's behalf needs an explicit grant naming the operators, connections and catalogs it may touch, and when the grant expires.
- Sandbox runs are bounded; a full run is a separate, explicit act
- No grant, no action: the agent fails closed
- Grants reuse the one grant table, the audit chain and expiry-at-read
Sealed per owner. Logged in a chain.
Append-only and hash-chained: each audit entry commits to the one before it, so a removed or altered line breaks the chain. A closed set of kinds, including folder, agent and ownership.
Credential vault
Connection secrets are encrypted with AES-256-GCM under a key derived per owner (HKDF from the master key and the owner id). They are sealed on save, never returned by the API, and the connection form shows masked values only. A one-time ownership migration re-seals every connection with a read-back check before a single write.
Audit log and backups
The Log area shows activity scoped to your access, append-only. Backups of the metadata plane run on a schedule with a restore test, so a backup that cannot be restored is found by the test, not by the incident.
Single tenant, by decision, and we say so.
Fletch runs one organisation per deployment. Several internal behaviours are safe only on that basis, and the repository keeps a readiness gate listing every one that would have to be re-decided before a second tenant shared an instance. We would rather state the boundary than imply an isolation we have not measured.
What this means for you
- Your cluster, your registry, your object storage, your identity provider
- No shared control plane, no cross-customer metadata, no vendor-hosted data path
- Entra ID OIDC, SAML and LDAP sign-in; local accounts only for first-run setup
- The console image carries the engine binaries, so a workflow never leaves the pod to be validated
Bring your security questionnaire.
We answer from the code and the design documents, and we show the test that proves each control.