Four deployment modes. One agent team.

How it is configured

The configuration combines three primitives, each enforced by a system the customer controls.

• One shared agent-definitions repo holds agent definitions, hooks, and skills. Visibility of the shared repo is your decision — org-wide read makes improvements flow centrally and is a common choice; restricted-team access is also supported. You set the visibility in GitHub.
• Per-team scoped repos — one per compartmented workspace — each with its own GitHub team ACL. The shared agent-definitions repo is included in each scoped repo as a git submodule, pinned to a known commit. The sub-team gets the full agent roster against their own data without a fork; updates to the shared roster are picked up by bumping the submodule pointer with the same review path as any other code change.
• One BrainSync project per scoped repo , each with its own bearer token. Memory entries, session logs, and dashboard queries are partitioned by project_id at the Postgres row level — the same Layer 3 mechanism that partitions cross-client memory. A query authenticated under one project's bearer token does not return rows tagged with a different project's ID.

What this gives you, when configured to the recommended baseline

• The team that owns the scoped workspace runs the same agent roster the rest of the organization runs, against their own data, without a separate copy of the team.
• Users without team membership and without inherited org-admin scope receive a 404 from GitHub when they attempt to clone the scoped repo — by Layer 1, before any Brainverse code runs. A prompt-injection attack on an agent in another sub-team's repo cannot trick the agent into reading this one's contents, because the request never reaches the agent's filesystem layer.
• Every scoped repo inherits the same hook chain — secret-check, memory-write-guard, config-protection, no-verify-block, mcp-send-guard. Compartmenting the workspace reduces blast radius without reducing per-repo defenses.
• Revoking a practitioner from a sub-team is a GitHub team-membership change, executed by your GitHub admin under your normal team-membership change process, with no Brainverse involvement required. This is a fifth revocation path on top of the four named on the hub landing page.

What you operate

The boundary depends on customer-operated configuration at three layers, in this order.

• GitHub organization configuration. Repo visibility (private is the recommended baseline; internal on GitHub Enterprise Cloud grants read to all org members and breaks the pattern). Base permission (default none is recommended; legacy read grants org-wide read to every repo). Org-owner and admin-team membership (these inherit access to every repo regardless of team membership; treat them as in-scope for any sub-team they can reach).
• GitHub team membership. Provisioning, rotation, and offboarding of team membership is your responsibility. SCIM-driven provisioning from your IdP to GitHub teams is supported; we don't operate it for you. Credentials linked to team-member identities (personal access tokens, deploy keys, GitHub Actions workflow tokens, SSH keys on shared infrastructure) inherit team access; treat their issuance and rotation as in-scope for sub-team membership policy.
• BrainSync project and bearer-token issuance. Distinct project IDs and distinct bearer tokens per scoped repo. Bearer tokens grant access to the project they are issued for; an individual who is issued tokens for multiple projects has access to each. Token issuance, scoping, and rotation follow your normal credential-management policy.

What this does not do, in plain terms

• It does not classify the data. Workspace-level scoping is not data-classification policy. An agent in a scoped repo can read tools, MCP endpoints, and external resources its credentials authorize; data those tools return is governed by their own access controls, not by this pattern. The scoping boundary is on the workspace and its memory, not on the data the workspace's agents are credentialed to pull from elsewhere. If a sub-team's agent should not see a particular external dataset, scope that dataset's credentials at the sub-team repo level — the same way Brainverse-staff credentials are scoped per engagement.
• It does not hide that the team exists. Git does not support 'everyone sees the folder, only some see the contents.' Visibility of 'this team has a workspace' lives in your org chart, your wiki, or your company directory — not in git. The repo is the access boundary for the contents. Likewise, agent definitions and hooks in the shared agent-definitions repo are visible to everyone you grant read on that repo. If a sub-team's name or project_id appears in a hook condition or a skill file, that detail is visible at the shared-repo grant level. Keep team-identifying constants out of the shared repo if existence-of-team must remain confidential within the org.
• It does not exclude Brainverse staff with engagement-level access. As described in the hub's honest-limits table, Brainverse staff hold scoped credentials for active engagements as required to deliver the work. If your engagement requires excluding Brainverse staff from a specific sub-team workspace, the per-engagement credential is scoped at the sub-team repo level rather than the org level, and the access scope is recorded in the engagement's SOW or security-evidence folder so both parties have a written record of what Brainverse staff can and cannot reach.
• It does not propagate scoped memory back to the shared repo automatically. Agent definitions and skills live in the shared repo and flow to every scoped team. Memory entries written under a scoped repo's BrainSync project stay there. Cross-team pattern propagation requires a deliberate operator action — read the scoped pattern, abstract it, redact the scoped context, commit the abstraction to the shared repo. There is no automatic memory sync.