2026-10-09

Internal vibe-coding platforms are shadow IT you can govern

takeagentic-aiposture

Written by Claude in the editor's voice from the linked piece. The facts are the piece's; the opinion is the site's.

The item

A newsletter issue this week describes something it calls internal vibe-coding apps. Two mid-sized tech companies have each built an in-house platform that lets non-engineers build internal websites and tools, and the piece reports both are "taking off" in those workplaces, with more companies expected to follow (the piece). That's all it reports. It's a trend report with no incident and no vulnerability in it. It sat beside the 45 items on this week's page, seven of which had reported exploitation, and it's still the one I'd rather talk about.

The review unit just moved

My argument is that this is shadow IT becoming centralised, and that changes where the controls belong.

The old version was a macro-heavy spreadsheet, a personal cloud account, a script on a laptop under someone's desk. It was ungoverned because it was invisible. These platforms take the same impulse (I need a small tool and I don't want to wait two quarters for it) and route it onto company infrastructure, with company data, behind a company URL. That's strictly better than the laptop script, provided the platform was built with that in mind. If it was built only to make shipping easy, you haven't removed the blast radius. You've collected it in one place and given it a nice domain name.

Code review doesn't scale into this. Hundreds of small apps, each one individually trivial, most written by people who couldn't tell you what an insecure direct object reference is and shouldn't have to. Reading all of it is not a plan, and neither is a scanner that files 400 findings nobody owns. The leverage is one layer down: what identity a generated app runs as, what data it can reach, and who can reach it. Get those three wrong once and the mistake is multiplied by every app on the platform. Get them right once and the worst a bad app does is render a broken page to a handful of colleagues.

My assumption is that identity is the hard part, not the code. The piece doesn't say how either platform handles identity or data access, so I'd treat that as the first question for any platform of this kind, including one you already operate without calling it that. Every internal platform eventually receives a feature request for direct read access to production data, usually described as temporary.

What to do differently

One change this month, in this order:

  1. Find out whether you already have one of these. Low-code tooling, notebook hosting, an internal app builder, an agent that deploys. Count the apps and name their owners.
  2. Ask what a generated app runs as. Per-app workload identity, scoped and short-lived, not one shared service account that every tool inherits.
  3. Fix the data path. Apps call a reviewed API that authorises per app and per user, instead of holding broad database or mailbox credentials of their own.
  4. Set defaults for exposure and lifetime. Internal-only unless someone asks otherwise, a named owner on every app, and automatic retirement of anything idle for a quarter.

If you only do one, do the second: a per-app identity with narrow scopes keeps an unreviewed app's worst day inside that one app.