Shadow AI Discovery & Amnesty
What's already happening, and what do we do about it?
This finds what's already happening. Deciding whether something should be built is the Marketplace's job; keeping it healthy is the Registry's.
Problem
Employees already use AI at work through personal accounts and unregistered licenses. IT sees little of it, and blocking it pushes it further out of sight.
What it does
A signal inbox collects evidence of AI use: spend lines, OAuth grants to third-party apps, and browser or CASB events. Each finding lands in a triage queue with three outcomes: stop, move to an approved tool, or formalize. Formalizing opens a pre-filled submission in the Innovation & PRD Marketplace. Alongside it, a no-blame self-report path lets people declare what they use before anyone finds it. Each finding gets an exposure estimate based on the kinds of data involved.
Planned scope
- The signal inbox, fed by a seeded feed that follows real vendor schemas
- The triage queue with stop, migrate and formalize, and the hand-off into the marketplace
- The self-report form and amnesty flow
- Exposure estimates from the data classes involved
What it demonstrates
Amnesty before enforcement. People route around rules that only punish, so the first goal is visibility: make it safe to say what you use, then make the approved route easier than the workaround.
Rejected alternative
Blocking unapproved tools. People route around blocks, and the organization loses the little visibility it had.
Honest limitation
Personal accounts on personal devices are largely invisible to any of these signals. And monitoring employees’ tool use raises privacy and legal questions that need HR and legal input before anything like this runs for real.
Integration map
| System | This demo | In production |
|---|---|---|
| Spend lines (cards and expenses) | Simulated, schema modeled on real expense exports | Finance system export |
| OAuth grants to third-party apps | Simulated, schema modeled on identity-provider audit logs | Identity provider audit API |
| Browser and CASB events | Documented only | Endpoint or CASB tooling |
| Self-report form | Built into the app | Same |
Planned stack
Nothing is built yet. This is the stack the project is planned on, shared with the marketplace where it can be.
- Frontend
- TypeScript
- Tailwind
Same language and styling approach as the marketplace, so the three projects share patterns.
- Backend / data
- Postgres (Neon)
- Drizzle
- Zod
- Seeded signal feed
Signals are synthetic but match real vendor schemas, so swapping in a real source changes the input, not the logic.
- AI
- Claude (structured outputs)
Classifies each signal into a typed record; the triage decision itself stays with a person.
- Quality
- GitHub Actions CI
Every change runs the classification checks before it ships.
- Infra
- Vercel
One small app with a database, deployed on push.
