Discovering the AI hardcoded in your repositories

Everyone is hunting the AI tools employees signed up for. The models and prompts your own teams wrote into the code, with the keys to call them, are the half nobody is looking at.

Point a scan at your repositories and the number tends to surprise people. Model calls hardcoded across services, prompts pasted straight into applications, and several of them in projects that shipped a year ago and belong to no one now.

None of it was ever approved as AI to govern. It was committed to hit a deadline, and it has been running quietly since.

This is the half of shadow AI almost nobody watches. The familiar version is employees using ChatGPT or Claude in the browser without sign-off, and most teams now watch for that. The other half is the AI your own teams built into your software, and it carries a risk the browser kind does not. The code that calls a model usually carries the key to call it, in the same file.

How it gets there

It gets there the way all working software gets built. A developer wires up a Bedrock or OpenAI call to ship a feature on a deadline. A prompt that took an afternoon to tune gets pasted into the application rather than stored anywhere central. A model reference is hardcoded because it was faster than the config, and the credential goes in right beside it for the same reason.

None of that is careless. But each one is an AI resource that never answered the questions a review would ask. What can this model do, what does this prompt expose, and what can this key reach. They pile up across every repo and branch, and no single person holds the list.

Why the half you built is the sharper risk

Set against the AI employees use in the browser, the AI in your own code is harder to see and worse when it goes wrong, for three reasons.

It comes with a live key. A model call needs a credential, and when the model is hardcoded, the key usually is too, sitting in the same file in a repository more people can open than you would guess. The forgotten service is not just an ungoverned model. It is an ungoverned model with a working secret attached.

You cannot govern it because you cannot find it. A browser tool at least leaves an account to point at. A model baked into code stays invisible until someone searches every repository by hand, and by then another feature has shipped. You cannot scan a model for weaknesses, score its risk, or put a control near it while you do not know it is there.

It is the entry that quietly fails an audit. An undocumented model touching data, with no record of what it is or what it can reach, is the item that was meant to be in scope and never made the inventory. When an audit asks you to account for the AI you run, the hardcoded resources are the ones you miss.

Find it in the source

FireTail scans your repositories directly, across GitHub, GitLab and Bitbucket, and surfaces the AI written into them. The models and prompts in your code, down to the file and the line, including the ones everyone forgot. It reads what is actually committed, not a diagram of what the architecture is meant to be.

The result is the list you could not build by hand: every provider, every model, every prompt in your code, grouped so the resources nobody owns stand out instead of hiding. And because hardcoded models sit in the same files where secrets often live, FireTail puts that AI in context. Which model the code reaches, which prompt it runs, which provider it talks to, so a loose credential reads as real model reach rather than a string that matched a pattern.

To be clear about the lane: this is discovery of the AI in your code and the exposure around it, not a dedicated secrets platform. If you already run secret scanning, keep it. What FireTail adds is the AI context those tools do not have, turning a found key into a known model with known reach.

A scan is a snapshot unless it keeps running

Code does not hold still. A new model lands in a service next sprint, a prompt gets rewritten, a key gets duplicated. A one-time scan describes the day you ran it and nothing after.

FireTail treats repository scanning as a standing process. Scheduled re-scans keep the inventory current, and new AI resources surface automatically as they land in a branch, so the model someone hardcoded last Thursday is on the list before it becomes an incident, not after.

Where to start

• Point FireTail at your repositories and read the inventory of models and prompts already committed, sorted so the unowned and forgotten sit at the top.
• Treat any hardcoded model with a credential in the same file as the first thing to fix. That is ungoverned model reach with a live key attached.
• Keep the scan running rather than treating it as a one-off audit, because the next forgotten service is already being written.

Most teams can account for the AI they bought. Far fewer can account for the AI they built, and that half is the one holding the keys and missing from the inventory. That is the gap this closes.

Book a demo to see the AI already written into your code, surfaced from your own repositories.

‍