Keeping Source Code and Secrets Out of AI Tools

Why the network layer cannot do this

The intuitive place to enforce is egress, and it does not work well here. The traffic is TLS-protected to a domain that is frequently already approved, so the choice is between allowing the destination wholesale and intercepting the session.

TLS interception makes the content visible at the cost of a considerable amount else: certificate pinning breaks, unmanaged and personal devices fall outside it, and the organization now holds a decrypted copy of everything, which is its own liability.

Inspecting at the surface where the content is composed avoids all of that. The content is already in the clear there, the tool and the user are known without inference, and the inspection happens before the request exists rather than after it.

Blocking and warning are for different categories

The instinct is to block everything sensitive. In practice that produces a control people disable, because most 'sensitive' content is contextual and the tool cannot know the context as well as the person can.

Split the problem by confidence and reversibility. Credentials score high on both: a matched key is rarely ambiguous, and once transmitted it must be rotated regardless of what the receiving service does with it. That combination justifies a block with no override.

Source code is different. A five-line snippet from an open-source dependency and a core proprietary algorithm are the same thing to a classifier and completely different to the business. A warning that names what was detected, and lets the person proceed, produces both a decision point and a record — which is most of the governance value, at a fraction of the friction.

• Block: API keys, private keys, tokens, connection strings with embedded credentials.
• Warn: proprietary source code, internal infrastructure references, confidential business records.
• Policy-dependent: regulated personal data, where the correct answer follows the regulation and the tool's contractual status.

Attachments and agent context are the same problem

Content does not only arrive by typing. It is pasted, dropped in as a file, or assembled by an agent gathering context from the workspace. A control that watches the text box and not the attachment path covers the easy case and misses the larger one — a file carries far more than anyone pastes.

Agent context is the least visible variant. When a coding assistant builds context from the surrounding workspace, the user has not chosen what is included and often does not know. Governing what leaves means governing the assembled payload, not only the words the person typed.

Do not build a second copy of the secret

A detection system that logs what it found creates a database of credentials and confidential text, extracted from context and gathered in one place. That is a more attractive target than the sources it came from.

Store the classification and the metadata: a credential was detected, of this type, in this tool, by this user, with this outcome. Everything a governance program needs to answer is answerable from that, and none of it requires keeping the value.

What Oconee Runtime detects

The documented detection categories are credentials and API keys, personal and health data, source code and secrets, financial and confidential data, internal repository and infrastructure references, and prompt-injection and unsafe instruction patterns. Coverage on the browser side includes ChatGPT, Claude, Gemini, Perplexity and Microsoft Copilot; the IDE extension covers VS Code and its forks.

Detection and activity logging are available from the entry tier. Allow, warn and block enforcement begins at the Growth tier — visibility first, then control, is the deliberate order.

Examples

• An engineer pastes a config file into a chat assistant to ask why a service will not start.

  The credential in the file is blocked; the rest of the file produces a warning naming what was found. The engineer redacts and continues, and the event is recorded without the credential.

• A support agent uploads a customer export as an attachment to summarize it.

  Attachment content is inspected on the same path as typed content. Regulated personal data going to a tool without the appropriate contractual status is the policy question, and it is answered before the upload rather than after.

• A coding assistant silently includes a neighbouring file containing deployment credentials in its context window.

  The user never saw it, so a warning aimed at the user would not have helped. Inspecting the assembled context rather than the typed prompt is what catches this class.

Frequently asked questions

Is a policy telling people not to paste code enough?

It is necessary and it is not sufficient. Disclosures are overwhelmingly accidental — a config file pasted whole, an attachment that carried more than intended, context an assistant assembled unseen. A rule aimed at intent does not address a failure of attention.

What about AI tools with enterprise agreements that exclude training?

A no-training commitment changes one risk and leaves others: the data still leaves your environment, is retained under the vendor's terms, and is exposed to that vendor's own compromise. It is a reason to permit more, not a reason to stop inspecting — and credentials should not be transmitted to any third party regardless of the agreement.

Will detection produce false positives?

Yes, and the design should assume it. That is the argument for reserving hard blocks for high-confidence, irreversible categories and using warnings elsewhere, and for making false positives visible in the same stream as true positives so rules can be tuned rather than merely endured.

Does this require reading employees' prompts?

Inspection happens locally at the point of submission; what is retained is the classification and the metadata. The organization learns that a credential was blocked in a given tool, not what anyone wrote.

Sources

• OWASP Top 10 for Large Language Model ApplicationsOWASP
• Artificial Intelligence Risk Management Framework: Generative AI Profile (NIST AI 600-1)NIST
• NIST SP 800-53 Rev. 5 — Security and Privacy ControlsNIST