AI-generated code is everywhere. Proof of where it came from is nowhere.
Here's a question your compliance team probably can't answer right now: what percentage of your production codebase was written by an LLM?
Not estimated. Not guessed. Proved, with a signed record, an audit trail, and a document you could hand to a SOC2 assessor today.
If you work at a company with active Copilot seats, the honest answer is probably somewhere between 20% and 60% of recent commits, and you have zero formal documentation of any of it. That gap is what this idea is trying to close.
The AI Code Provenance & Attribution idea sits at an uncomfortable intersection: a problem that is clearly real, regulators who are clearly moving toward caring about it, and a window of maybe 12-18 months before GitHub closes the opportunity by shipping something native.
Let's start with why the problem exists at all. When a developer uses Copilot, Cursor, or Claude to write a function, nothing in the commit records that. The diff shows up, the PR gets reviewed (maybe), the code ships. Six months later, when a security vulnerability is traced back to that function, or when an auditor asks whether the codebase complies with your company's AI usage policy, you have no idea. You're guessing.
This is fine when AI-assisted code is maybe 5% of what ships. It is not fine when it's 40%, and that number keeps going up. The Spotify thread that went viral last year, where engineers were openly discussing not writing code manually anymore, got over 1,000 upvotes not because it was shocking but because it resonated. Everyone already knows this is happening. Nobody has the infrastructure to prove it.
On the compliance side, G2 and Capterra reviews of Copilot and GitLab Ultimate are littered with complaints about this exact gap. Customers want audit trails that capture the model, the prompt, the confidence. They're not getting them.
Three things are converging. The EU AI Act is creating real urgency in enterprise legal departments, even if its specific requirements for developer tooling are still genuinely ambiguous. Enterprise AI usage policies are becoming real documents with real teeth, not just blog posts from the CISO. And vendors like OpenAI and Google DeepMind are starting to publish provenance APIs, which means the raw infrastructure for this is starting to exist.
The "why now" argument here is not "regulation will definitely require this exact thing by this exact date." It's softer than that, which is both a problem and an opportunity. The problem: compliance teams doing their own AI Act analysis may conclude they can wait. The opportunity: the ones who are already dealing with SOC2 audits, who are already getting questions from assessors about AI tooling, have a concrete near-term pain point that doesn't require regulatory certainty to feel real.
Selling to a company in the middle of an active audit is a completely different motion than selling future-looking governance software. The former has urgency and a named budget holder. The latter has six-month sales cycles and a lot of "let's revisit next quarter."
The core concept is an SBOM for AI authorship. Software Bill of Materials is already a standard concept in security compliance. Every dependency gets listed, versioned, tracked. This applies the same logic to AI contributions.
At the commit level, a pre-commit hook or GitHub App intercepts pull request events, classifies which files were AI-touched (using a combination of heuristics and IDE telemetry metadata), and attaches signed provenance records: origin model, confidence score, timestamp. The compliance dashboard then surfaces per-repo AI authorship percentages, exportable in SBOM-format JSON or CSV that auditors can actually consume.
The policy enforcement layer is where it gets genuinely useful. You configure rules: require human sign-off when AI-generated code exceeds a threshold in security-critical modules, block merges on certain paths without manual review, warn-only for lower-risk areas. This turns a passive audit trail into an active governance system.
From a build perspective, this is not a complicated stack. A Next.js frontend, Supabase for storage with hash-chained append-only provenance logs, a GitHub App via Octokit, Stripe for billing. A solo developer could have an MVP in 8-10 weeks. The technical moat is not the infrastructure. It's the classifier, trained on labeled AI-generated vs. human-written diffs, that gets more accurate with every enterprise customer's commit history. That's the data flywheel that a generic GitHub logging feature won't replicate.
There are no YC companies doing this directly, which sounds exciting until you remember that sometimes that means the market doesn't exist and sometimes it means you're early. Snyk and Semgrep own the code quality and vulnerability space. GitHub's Copilot logs some usage data but provides nothing resembling a formal provenance chain or policy enforcement layer. Watermarking research from OpenAI and Google DeepMind exists at the model level but nobody has productized it across multiple models in a repo-integrated system.
The gap is real. The question is how long it stays real.
I want to be honest about the thing that makes me most nervous about this idea, because it's genuinely severe.
GitHub controls the commit pipeline. Microsoft shipped Copilot audit logs as a first-party GitHub feature within 12-18 months of third-party tools proving demand in adjacent spaces. They can add an "AI authorship tag" to every Copilot suggestion at zero marginal cost, bundle it into GitHub Enterprise Advanced, and your data collection layer is commoditized overnight. If you haven't locked in 50+ enterprise customers with 12+ months of audit history before that ships, your core value proposition evaporates.
This is the existential risk. Everything else is secondary.
The second risk is subtler but almost as bad. If 20% of AI-assisted commits bypass your detection, because developers are using local LLMs, copy-pasting from ChatGPT, or just toggling off the hook, your audit report is actually dangerous. It implies comprehensive coverage when it isn't. A compliance officer who submits an incomplete provenance report to an auditor is worse off than one who submitted nothing, because they've made an implicit completeness claim. You could get blamed for audit failures that are really adoption failures, and that's a liability problem that can sink a company.
There's also a false-positive risk that I don't think the founders have fully reckoned with. If your classifier incorrectly flags human-written code as AI-generated and a developer gets disciplined or fired over it, you're looking at product liability exposure. That's a low-probability but high-consequence scenario.
And the EU AI Act angle may be weaker than the pitch suggests. The Act focuses on AI systems deployed to end users. Internal developer tooling is genuinely ambiguous territory, and enterprise legal teams doing their own analysis may conclude the regulatory urgency isn't there yet.
The sales insight buried in this idea is actually the most interesting part. This is not a developer tool sale. It's a compliance sale. The buyer is the VP of Platform Engineering or the Head of GRC who is already nervous about their next SOC2 audit. They have budget. They have urgency. They're not evaluating cool developer tooling, they want a document they can hand to an auditor.
That changes everything about the go-to-market. You're not posting on Hacker News and hoping it spreads. You're cold messaging 500-5,000 person fintech and healthcare companies on LinkedIn, asking one question: "How is your team currently answering auditor questions about AI-generated code?" You're attending ISACA chapter events. You're building referral relationships with the GRC consultants who are already doing EU AI Act readiness engagements.
The validation test is simple: 20 Zoom calls with compliance officers. Ask the question. End with "would you pay $10K/year for a tool that solved this?" Five signed letters of intent before you write a line of code means you have something. Anything less means you have an interesting idea.
A free tier for up to three repos buys OSS community adoption and classifier training data. Team pricing at $49/user/month with a ten-seat minimum gets you to $490/month per customer, which is fine but not the business. The business is enterprise flat rates at $2,000-$5,000/month, annual contracts in the $15K-$50K range, with SSO, on-prem export, and SLA.
At $3K/month average and 80% renewal, enterprise LTV is around $60K over two years. You break even at 3-4 enterprise customers or about 20 team-tier customers. The unit economics are not the problem here.
If this idea works, it works because you got to 50+ enterprises with locked-in audit history before GitHub shipped native provenance. That window is probably 12-18 months. Maybe 24 if you're lucky and GitHub moves slowly on something that doesn't benefit their core Copilot monetization.
The right move is not to build a comprehensive platform. It's to build the minimum thing that gets a compliance officer their audit document, sign five LOIs, then build fast. Every month spent on product refinement before you have paying customers is a month of your window gone.
This is a race with a known endpoint, against a competitor that doesn't know it's competing yet. That's a strange position to be in. I genuinely don't know if 12-18 months is enough time to build a defensible moat through audit trail continuity. But the problem is real, the buyers exist, and nobody has built it yet. Sometimes that's enough.