Why IT blocks the AI tool you built — and what they are actually worried about

By the Cresec team · Published 22 September 2026 · Updated 17 October 2026

You built something useful. Maybe it reads your inbox and drafts replies, or pulls your open deals and reminds you who to call. Your teammates want it. Then someone asks IT, and the answer is no — or worse, no answer at all.

It is tempting to read that as IT being difficult. Usually it isn’t. The “no” comes down to one combination of things your tool does, and four questions nobody could answer yet.

The real reason: the lethal trifecta

Look at what your tool does. It reads text someone outside wrote, such as emails or tickets. It can see private data, such as your CRM or inbox. And it can send something out. Security researchers call that combination the lethal trifecta: a hidden instruction in the text it reads can make it send your data to an attacker. A model can’t reliably tell your instructions from the attacker’s, so a security team that sees all three legs will say no until something other than the model decides where data goes.

What a good answer looks like: the tool’s actions and recipients are fixed in code, so an instruction hidden in a ticket can change a sentence in a draft but not where it goes.

1. Whose login is it using?

Most homemade tools start on the builder’s own account. That’s fine while only you use it. The moment a teammate uses it, they are acting as you — reading your customers, sending from your mailbox. IT can’t approve that, because nobody can tell afterwards who actually did what.

What a good answer looks like: each person signs in as themselves and connects their own accounts. The tool never holds anyone’s password.

2. What can it do without asking?

An assistant that drafts an email is very different from one that sends it. IT’s worry is the second kind: a tool that can send, delete or change records on its own, for everyone, from day one.

What a good answer looks like: new users start with drafts only. Sending or changing things is allowed later, for a specific person and a specific tool, by someone who can say yes.

3. Will there be a record?

When something goes wrong — a wrong email to a customer, a changed record — someone will ask what happened. Homemade tools rarely keep any trail at all.

What a good answer looks like: records name the person and tool version, with documented verification and trust assumptions. Check integrity of the records that exist separately from coverage: an action never recorded may leave no detectable gap.

4. What happens when someone leaves?

If the tool runs on a shared account or a saved password, someone leaving means changing that password everywhere and hoping nothing breaks.

What a good answer looks like: access follows the person, with a tested revocation path. Check existing sessions, connected accounts, schedules and workflow ownership; switching off one company account may not complete the handover.

A concrete example of the review friction

In this Reddit comment about choosing an app builder, a reader describes weighing UI tradeoffs and checking SDK compatibility before a proof of concept. It is one reported experience, not evidence that any named platform is generally unsuitable. Turn that uncertainty into a small test your IT reviewer can reproduce.

Bring the answers, not the tool

Answers to these questions give IT a concrete basis for a decision. Cresec may help with a supported access and governance gap, while you retain workflow ownership. An integration still needs review and may require code changes. Check the FAQ before making an assurance.