The Internal-to-Product Gap: New Obligations When You Start Shipping

Why the bar changes

Internal tools operate inside a single trust boundary. The team that builds the tool and the team that uses it share an employer, a security policy, a legal entity, and a recovery path when something goes wrong. The cost of a security shortcut is borne by the same organisation that benefits from the shortcut. Trade-offs are made locally and reversed locally.

Shipping the tool to customers breaks every one of those assumptions. The cost of a security shortcut now lands on a different organisation, often with a different regulator and a different legal exposure. The supplier becomes accountable for downstream harm in a way that an internal team is not. Frameworks, contracts, and attestations that were optional internally become procurement gates externally.

This is not unique to AI. It is the consistent pattern of how internal projects become commercial products. What is unique to AI agents is the speed at which the transition happens — useful internal tools become shippable in months, not years, and the gap between "works for us" and "ready for a customer" is frequently underestimated.

The Internal-to-Product Gap anti-pattern

The frameworks that now apply

Several industry and regulatory frameworks describe the new obligations explicitly. None requires invention; all require commitment.

The frameworks differ in detail; they converge on a small set of artefacts the supplier must produce and publish. The work to produce those artefacts the first time is one engineering project; sustaining them is part of the release process.

A hypothetical supplier scenario

The following illustrates a plausible failure mode under the Internal-to-Product Gap anti-pattern. The shape draws on the supplier-incident class of the past decade; no specific incident is implied.

An organisation builds a useful internal tool for AI-assisted code review. The tool works well internally. Customer interest leads to commercial release. The release ships with the same configuration that worked internally: same dependency resolution at runtime, same telemetry capture to local disk, same agent runtime executing in the customer's developer environment with the customer's credentials.

A customer experiences an incident traced to one of the tool's dependencies. The dependency had been compromised at the publisher; the tool fetched it at runtime, as it had always done. The customer wants to know which other artefacts in their environment are at risk. The supplier has no SBOM to provide, no provenance attestation for the artefact in question, no incident-disclosure commitment to anchor the conversation, no record of which version of the dependency was actually delivered.

The technical compromise is contained. The procurement relationship is not. The customer's audit team asks the questions any audit team would ask of a supplier in this situation; the supplier does not have the answers. Subsequent renewals are paused; other customers are notified; the supplier rebuilds a programme that the internal tool's success had let them postpone.

Shipping the tool changed who bears the cost of cutting corners. The corners that were cheap internally became expensive externally.

The shippable-to-customers gate

The simplest organisational fix is a shippable-to-customers gate — a release-readiness checklist owned jointly by product and security leadership, distinct from the engineering backlog. The gate has bounded criteria; an artefact either meets them or does not. Below the gate, the tool ships internally as before. Above the gate, customers receive it.

A representative set of gate criteria:

1. Software Bill of Materials.

   CycloneDX or SPDX SBOM produced for every release. Customers can answer "what is in this artefact" without contacting support.

2. Signed build provenance.

   SLSA Level 2 or higher. Every shipped artefact carries an attestation describing how it was built and from what source.

3. Published vulnerability-disclosure policy.

   A documented contact path for security researchers, a stated response-time commitment, and a track record of acting on reports. RFC 9116 (security.txt) is the de-facto standard for the discovery path.

4. Supplier register for runtime dependencies.

   Every external service the product depends on is named, with a contact, contract type, and review cadence. Customer security questionnaires get answered by reference, not by reconstruction.

5. Independent security review.

   A third-party assessment of the product within a defined window (often six to twelve months). Internal review is necessary; external review is the part that survives the "you marked your own homework" question from a regulator.

6. Standing artefacts for procurement.

   A current security data sheet, a current threat-model summary, a current architecture diagram. The materials a customer's security team will request at procurement time exist before they ask.

A practical checklist

• A shippable-to-customers gate exists, with bounded criteria, owned jointly by product and security leadership.
• Every shipped release is accompanied by an SBOM in CycloneDX or SPDX format.
• Every shipped artefact carries SLSA Level 2 or higher provenance attestation.
• A vulnerability-disclosure policy is published, with a documented contact path and response-time commitment.
• A supplier register documents every runtime dependency, with a named owner, contract type, and review cadence.
• An independent third-party security assessment has been completed within the agreed window.
• Current security data sheet, threat-model summary, and architecture diagram are maintained and provided to customers on request without lead time.
• Demonstrations to prospective customers use synthetic data, not the prospect's own environment, until the gate has been cleared for them.
• Incident-response runbooks include customer communication paths and time-bound notification commitments matching the highest applicable regulatory regime.
• The gate is re-attested at least annually; major changes (new dependencies, new architectures) trigger an interim re-attestation.

Test your own codebase in ten minutes

The fastest way to find out whether this anti-pattern is present in your own system is to ask an AI coding assistant to look for it. Run the prompt below in a fresh chat session, on its own — and judge the system by what the code actually does, not by what its documentation claims.

Search the whole repository to find where this applies — do not
wait for me to list files. Ignore generated, vendored, and dependency
folders (build output, node_modules, vendor). Read the source plus
README.md, LICENSE, SECURITY.md, and any docs/ file. List the search
terms you used so I can confirm nothing was missed.

Assume this codebase is about to be published for use by people
other than its authors. Identify obligations that apply to shipped
software but not to internal tools, and state whether each is met:
- multi-tenant isolation (no cross-tenant data leakage)
- abuse-handling path (rate limits, reporting channel)
- user-facing error messages (no internal stack traces / secrets)
- a security contact and disclosure policy
- a clear statement of what data the tool sends where

Respond with exactly these four sections:
1. VERDICT: one of [present / not present / unclear]
2. EVIDENCE: file path + line numbers + a one-line quote per claim
3. WHY IT MATTERS: two sentences, plain English
4. FIX: a concrete change, with a short before/after code snippet
   if applicable. If "unclear", list the one piece of context you
   need to decide.

Insist on the four-part answer: a verdict with a file path, a line number, and a one-line quote is something you can act on; a verdict on its own is just an opinion. If the result is present, the FIX section is your starting point — close each shipped-software obligation (tenant isolation, abuse handling, safe error messages, a security contact) before launch day. Re-run the same prompt after the change to confirm the verdict flips to not present.

Conclusion

The transition from internal tool to shipped product is small in engineering effort and large in obligation. Recognising the change explicitly — through a launch gate, through the artefacts the gate requires, through joint ownership across product and security — is the difference between shipping a product that customers can defend and shipping a product whose first major incident becomes a sales-cycle story.

The frameworks are mature. The artefacts are standard. The work is bounded. The only ingredient that has to be added is the recognition that something has changed — and the discipline to treat the new posture as the baseline, not the aspiration.