Skip to main content

Knowledge Access Control: Who Can Create, Promote, and Bind Assets

Knowledge governance breaks down when access control is too loose or too vague. If anyone can activate anything, draft content becomes production risk. If no one understands who owns promotion or binding, the platform becomes slow and inconsistent. Keeptrusts addresses that with a combination of scope, ABAC, permissions, and workspace sharing.

The result is a practical separation of duties. People who create content do not automatically have to be the same people who promote it into active runtime use, and visibility in chat suggestions can still respect team scope and policy boundaries.

Use this page when​

  • You are designing ownership and approval rules for Knowledge Base.
  • You want to limit who can create, read, promote, or bind assets.
  • You need to explain how scopes and sharing affect visibility and runtime access.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Platform administrators, knowledge managers, technical leaders

The problem​

Access control for knowledge is harder than it looks because there are several separate questions hiding inside it.

  • Who can create or update the content?
  • Who can see the asset in the console or chat suggestion flow?
  • Who can promote a version into active runtime use?
  • Who can bind the asset to an agent and therefore affect production answers?

If those concerns are not separated, organizations usually end up in one of two bad states. Either everyone works around the system because it is too restrictive, or too many people can push content live because the rules are informal.

That problem gets worse in multi-team setups. A team may need to author its own material while keeping it invisible to other teams. A platform group may need global oversight without becoming the bottleneck for every edit. And reviewers may need approval authority without becoming day-to-day document maintainers.

The solution​

Keeptrusts combines several real access controls.

At the asset level, knowledge assets are org-owned but ABAC-controlled. The CLI reference documents access levels of org, team, and user, which determine how the asset is scoped for use. In the console knowledge overview, suggestion visibility is further limited by team scope and ABAC policies.

At the permission level, the CLI docs call out knowledge_base:read for list and get operations, and knowledge_base:write for create, update, and delete operations. Promotion authority is also called out in the user-docs use case material, which notes that in team-scoped configurations, only team admins or org owners should promote assets.

At the workspace level, the file manager adds folder sharing roles of viewer, editor, and manager. That helps teams collaborate on durable knowledge files without making every collaborator a global asset owner.

Taken together, these controls let you build a clear ownership model:

  • authors create and edit
  • reviewers approve promotion
  • operators manage bindings to agents
  • end users see only the assets visible to them under scope and ABAC rules

Implementation​

A good starting pattern is to scope shared team content at the team level and keep agent bindings with the operational owner of that workflow.

# Create a team-scoped asset for the support organization
kt kb create \
  --name "emea-support-playbook" \
  --scope team \
  --kind static

# After review, promote it into runtime eligibility
kt kb promote kb_emea_support_playbook --to active

# Bind the active asset to the correct agent
kt kb bind \
  --id kb_emea_support_playbook \
  --target-type agent \
  --target-id agent_support_emea

In the console file workspace, use folder sharing to separate collaboration from activation. Editors can help maintain files under a shared folder. Managers can control the folder. Promotion and binding can remain with the group that owns runtime behavior.

This is also where chat suggestions become useful. The knowledge overview documents that only assets visible under team scope and ABAC policies appear in the suggestion panel. That means visibility to users is already narrower than “everything active in the org,” which is an important control in multi-team deployments.

Results and impact​

Clear knowledge access control reduces both risk and friction. Teams can work faster because ownership is defined, while platform operators keep strong control over what becomes active production context. Sensitive or specialized knowledge becomes easier to isolate, and day-to-day collaboration does not require making every collaborator a global administrator.

The downstream effect is better grounded AI with fewer surprises. When a response cites an asset, you know not only which source was used but also which scope, permission path, and binding decision made that use possible.

Key takeaways​

  • Knowledge Base access control is a combination of scope, ABAC, permissions, and workspace sharing.
  • org, team, and user scope affect who can use or discover an asset.
  • knowledge_base:read and knowledge_base:write permissions distinguish viewing from authoring operations.
  • Folder sharing roles help teams collaborate without flattening runtime governance.
  • Promotion and binding should be treated as controlled actions, not incidental editing side effects.

Next steps​