The platform and identity owners together. The application team controls what the agent reads and writes, while the identity team controls which repositories the credential can reach. If either side treats the token as a generic developer credential, the boundary fails. Accountability has to sit with the team that can actually narrow the session to one trust zone.
How MCP access should be scoped between repositories and trust zones
Scoping is not just a permissions task, it is a boundary-setting task. The practical question is which team can define the session’s blast radius without guessing how the token will be used. For MCP, that means the application team defines the agent’s read and write surface, while the platform and identity owners define which repositories and trust zones the credential can actually reach.
That division matters because MCP access often spans more than one control plane. Repository scope, token audience, and tool access are related but not interchangeable decisions. If one team owns the application behavior but another owns the credential reach, the accountability line has to be explicit or the agent inherits more access than either side intended. The MCP Security Guide is useful here because it treats authorization, token passthrough, and gateway boundaries as separate design choices rather than one generic access problem.
In practice, the accountable owner is the team that can narrow the session to one trust zone and prove that the agent only reaches the repositories needed for the current task. That usually requires the application side to define the minimum tool and data scope, and the identity side to enforce the repository and token scope that makes that design real. If either side treats the token like a broad developer credential, the control collapses into shared access with no clear boundary.
Where scoping breaks down in mixed public and private repository access
The failure mode is usually overreach, not total compromise. A token intended for one repository type gets reused across multiple repositories, or an agent session is allowed to move from a narrow private workspace into broader source control access because the authorization boundary was never tied to a specific trust zone. That creates hidden cross-repository exposure even when the agent appears to be acting normally.
Public and private repositories are not just different visibility settings, they often imply different governance expectations, different review thresholds, and different recovery steps. When one token can cross that line, a mistake in the agent or its tooling can turn a local read into a broader code or secret exposure event. The Model Context Protocol: Authorization specification is relevant because it reinforces audience-bound access and rejects token passthrough as a safe default for HTTP transports.
That is why accountability has to be shared but not blurred. The application team owns the intended use of the agent session, and the identity or platform team owns the actual enforcement of repository reach. If either side assumes the other side will constrain the token later, scope drift becomes the default.
What good accountability looks like for repository scope
Good accountability is visible in ownership, not just in policy language. The team that designs the agent workflow should be able to say what repositories it needs, why it needs them, and when access should stop. The team that manages identity should be able to show that the credential cannot be reused outside that boundary, even if the agent, tool, or user request changes.
That is easier to verify when the scope is tied to one workflow and one trust zone rather than a general developer identity. For example, a token that can read one private repository but not write to unrelated repos is much easier to reason about than a broad token that works wherever the agent happens to be pointed. The RFC 8707: Resource Indicators for OAuth 2.0 supports that model by letting clients request audience-restricted access tokens for a named resource.
When the scope is well owned, reviews become simpler too. You can test whether the agent needs read access, write access, or both, and whether that access should be limited to a single repository set or a single class of repositories. That makes exception handling clearer when a new repository, environment, or connector is introduced.
Risk and Threat Considerations
The main risk is that a broad or reused token lets an agent cross from a narrowly approved repository set into a wider one without any meaningful change in behavior. Once that happens, a single integration mistake can expose private source, sensitive configuration, or embedded secrets across multiple repositories.
Failure mechanism: The access token or session is scoped like a generic developer credential, so the repository boundary is enforced informally instead of technically. The agent, tool, or workflow then inherits reach beyond the trust zone that the approving team actually intended.
Impact: Unauthorized repository reads or writes can expose source code, leak secrets, or let one compromised workflow spread access into other projects. Recovery becomes harder because the organization cannot prove which team owned the boundary that failed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | MCP scope determines what an agent can access and do. |
| Recommendation — Bind each agent session to the minimum repository and tool privileges required. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Repository scope should be minimized to the minimum required access. |
| IA-9 — Service Identification and Authentication | MCP access is mediated by service-to-service credentials and token audiences. | |
| Recommendation — Enforce least privilege so agent credentials cannot reach unnecessary repositories. Authenticate the MCP service identity and bind tokens to the intended resource. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Broad or reused tokens can let an agent cross repository boundaries. |
| Recommendation — Scope tokens to the correct audience and reject generic bearer reuse. | ||
Practitioner Guidance
What to prioritise: Put the scoping decision where the blast radius can be reduced, not where the request originated. If the agent can touch more than one repository class, require both the workflow owner and the identity owner to sign off on the exact reach of the session.
What to verify: Confirm that the repository list, token audience, and allowed actions are all bounded to the same trust zone. A design is not properly scoped if the agent can still reach private repositories after the intended task is complete.
Practitioner takeaway: Accountability for MCP scoping belongs to the team that can actually enforce the narrowest safe boundary, but durable control only exists when application intent and identity enforcement match.
Related resources from NHI Mgmt Group
- Who is accountable when cybercrime response depends on intelligence sharing across public and private partners?
- Who should be accountable for improving SME cyber resilience across the public and private sectors?
- Who is accountable for protecting private and public GitHub repositories with runtime CI/CD monitoring?
- How should security teams restrict public access to code scanning platforms that analyze private repositories?