AI Security Readiness: Closing the Gaps AI Exposes

A friendly robot assistant and a woman security lead patching glowing cracks in a large translucent blue shield

When security leaders ask me about AI security readiness, they often expect a conversation about exotic new threats: poisoned models, rogue agents, attacks nobody has seen before. Those exist, and I’ll cover the ones that matter. But the security problems that actually delay AI rollouts at mid-size organizations are almost always old ones.

Oversharing that nobody fixed. Identity that’s strong at the front door and loose once you’re inside. Data nobody classified. Vendors nobody reviewed for how they use your data. Employees using tools IT never approved. AI doesn’t create those gaps. It exposes them, faster and more visibly than anything before it, because an assistant will find and repeat whatever a user can technically reach.

Why AI changes the speed of exposure

Before AI, most overshared files were protected by obscurity. Finding them required knowing where to look, and most people didn’t bother. An AI assistant removes that protection. Ask it a question, and it searches everything the user has access to, in seconds, and presents what it finds fluently.

The same acceleration applies elsewhere. A weak vendor contract becomes a live data flow the day an AI feature is switched on. A permissive app-consent setting becomes an open door the day an employee tries an AI note-taker. The fundamentals haven’t changed. The time between “gap exists” and “gap causes an incident” has shrunk.

The four security questions in the assessment

The security dimension of the AI Readiness assessment asks four questions. Each has its own detailed guide in this series.

  1. Shadow AI: which statement best describes employee use of AI tools today? The goal is an approved alternative plus monitoring, not a ban. See the shadow AI policy your IT team actually needs.
  2. Classification and DLP: how do you classify and protect sensitive data? Labels and DLP are how AI tools know what’s sensitive. See sensitivity labels and DLP before AI.
  3. Identity: how mature is your identity and access management? The assistant inherits every user’s access, so identity is your real AI control plane. See identity is your AI control plane.
  4. Vendor review: do you review how AI vendors handle your data? Two questions added to your existing review cover most of it. See two questions to add to every vendor security review.

The pattern I see most often

When I score mid-size teams on those four questions, the same profile comes up again and again. Shadow AI sits low, because people are using public tools and there’s no approved alternative yet. Classification sits low, because a policy exists on paper but nothing is labeled. Identity is a little higher, because MFA is in place, but access is broad and rarely reviewed. Vendor review is often the strongest, because a process exists; it just doesn’t ask anything about AI. The encouraging part of that profile is that the two lowest scores are also the two that improve fastest once someone owns them.

The risks that genuinely are new

Three AI-specific risks deserve attention alongside the fundamentals:

  • Prompt injection. An AI tool that reads documents, email, or web pages can be manipulated by instructions hidden in that content. It’s at the top of the OWASP Top 10 for Large Language Model Applications. The practical defense for most mid-size teams isn’t clever filtering; it’s limiting what an AI tool is allowed to do, so a manipulated tool can’t do much harm.
  • Agents that take actions. An AI that can send email, change records, or grant access turns a wrong answer into a wrong action. Read-only by default, dedicated identities, and human approval for consequential actions are the controls. They’re covered in APIs before agents.
  • AI-generated content carrying sensitive data. A summary of a confidential document is confidential. Make sure labels carry over to AI output and that your DLP treats it the same way.

The asset: an AI security readiness scorecard

Score each of these seven checks green, amber, or red, and write one line of evidence for each. Evidence matters more than the color; “we think so” is amber at best.

  1. Approved AI tool available to the people who need one, with interim guidance for everyone else.
  2. Unapproved AI use is visible, through web proxy, DNS, or browser logs reviewed at least monthly.
  3. Sensitivity labels exist and are applied to at least your most sensitive data types, with DLP in place for email, cloud storage, and endpoints.
  4. MFA and SSO enforced, with user consent to third-party apps restricted and existing grants reviewed.
  5. Access reviewed for the groups that grant access to finance, HR, legal, and executive content.
  6. AI questions in vendor reviews, covering training on your data, retention, subprocessors, and admin controls.
  7. AI integrations use dedicated identities, read-only by default, with every action logged.

Red flags that should delay an assistant rollout

Most amber items can be fixed alongside a rollout. These are the ones I recommend fixing first, because an assistant turns them into incidents quickly:

  • Sensitive sites shared with everyone in the organization. The fix is in the SharePoint oversharing cleanup.
  • MFA not enforced for all users.
  • Any user can grant third-party apps access to organizational data.
  • No idea which AI tools are already in use.

None of these requires new spending for most organizations. They require admin time and decisions, and a delay of about a month is usually enough to address them.

A 90-day security plan for AI

Days 1 to 30: contain. Fix the red flags above. Stand up an approved AI tool and publish interim guidance. Turn on logging for AI site usage. Restrict app consent.

Days 31 to 60: classify and review. Roll out a small set of sensitivity labels and DLP in audit mode. Run the first access review on sensitive groups. Add the AI questions to vendor reviews and apply them to your top SaaS vendors.

Days 61 to 90: enforce and extend. Move DLP from audit to warn and block for your most sensitive data. Extend DLP to AI tools and browser uploads. Put dedicated identities and logging on every AI integration. Publish or update the AI acceptable use policy to match the controls you now have.

At the end of 90 days, most mid-size teams can move their security dimension up by one to two levels on each question.

What AI security readiness is not

It’s not a new security tool. AI security products exist and some are useful, but most mid-size teams get further by using the controls already in their licenses.

It’s not blocking AI. A ban without an alternative pushes use onto personal devices, where you have no visibility at all.

It’s not only the security team’s job. Business owners decide what’s sensitive; HR and legal shape the policy; IT runs identity. Security coordinates.

How security fits with the other five dimensions

Security is one of six dimensions in the AI Readiness framework, and it’s the one most likely to produce red flags that override an otherwise good score. It overlaps with data (permissions and classification) and governance (policy and vendor oversight). For the full framework, see the 6-dimension AI readiness framework, explained.

Where does your team actually stand?

The free AI Readiness Score includes security questions alongside the other five dimensions. It’s 10 questions and gives you a score in a few minutes.

Get your free AI Readiness Score →

Want to see what the full assessment covers first? Flip through a complete 38-page sample report.

Related guides

Frequently asked questions

Does AI create new security risks?

A few, such as prompt injection and agents that take actions. But the problems that most often delay AI rollouts are old ones: oversharing, broad access, unclassified data, unreviewed vendors, and unmanaged tools. AI exposes those gaps faster, because an assistant can find and repeat whatever a user can reach.

What should be fixed before rolling out an AI assistant?

Four red flags: sensitive sites shared with everyone, MFA not enforced for all users, users able to grant third-party apps access to organizational data, and no idea which AI tools are already in use. Most organizations can address them in about a month without new spending.

How do you defend against prompt injection?

For most mid-size teams, the practical defense is limiting what an AI tool is allowed to do. Keep integrations read-only by default, use dedicated identities with narrow permissions, require human approval for consequential actions, and log everything, so a manipulated tool can't do much harm.

What does a 90-day AI security plan look like?

Days 1 to 30 contain the red flags and stand up an approved tool. Days 31 to 60 roll out labels and DLP in audit mode, review access, and add AI questions to vendor reviews. Days 61 to 90 enforce DLP, extend it to AI tools, and put dedicated identities on every AI integration.

Scroll to Top