Granular AI Resource Scoping: Isolate Agents, Knowledge Bases, and Files Across Org Trees

AI resource scoping is the difference between an enterprise AI platform that reflects organizational boundaries and one that relies on every agent, search, and connector behaving perfectly. A global company may share an AI platform while requiring its France sales team, UK support group, and corporate legal department to work with different agents and information. Giving every authenticated employee access to every resource is not a tenancy model.

Koios models organizational structure as a hierarchy of organizational nodes and treats governed assets—including AI agents, knowledge bases, workspace files, and tools—as resources that can be associated with those nodes. This makes scope an explicit authorization concern rather than an informal convention embedded in prompts.

Why shared AI platforms need resource boundaries

Enterprise AI resources are not just rows in a dashboard. An agent can execute tools, a knowledge base can return confidential documents, and a workspace file can contain operational or customer data. If the platform scopes only user accounts but not the assets agents can use, broad access can cross departmental boundaries.

Consider a global organization with a Europe branch, France and UK departments, and teams beneath them. A French sales agent may need a France-scoped playbook and CRM connector, while UK support needs its own knowledge sources. A global policy agent might be intentionally available across the organization. These are distinct access decisions; they should not be inferred from a resource name, a prompt instruction, or the fact that a user can sign in.

Model the organization and the resource separately

Koios’ ReBAC model separates the organizational hierarchy from resources and their scope relationships. An OrgNode represents a tenant, region, department, team, or similar structural unit, with parent-child relationships. A Resource records a governed asset such as an agent, knowledge base, file, or tool. ResourceScope links a resource to one or more organizational nodes.

Organization
└── Europe
    ├── France
    │   └── France Sales
    └── United Kingdom
        └── UK Support

Resources
├── France Sales Agent  → France Sales scope
├── EU Policies KB      → Europe scope
└── Global HR Agent     → organization-wide policy

Roles and assignments are also associated with organizational nodes. A role can define actions by resource type—for example, reading a file, searching a knowledge base, or consuming an agent. Authorization then considers the user’s role assignment, the requested action, the resource type, and the relationship between the user’s node and the resource’s scope.

How inheritance helps—and where it must be explicit

With transitive ReBAC, a user granted an appropriate role at a parent node can inherit access to eligible resources scoped to descendant nodes. Assigning a regional manager at Europe can therefore cover subordinate country branches without maintaining a separate assignment for every team. Conversely, a user scoped only to France should not gain access to a UK-only resource simply because both belong to Europe.

Inheritance is not a substitute for policy design. Teams should decide which resources are regional, departmental, team-specific, or intentionally organization-wide, and which actions each role permits. In the Koios model described in the platform material, a resource with no explicit scopes is treated as globally accessible to authenticated members of the organization. Therefore, scope configuration should be reviewed deliberately; do not assume that an unscoped resource is private or deny-by-default.

Apply the same governance to agents, retrieval, and files

Agents

Scope an agent to the organizational branch whose users may consume it. A shared agent may still need access to separately scoped knowledge bases and connectors. Evaluate each dependency rather than assuming that permission to launch an agent grants permission to every asset it could reference.

Knowledge bases

Retrieval boundaries matter as much as chat access. Scope knowledge sources to the correct department or region, and ensure search results are filtered by the caller’s permitted resource set. A well-written system prompt cannot replace authorization at retrieval time.

Workspace files and tools

Files and connectors can carry sensitive information or perform consequential actions. Assign scope to the file or tool resource itself, and check the relevant action at the point of access or execution. Avoid treating a tool as safe merely because it is attached to a permitted agent.

Authorization flow: check each requested resource

1. Authenticate the user and resolve their organization identity.
2. Determine the requested action and resource type (for example, search on a knowledge base).
3. Resolve the user’s role and node relationships, including permitted transitive inheritance.
4. Compare the authorized organizational nodes with the resource’s explicit scope.
5. Allow only when the action and scope both match; record sensitive governance changes for later review.

This model supports both endpoint checks and filtering lists of resources to those a user can access. The platform messaging describes PostgreSQL recursive CTEs for resolving hierarchical relationships and fine-grained ReBAC scoping for agents, knowledge bases, workspace nodes, and tools. The key operational principle is consistent enforcement: apply the same access policy to discovery, retrieval, execution, and file operations.

Flat RBAC versus resource-level ReBAC

Practical rollout checklist

• Map the real organizational hierarchy and identify ownership for each branch.
• Inventory every agent, knowledge base, workspace file, and tool that contains or acts on business data.
• Choose explicit scope for each asset; flag unscoped resources for review because they may be organization-wide.
• Define least-privilege actions for roles at each node.
• Test parent-to-child inheritance, sibling isolation, global resources, and role removal with representative users.
• Verify that lists, search results, direct file access, and tool invocation use consistent authorization checks.
• Log changes to roles, assignments, and scopes, then periodically review exceptions and organization-wide resources.

Build tenancy into the AI operating model

Enterprise AI resource scoping turns the corporate hierarchy into an enforceable boundary around the assets agents can use. It reduces the temptation to create duplicate agents and knowledge stores for every team, while keeping cross-department access reviewable. The value depends on careful scope assignment and consistent checks across every access path—not on labels or prompt wording.

For a deeper look at the underlying relationship model, read Beyond Flat RBAC: Transitive ReBAC and PostgreSQL Recursive CTEs. Koios positions this governance layer as part of its Enterprise AI Operating System and execution harness: agents, knowledge, files, and tools are governed resources, not invisible prompt attachments.