In preview: per-block source permissions
Per-block permissions in the KB — control which teams or roles can read, draft from, or edit each content block, with audit trails on every read. In preview while the marketed KB surface catches up.
Per-block source permissions are available in preview to workspace administrators this week. Every content block in the knowledge base can now carry its own access policy, separate from the broader workspace and project settings. The marketed KB surface today describes per-block ownership and edit history; this preview extends that to read/draft/edit access policies and audit-log surfacing, and will roll into the platform page once the migration story is fully documented.
What changed
A content block in the KB used to inherit its visibility from the project it lived in. If the project was visible to a user, every block in the project was visible. That model held for early-stage usage and broke for any team where some content is more sensitive than other content within the same project.
The new model gives every block a permission policy with three dimensions:
- Read access. Which roles or named users can see the block exists and view its text.
- Draft access. Which roles or named users can use the block as a source when the drafting engine writes a response. A block readable by everyone may still be restricted from drafting if it isn’t appropriate to surface in proposal text.
- Edit access. Which roles or named users can edit or version the block.
The defaults are conservative. New blocks inherit the project’s existing permissions. Teams that want tighter control on a block — for security-sensitive content, customer-specific content, or content under legal review — can override at the block level without changing the broader project policy.
Why this matters
Two practical reasons.
First, multi-team KBs. A workspace with both a federal proposal team and a commercial proposal team often shares some content (company overview, certifications, financial data) and segregates other content (federal-specific past performance, commercial-specific pricing). Without per-block permissions, the segregation lives in a separate KB or in a side document. The segregation now lives in the KB itself, which means the team can stop maintaining parallel structures.
Second, security-sensitive content. Some KB content — internal architecture documents, draft compliance attestations, customer-specific addenda — should not be available for drafting against arbitrary prospect proposals. Per-block draft access lets a security or compliance owner mark blocks as draftable only against named accounts or projects. The block stays in the KB (so it remains discoverable by the right people) without being available as a source for the wrong proposal.
Audit trail
Every read of a permission-restricted block is logged. Every draft attempt that resolves a restricted block is logged. The Audit tab on a block shows who has accessed it, from which project, and whether the access produced a citation that landed in a final response. Audits are visible to workspace administrators by default and exportable as a CSV.
This is the kind of feature that doesn’t show up in a sales conversation and matters quite a lot when a customer’s compliance team asks for evidence of access controls. We built it because customers asked, and because it lines up with the audit trail we already maintain on content-block versioning — the versioning post from last week covers the version history side; this post covers the access side.
Migration
Existing blocks default to project-level visibility. Nothing changes for current customers without action. Workspace administrators who want to apply tighter policies to specific blocks can do so from the Permissions tab on each block, or in bulk from the Permissions section in workspace settings.
What’s next
Two related features are queued for the next month: project-level templated permission policies (so a new “Federal” project automatically inherits a defined block-permission template), and exportable audit reports tied to specific RFP responses (so a compliance reviewer can confirm exactly which blocks contributed to a shipped proposal).
Per-block permissions run on every existing block and every new block. There’s nothing to enable; the new tab is visible in the KB now.