> ## Documentation Index
> Fetch the complete documentation index at: https://aidocs.ethanbragdon.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# Project & Knowledge Access

> Control organization member access to projects, Knowledge, repositories, artifacts, and related team resources.

# Project & Knowledge access

Organization membership gives a person a place in the team. Resource permissions decide which shared work they can actually access.

## Why resource access matters

Large organizations should not need to expose every project, repository, Knowledge base, or artifact to every member.

Use resource-level access to separate:

* product teams
* internal departments
* confidential projects
* support vs engineering material
* development vs production integrations

## Grant access

When the current product surface supports project/resource sharing:

1. Open the organization-owned project or Knowledge resource.
2. Review existing access.
3. Add the intended member or role.
4. Choose the narrowest appropriate permission level.
5. Verify the member can access the resource without granting a broader organization role.

## Inherited access

Some resources can inherit organization or project permissions. The UI should make inherited access distinguishable from explicit resource grants when possible.

## Knowledge retrieval

Retrieval must enforce access at query time. A member should not receive a protected Knowledge chunk merely because it is semantically relevant.

## Artifacts and builds

Access to a project can affect visibility of its FORGE builds and artifacts, but destructive or download actions can still require narrower permissions.

## Remove access

When removing project access, check whether the person still has access through another role, group, organization policy, or ownership relationship.

<Warning>
  Do not “fix” a project-access problem by promoting someone to organization owner or platform administrator.
</Warning>