Access Rules

An access rule narrows who in your workspace can see a document's content. Rules are scoped to a source, a document type, or a tag, and they are managed from the Access rules panel on a source card, or workspace-wide under Settings → Access rules.

Two principles govern the model, and both matter when reasoning about what a colleague can see. First, visibility is default-allow: a document that no rule matches is visible to everyone in the workspace. Second, a rule excludes — it never grants. There is no "allow rule" that opens a document to someone who could not otherwise reach it; adding a person to a rule only means they survive that rule.

A workspace with no access rules behaves exactly as it did before the feature existed. Nothing is hidden until you create a rule.

New sources are private by default

When you connect a new source — Google Drive, Gmail, SharePoint, OneDrive, S3, Azure Blob, a SQL database, Notion, HubSpot, Granola — Talonic automatically applies a "Private source" rule to it. Its documents start visible only to you, the person who connected it. Sharing is then a deliberate act: edit the rule to name the colleagues or roles who should also see the source, or delete the rule to make it workspace-visible.

Two source kinds are exempt and never receive an automatic rule, because they have no single connector to be private to: manual uploads and API sources (documents pushed through a dedicated API key). Existing connections made before this behavior shipped are untouched — there is no retroactive backfill.

How rules combine

Rules intersect. A document hidden by one rule stays hidden even if a second rule would admit you — every rule that matches the document must independently let you through. This is the safe direction: adding a rule can only ever narrow visibility, never widen it, so a new rule cannot accidentally expose something.

Each rule names its principals — who survives it. A principal is a specific person, a role (viewer, member, owner, and above), or the uploader (whoever connected the source or uploaded the document). The automatic "Private source" rule uses the uploader principal, which is why it resolves to exactly one person without naming them.

What a hidden document looks like

A hidden document is hidden everywhere its content could surface, not just in the document list. That includes search results and value autocomplete, extraction and captured values, structuring grids and run results, cases and their evidence, linking graphs, benchmark and validation results, the review queue, anomalies, and the AI agent's answers. The agent will not cite, quote, or count a document you cannot see.

A document you cannot see behaves as though it does not exist, rather than returning a "forbidden" error. This is deliberate: an error that distinguishes "hidden" from "missing" would itself reveal that the document exists. Counts and totals are computed from what you can see, so a filtered list does not disclose how much was withheld.

Who can manage rules

A rule can be edited or deleted by its author or by a workspace owner. Rule management is authorized against your real workspace membership, so it cannot be reached by assuming a role you do not hold in that workspace.

Access rules apply to everyone, including workspace owners and Talonic staff. There is no administrative bypass on the read path — an owner who is excluded by a rule does not see the document. Owners can always edit or delete the rule itself.

API keys and integrations

An API key sees exactly what the user who created it sees. A key minted by someone excluded from a source returns no documents from it — the public API applies the same rules as the interface. Keys created before this feature shipped, which carry no recorded creator, fail closed: they still return documents that no rule matches, but never a rule-matched one.

If an existing integration stops returning documents after a rule is created, check which user minted its key — that user is who the key is evaluated as. Re-mint the key as a user who should see the source, or add the key's creator to the rule.

Current limits

Outbound delivery and share links are not filtered. A scheduled delivery, a data-product export, or a public share link runs without a viewer, so it can carry documents that access rules would hide from an individual. Treat configuring a delivery or minting a share link as a sharing decision in its own right.
Rules by document type or tag depend on that value being present. A document with no detected type matches no document-type rule, and a document with no tags matches no tag rule. For a guarantee that does not depend on classification, scope the rule to the source.
Tags can move a document in and out of scope. Because a tag rule matches on tags, whoever can edit a document's tags can change which tag rules apply to it.
Reference data imported from a SQL source stays workspace-visible. Rows already imported into a reference table are consumed workspace-wide by matching and resolution; access rules do not reach them.
Assembled values with no source document stay visible. A value composed from several documents may have no single source document to match a rule against, so it remains visible under default-allow.

Frequently asked questions

Does an access rule hide a document from workspace owners too?+

Yes. Access rules apply to every member of the workspace, including owners and Talonic staff — there is no administrative bypass on the read path. An owner who is excluded by a rule does not see the document in lists, search, exports, or the agent. Owners retain the ability to edit or delete the rule itself, which is how they regain access.

Are my existing sources private now?+

No. Private-by-default applies only to sources connected after the feature shipped; existing connections are untouched and there is no retroactive backfill. To make an existing source private, open its Access rules panel and use "Make private", or create a rule scoped to it.

Why does my API integration return fewer documents than before?+

An API key is evaluated as the user who created it. If a rule now excludes that user from a source, the key returns no documents from that source. Either add the key's creator to the rule, or re-mint the key as a user who should see it. Keys with no recorded creator (older keys) fail closed and never return rule-matched documents.

Can I use an access rule to grant someone access to a document?+

No — rules only exclude. Visibility is default-allow, so a document that no rule matches is already visible to the whole workspace; there is nothing to grant. Naming someone in a rule means they survive that rule, not that they gain access to anything else. To widen access, edit or delete the rule that is narrowing it.

If two rules match the same document, which one wins?+

Both. Rules intersect: you must survive every rule that matches the document. A document hidden by one rule stays hidden even if another rule would admit you. This means adding a rule can only narrow visibility, never widen it.

Source Connectors

Uploading Documents

Team Management