Which AI App Problems Should You Fix First?

TL;DR: Fix an AI app's problems by what each one can reach, not by the label on the report. A flaw that touches no company data is a nuisance. The same flaw becomes a breach once the app connects to real records. Ask what the app can see and do, and who it thinks is asking.

Key takeaways:

• A problem's label is a decision someone made. What the problem can reach is a fact about the app.

• Almost every AI app problem looks small until the app connects to company data.

• A guardrail product that screens what goes into an app isn't a data-loss control. They do different jobs.

• Security teams need a second column on every report: what this exposes today, and what it exposes after the next connection.

• Leaders who ask that one question get better answers than leaders who ask for a color.

Which AI app problems should you fix first?

Fix the ones that reach the most sensitive data, and fix them before the app gets wider access. The color on the report comes second.

Turns out the color is the easy part to change. Management can move a "critical" down to a "high" in one meeting. Nothing about the app moves with it.

In October, Josh talked with the security team at a financial firm. They'd built their own internal chat app and tested it themselves. About 25 problems came back. And yes, many of the criticals were later marked down to highs. The app could still reach exactly what it could reach the day before.

What does "reach" mean for an AI app?

Reach is everything the app can see and do on someone's behalf. Think of it as the app's job badge. A badge that opens only the lobby makes for a boring day. A badge that opens the records room is a different story.

Reach has two parts:

• What it can see and do. The data it can read, and whether it can browse the web or change records.

• Who it thinks is asking. If the app treats every person as the same person, it has no way to hold anything back from anyone.

An app with a tiny badge can have a long list of flaws and still not cost you much. An app with a big badge needs only one.

Why does the same flaw go from small to serious?

Because the flaw never changed. The badge did.

On that call, the team's chat app could be tricked into saying things it shouldn't. Annoying, and not much more, because it wasn't connected to anything valuable. But a link to a company data warehouse was about three months out. After that, the same trick could pull real records.

My rule for any feature is that if a user can't predict what'll happen next, it isn't done. For an AI app, that means asking what happens after the next connection, and not only today.

The OWASP project, which publishes the standard list of AI app risks, makes the same point in its entry on sensitive information disclosure. It says to give people and processes only the data they need, and to limit which outside data sources the model can reach. In other words, shrink the badge.

Can a guardrail product handle all of this?

It can handle part of it. Nobody should expect it to handle all of it.

A guardrail product screens what people type into the app and what comes back. That's useful. But a data-loss control is a different job, the one that stops sensitive data from leaving. Someone on that client team said it well: "it's kind of difficult to make a guardrail tool be a DLP tool."

OWASP's list names ten kinds of risk for AI apps. Josh scored several AI security products against that list for a health system earlier this year. They covered different risks, and none covered all ten. Buy for the risks you're weakest on, after you know which ones those are.

The ledger of client calls behind this post shows the question on two entries so far, one in June and one in October 2026. Both involved a product asked to do a job it wasn't built for.

What should a leader ask for?

Ask for one extra column on every security report. It says what each problem exposes today, and what it will expose after the next planned connection.

Then ask two follow-ups. Who owns this fix? And who has to sign off before the app connects to anything new?

If you want the practitioner version, Josh wrote it up for security teams: how to rank an AI app's findings by what they expose. For a test you can run, see how to measure an AI agent's blast radius before the inventory is finished.

Frequently asked questions

Do I need a technical background to use this?

No. You need to ask what each problem can reach, and to read the answer.

Does the severity label ever count?

Yes, as a starting point. Just don't let it decide the order without the reach column beside it.

What if the app isn't connected to anything yet?

Then the problems are small today. Fix the ones that would grow fastest, and set a rule that nothing connects until they're done.

Who should own the ranking?

Security proposes it. The person who owns the data checks it.

Reports tend to get ranked by whoever argues best. Rank them by what the app can touch instead, and the argument gets a lot shorter.