Sensitive data policies
Add a second data-visibility boundary after roles and source ACLs.
Sensitive-data policies complement normal access rights. A member may be allowed to search a workspace while selected data classes, such as email addresses, phone numbers, names, postal addresses, dates of birth, usernames, government identifiers, IBANs, payment-card numbers, or tenant-specific identifiers, are redacted or blocked.
The server applies policy decisions after tenant and ACL checks and before returning search snippets, generated answer context, document text, previews, or original downloads. Redacted values are not written to audit logs. Admins should test policies with representative documents before enabling them for a role, and keep an explicit exception process for false positives.
Sensitive-data filtering is not a replacement for correct connector scopes, workspace permissions, or source ACLs.
Configure policies
Open Administration → Workspace → Sensitive data. Select one role at a time, search the available data classes, and choose one action per class. This role-focused view stays usable even when an organization has many roles. Built-in classes cover contact, identity, address, payment, network, and account data.
- Allow returns the value after the normal tenant and source ACL checks.
- Redact replaces detected values in text and structured responses.
- Block hides the detected value and denies access to the original file.
When a person has multiple roles, the strictest matching action wins:
block, then redact, then allow. Policy changes take effect on the next
request. They do not rebuild keyword, vector, or graph indexes and do not
create a separate index per role.
CogLake keeps one tenant-scoped knowledge index and applies the caller's roles after tenant and source-ACL checks. Search candidates are protected before an optional external reranker or answer model receives them and are checked again before REST or MCP returns the response.
The same response boundary covers workspace file content, legacy notes, annotations, memory records, document-note history, graph content, and direct document or chunk reads. Stored source content remains unchanged so another authorized role can receive its permitted view without duplicate indexes.
Test before activation
Use the policy preview to check representative text for a selected role. The preview runs in memory and is not saved. It shows which classes matched and how the protected text will look to that role.
Custom classes use a visual Contains rule with one or more values, such as customer codes, internal project names, or contract identifiers. Technical keys are generated automatically. Use concise values and test both expected matches and likely false positives before rollout.
Document notes inherit the document's tenant, workspace, role, and source ACL checks. Their current content and recent history pass through the same sensitive-data policy before they are returned.
Originals and downloads
If a document contains a class configured as Redact or Block, that role cannot preview or download its original file. CogLake checks the policy both when creating a download link and when the link is redeemed. Original files are delivered through the authenticated API; the browser never receives direct storage credentials.
AI processing boundary
Sensitive-data response rules are independent from model routing. Open Administration → Connections & identity → AI providers & data egress to choose Local models only or allow selected hosted processing stages. Saving that policy changes new processing requests immediately and does not alter role access or create additional indexes.