The trust boundary collapses. A public issue can carry attacker instructions that shape what the agent retrieves from private repositories, and a later write action can publish that material back out. The problem is not a server defect. It is one identity context spanning two trust levels, which makes normal collaboration features behave like an exfiltration path.
Why a single MCP session breaks the trust boundary
The core failure is not “public versus private content” by itself, but shared authority. When one agent session can inspect public issues and then access private code without a clean context reset, the agent can treat attacker-controlled text as input to private retrieval and later as output material. That creates a single execution path across two trust levels, so collaboration features stop being ordinary workflow tools and become a data-flow bridge.
In practice, the public issue is a delivery vehicle for instructions, prompt shaping, or hidden constraints that influence what the agent looks up next. Once those instructions affect private repository access, the issue is no longer just metadata, it has become an input to a privileged read. If the same session can then write back out, the private material can be repackaged into a comment, patch, summary, or artifact that leaves the private boundary.
That is why the question is really about session scoping and trust separation, not about whether the MCP server itself is “broken.” The dangerous condition is a context that is broad enough to cross from untrusted collaboration data into confidential source material without a hard policy break in between.
How prompt-to-retrieval-to-write exfiltration happens
The most common pattern is indirect exfiltration through retrieval. The agent reads a public issue, follows its instructions, queries private code, and incorporates the result into a later response. Even when the model never explicitly “decides” to leak, the session has already allowed untrusted text to steer access to higher-value material.
A second pattern is write-back abuse. If the agent can post comments, update issue text, open pull requests, or generate summaries from the same session, attacker-supplied content can be echoed outward with private code fragments, paths, secrets, or implementation details embedded in the output. This is especially dangerous when the write channel is treated as low risk because it looks like normal collaboration.
For agentic systems, the problem is amplified by tool chaining. The same conversation can accumulate context from a public source, then use that context to select private tools or repositories, then surface the result to a destination the attacker can see. That is a classic confused-deputy pattern, with the agent acting on behalf of the wrong trust context.
What a safe separation model needs to enforce
Safe designs do not rely on the agent “understanding” which content is trustworthy. They enforce separation at the session, authorization, and tool layers so that public inputs cannot automatically influence private reads, and private reads cannot automatically flow back to public writes. The important control is not just authentication, it is constraining what the session is allowed to mix, remember, and publish.
Where possible, public issue handling and private code access should be split into different principals, different tokens, or different tool contexts, with explicit approval for any transition across trust boundaries. If the agent must bridge both worlds, the bridge should be narrow, policy-governed, and observable rather than implicit in a long-lived chat context. MCP Security Guide is useful here because it treats authorization, token handling, and confused-deputy risk as first-class design problems.
That same principle is why least-privilege delegation matters more than “agent convenience.” If the agent only needs to read public issues, it should not inherit the ability to reach private code in the same unbounded context. If it only needs private code for a bounded task, the read should be isolated from any public-facing write channel. AI Agent Authorisation Guide helps frame that as per-action authority, not blanket access.
Why a single MCP session breaks the trust boundary
The core failure is not “public versus private content” by itself, but shared authority. When one agent session can inspect public issues and then access private code without a clean context reset, the agent can treat attacker-controlled text as input to private retrieval and later as output material. That creates a single execution path across two trust levels, so collaboration features stop being ordinary workflow tools and become a data-flow bridge.
In practice, the public issue is a delivery vehicle for instructions, prompt shaping, or hidden constraints that influence what the agent looks up next. Once those instructions affect private repository access, the issue is no longer just metadata, it has become an input to a privileged read. If the same session can then write back out, the private material can be repackaged into a comment, patch, summary, or artifact that leaves the private boundary.
That is why the question is really about session scoping and trust separation, not about whether the MCP server itself is “broken.” The dangerous condition is a context that is broad enough to cross from untrusted collaboration data into confidential source material without a hard policy break in between.
How prompt-to-retrieval-to-write exfiltration happens
The most common pattern is indirect exfiltration through retrieval. The agent reads a public issue, follows its instructions, queries private code, and incorporates the result into a later response. Even when the model never explicitly “decides” to leak, the session has already allowed untrusted text to steer access to higher-value material.
A second pattern is write-back abuse. If the agent can post comments, update issue text, open pull requests, or generate summaries from the same session, attacker-supplied content can be echoed outward with private code fragments, paths, secrets, or implementation details embedded in the output. This is especially dangerous when the write channel is treated as low risk because it looks like normal collaboration.
For agentic systems, the problem is amplified by tool chaining. The same conversation can accumulate context from a public source, then use that context to select private tools or repositories, then surface the result to a destination the attacker can see. That is a classic confused-deputy pattern, with the agent acting on behalf of the wrong trust context.
What a safe separation model needs to enforce
Safe designs do not rely on the agent “understanding” which content is trustworthy. They enforce separation at the session, authorization, and tool layers so that public inputs cannot automatically influence private reads, and private reads cannot automatically flow back to public writes. The important control is not just authentication, it is constraining what the session is allowed to mix, remember, and publish.
Where possible, public issue handling and private code access should be split into different principals, different tokens, or different tool contexts, with explicit approval for any transition across trust boundaries. If the agent must bridge both worlds, the bridge should be narrow, policy-governed, and observable rather than implicit in a long-lived chat context. MCP Security Guide is useful here because it treats authorization, token handling, and confused-deputy risk as first-class design problems.
That same principle is why least-privilege delegation matters more than “agent convenience.” If the agent only needs to read public issues, it should not inherit the ability to reach private code in the same unbounded context. If it only needs private code for a bounded task, the read should be isolated from any public-facing write channel. AI Agent Authorisation Guide helps frame that as per-action authority, not blanket access.
Practitioner Guidance
What to verify: Check whether the agent uses one identity and one conversational context across both public and private resources, because that is the condition that turns an ordinary issue thread into a cross-boundary data path. Verify not just that access exists, but that public inputs cannot influence private retrieval without an explicit policy step.
Decision rule: If a workflow can read untrusted public content and private repository content in the same session, treat it as a trust-boundary design flaw even when no secret has been observed leaking yet. If the output channel can publish back to a public issue, comment thread, or other shared surface, require a separate context or a hard approval gate before any private material is written out.
What good looks like: The agent can operate on both sides only through narrowly scoped actions, with separate credentials or tool contexts, clear auditability, and an explicit stop between public intake and private retrieval. The safest signal is that an attacker-controlled issue cannot alter what the agent sees in private code unless a policy engine allows the transition.
Practitioner takeaway: The real fix is to stop treating one session as a harmless convenience layer, because once untrusted collaboration data and private code share the same authority chain, the session itself becomes the exfiltration boundary.
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 | The issue is one agent context spanning untrusted input and privileged private access. |
| ASI02 — Tool Misuse | Public issue text can steer tools into private retrieval and outward publication. | |
| Recommendation — Bind agent actions to per-request authority and block privilege carryover across trust boundaries. Constrain tool invocation so untrusted content cannot redirect private reads or writes. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The same session should not be able to invoke public and private functions without policy separation. |
| Recommendation — Enforce function-level checks before an agent can move from public collaboration to private code access. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Agent-to-tool and agent-to-repository access need distinct service authentication contexts. |
| AC-6 — Least Privilege | The session only becomes dangerous when one identity can read both sides and write back out. | |
| Recommendation — Authenticate each service interaction separately and prevent token reuse across trust levels. Limit each agent session to the minimum read and write rights needed for the current task. | ||
Practitioner Guidance
What to verify: Check whether the agent uses one identity and one conversational context across both public and private resources, because that is the condition that turns an ordinary issue thread into a cross-boundary data path. Verify not just that access exists, but that public inputs cannot influence private retrieval without an explicit policy step.
Decision rule: If a workflow can read untrusted public content and private repository content in the same session, treat it as a trust-boundary design flaw even when no secret has been observed leaking yet. If the output channel can publish back to a public issue, comment thread, or other shared surface, require a separate context or a hard approval gate before any private material is written out.
What good looks like: The agent can operate on both sides only through narrowly scoped actions, with separate credentials or tool contexts, clear auditability, and an explicit stop between public intake and private retrieval. The safest signal is that an attacker-controlled issue cannot alter what the agent sees in private code unless a policy engine allows the transition.
Practitioner takeaway: The real fix is to stop treating one session as a harmless convenience layer, because once untrusted collaboration data and private code share the same authority chain, the session itself becomes the exfiltration boundary.
Related resources from NHI Mgmt Group
- What breaks when an AI triage agent can read public issues and reach repository secrets?
- What breaks when an AI assistant can read alerts and modify code in one session?
- What breaks when MCP servers expose all tools to every agent session?
- What breaks when an AI agent can read and write identity infrastructure in one session?