Why IT keeps saying no to AI app builders, and what would make them say yes

AI app builder security is the reason most requests to use Lovable, Bolt, Replit, Base44 or v0 at work stall. People see a tool that turns a sentence into a working app and want it today. IT sees a new vendor holding company code and data, another AI model with its own terms, keys pasted into chat windows and no record of what got built. Both sides are right. This post lays out the objections IT actually raises and what a tool would need to do to clear them.

Why IT says no

Talk to the people who review software requests and the same five concerns come up:

1. Shadow IT. Someone signs up with a company card, builds a tool on a personal account and shares a link. IT finds out when it breaks, or when that person leaves.
2. Data on someone else’s servers. Hosted builders keep the project, and often the app’s database, in the vendor’s cloud. That means a new data processor to assess, a new place for customer data to live and a new offboarding task.
3. Another AI vendor. The company may have spent months approving one AI provider, with a data processing agreement and settings it trusts. An app builder brings its own choice of models under its own terms.
4. Keys and secrets. Building a real app means API keys for payment, email or internal systems. People paste them into chat, and they end up in code and repositories.
5. No visibility. There is no review before something goes live and no central list of what exists. Code built outside engineering ends up somewhere nobody can read it.

Hosted builders have been closing some of these gaps. Several offer business or enterprise plans with single sign-on, GitHub sync and admin controls, and that genuinely helps. What they cannot change is the shape of the product: the work lives on their platform, and AI usage runs through their billing.

What AI app builder security means to IT

When a security reviewer evaluates an AI app builder, they are rarely asking whether the vendor is competent. They are asking where the boundaries are. A useful way to frame the review is four questions:

• Where does the code live? In a system the company controls, or in a vendor workspace that has to be exported, audited and closed later?
• Which AI sees it? The provider the company already approved, in the region it chose, or a new one?
• Where do secrets go? A keychain on the device, the vendor’s secret store, or the chat history?
• Who decides what reaches production? The same review that governs other code, or whoever has the share link?

A tool that gives clear answers to those four is most of the way to approval.

What would make IT say yes

Turn the objections around and you get a short checklist for an approvable AI app builder:

• The work stays on the company’s computers and in the company’s git, not in a new vendor workspace.
• It uses the AI provider the company already approved, billed under that existing agreement.
• Keys live in the operating system’s keychain, never in chat or in the repository.
• IT sets the rules once, centrally, and the tool enforces them.
• There is an audit trail of what was built, pushed and published.
• It works behind the corporate proxy, with the company’s certificates.
• Nothing goes to production without passing the usual review.

How Jig answers each point

We built Jig against that checklist. Here is what it does today.

The full detail, including the policy file format and what leaves each computer, is on the page for IT.

What is not built yet

Trust runs both ways, so here is what is still on the roadmap rather than in the product:

• Single sign-on with SAML or OIDC (Okta, Entra ID) and audit export to a SIEM.
• An admin dashboard for seats, versions and rollouts.
• Company templates and a shared library of skills, components and brand kits.
• Policies pushed from the cloud instead of MDM files.
• Publishing to Vercel, Cloudflare Pages, GitHub Pages and Azure Static Web Apps.

Running a pilot

If you want to test the idea before committing, a small pilot answers most questions in a couple of weeks:

1. Pick five to ten people with real internal-tool ideas, and one engineer to review.
2. Deploy Jig with a policy that allows only your approved AI provider and your company git host, with private repositories only.
3. Have each person build one tool and push it to a shared group in your git.
4. Review the repositories the way you would any other code, and decide what goes to production.
5. Read the audit logs and check what left each machine against your expectations.

For what happens after the pilot, when a whole team is building, read From shadow IT to shared git. Pricing for teams is on the pricing page.