How to Prevent AI Agents from Leaking Private Repository Code into Public Issues, Comments, and Gists

The threat model: private context meeting a public write tool

An AI coding agent becomes a leakage risk when three things coincide in one session: read access to private code, a tool that can write to a public destination, and input the agent should not trust. Remove any one and the path narrows considerably.

Indirect prompt injection is the best-documented trigger. NIST's Generative AI Profile notes that researchers have demonstrated indirect prompt injections stealing proprietary data. An issue body, a comment, or a file in a dependency can carry instructions that the agent follows as if they came from its operator. NIST's agentic security guidance adds that instructions, metadata, and artefacts from users or other agents should not be trusted.

Credentials are the second path. The same guidance observes that agents often reuse user or service credentials embedded in context, memory, or tool responses, even when those credentials were never meant to be forwarded, and that tokens can propagate across task boundaries and other agents. A token that is broader than the task turns a small mistake into a wide one.

The third path needs no attacker. Context carryover, an over-permissive tool configuration, or an agent asked to "attach a reproduction" can place proprietary code in a public comment. The destination is legitimate and the credential is valid, but the content is wrong for that audience.

Step one: map every leakage path

Start with an inventory per agent rather than per repository. For each agent, record what it can read, what it can write, and which credentials it can see. Any agent that appears in both the private-read and public-write columns is a candidate for redesign or runtime enforcement.

• Private read sources: Repositories, local checkouts, retrieval indexes, and memory the agent can reach.
• Public write surfaces: Issue creation, pull request comments, gist creation, and any tool that forwards text to a public destination.
• Credentials in reach: Tokens in environment variables, context, memory, or tool responses, and the scope of each.
• Untrusted inputs: Issue content, comments, documents, and outputs from other agents that can steer behavior.
• Tool and MCP exposure: Which tools and MCP servers are available, and whether any are open-ended.
• Delegation: Whether sub-agents or downstream tools inherit the parent's authority.

Step two: apply preventive controls

Preventive controls shrink the set of actions an agent can attempt. They do not judge the content of any single action, so treat them as the foundation and not the whole design.

Credential scoping comes first. NIST's agent identity tenets call for zero standing privilege, so an agent holds no persistent rights when idle, and for minimum scope per task. They advise against long-lived bearer tokens and static, reusable secrets in favor of ephemeral access acquired when a task starts. Where authority is delegated to sub-agents or downstream services, scopes should attenuate so a downstream entity never holds more than its parent. NIST's secure development practices apply the same least-privilege principle to source code storage, covering tools and services as well as people.

Separation of read and write capabilities follows. An agent that triages public issues should not hold a token that can read private repositories. An agent that works on private code should not have a tool that can post to public destinations. Where a workflow genuinely needs both, split it across identities, so that no single agent can assume conflicting privileges, and put a review or policy step between them.

Destination allow-lists and tool permissioning complete the set. Define which repositories, organizations, and visibility levels each agent may write to, and deny public destinations by default. Expose the narrowest tools that do the job, and avoid open-ended tools that accept arbitrary targets. Apply the same discipline to MCP servers: each server an agent can reach is a set of capabilities, so permission them per agent and per task, and review what each server's tools can write and where.

Where platform controls stop short

Source-hosting platforms and agent frameworks offer token scoping, repository and organization visibility settings, secret scanning, and tool allow-lists. Use all of them. They reduce the attack surface and catch known patterns.

Their limitation is structural. Most are static settings applied in advance, or detectors that run after content exists. Permissions answer whether this identity may write to this destination. They rarely answer whether this specific text, produced from this specific context, should be published there. Secret detection can catch credential formats but does not recognize proprietary business logic, internal hostnames, or an unreleased module pasted into a comment. Review after the fact means the content has already been visible to anyone watching the destination.

Agent behavior widens the gap. An agent with a legitimately scoped write token can still be steered, by injected instructions or by its own context, into using that token on the wrong content. The decision point that matters is the moment the agent issues the tool call. That is where enforcement belongs.

Step three: enforce policy at the tool call

Runtime enforcement sits in the execution path between the agent and the tool. It receives the proposed call, evaluates it against policy, and returns a decision before anything is published. Because the check is on the call itself, it works regardless of why the agent made it.

Useful policy conditions are destination visibility, content classification, secret detection, and code origin. A call to a private destination with ordinary content can pass. A call to a public destination warrants closer inspection, and the response should scale with what the content contains. Tune thresholds against red-team results; NIST advises red-teaming for prompt injection, and the AgentDojo-Inspect codebase from NIST's AI Safety Institute supports research on agent hijacking and defenses.

• Allow: Public destination is on the allow-list and content is classified as non-sensitive with no secrets detected.
• Redact: Content is otherwise acceptable but contains a secret or internal identifier that can be removed before the write.
• Block: Content matches private source code, or the destination is outside the allow-list for that agent.
• Escalate: Content is ambiguous, the destination is public, and the code's origin is unclear. Hold the call for human approval.
• Rate limit: A burst of public writes from one agent or session suggests a loop or hijacked behavior.

Evidence to retain and where Trussed fits

Auditors and incident responders need to know what the agent was permitted to do and what it did. For each public write attempt, retain the agent identity and its initiator, the credential scope in effect, the destination, the policy version that evaluated the call, the decision, and any redaction applied. Add periodic records of prompt-injection red-team exercises and review of the agent inventory. NIST guidance is voluntary, but this record structure gives a defensible basis for mapping to the AI RMF: Govern for policy ownership, Map for the leakage-path inventory, Measure for red-team results and decision rates, and Manage for enforcement and response.

Trussed enforces policy in the execution path across agents, tools, MCP servers, and coding assistants, with allow, redact, block, rate limit, and escalate for human approval. The scope is the individual interaction or tool call, so enforced at runtime, not reviewed after the fact. Code provenance supplies the origin, licence, and security context of code, which gives a policy a basis for judging whether a snippet should be published. Enforcement generates audit-ready evidence continuously, mapped to frameworks including NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

These capabilities complement credential scoping and destination controls and do not replace them.