Is Your AI a Trusted Advisor or an Untrusted One? A Governance Checklist

Quick answer: Treat AI output the way you would treat advice from an unvetted consultant - useful, but verified before you act on it. Discover your shadow AI footprint first with an AI-BOM, monitor for prompt injection and anomalous behavior at runtime, and map every tool to NIST AI RMF before you trust it with real decisions. Use the readiness checklist and RFP criteria below to pick the right AI-SPM vendor.

Anton Chuvakin's most useful idea from his CISOPlatform fireside chat wasn't a tool or a framework - it was a label. He described AI as an "untrusted advisor": something that can generate real insight and accelerate real work, but whose output must be verified before it's trusted with a high-stakes decision. That one reframing gives CISOs a simple test to apply to every AI use case in their environment.

The shared fate model

Chuvakin distinguished Google Cloud's approach from a generic shared-responsibility model: shared fate means the provider actively helps customers secure their environment, rather than drawing a line and handing over the infrastructure. Whichever cloud or AI vendor you use, ask which model you're actually getting.

Four places AI touches your security posture

Infrastructure security - cloud security fundamentals still apply underneath any AI layer.

Application security - AI-powered applications need their own vulnerability lens, not the one you built for traditional apps.

Data security - sensitive data moving through AI pipelines needs its own controls.

Model security - the model itself is an asset that can be manipulated or attacked, not just a black box.

Shadow AI is already inside your walls

Employees are using ChatGPT, Gemini, and similar tools for work without approval right now, whether or not there's a policy. Chuvakin's point isn't that this is avoidable - it's that ungoverned use is the real risk, not the tools themselves.

Where AI is genuinely earning its keep today

Reverse-engineering malware (Gemini shows particular strength here)

Summarizing security incident reports to save analyst time

Generating tabletop exercise scenarios

Suggesting remediation steps, with the explicit caveat that these still require human validation

The warning worth repeating to your team

Chuvakin flagged a subtle trap: using AI-driven security tools to defend AI systems can introduce shared vulnerabilities between the attacker's tooling and your own. AI is a powerful control. It cannot be the only control.

Untrusted Advisor Checklist

Every AI-generated security recommendation has a named human validator before action

Shadow AI usage is measured, not assumed away, via network and SaaS discovery

Infrastructure, application, data, and model security are each explicitly owned, not bundled into one "AI security" line item

At least one AI-securing-AI dependency has been mapped for shared-vulnerability risk

Test the untrusted advisor, safely: CISOPlatform members can redeem a free AI-powered pentest from FireCompass to see how an AI-driven offensive tool performs against your own environment - a live example of validating AI output before trusting it, the exact discipline Chuvakin described.

Do you actually have a shadow AI problem? A discovery checklist

Have you run a SaaS-API-based discovery scan (via your CASB or SSPM) to find which approved tools have quietly added AI features you never separately approved?
Have you checked for AI workloads running outside your CI/CD pipeline - ephemeral environments, dynamically loaded dependencies, or inference endpoints spun up ad hoc? Static scans and cloud API inventories miss these by design.
Do you have an AI Bill of Materials (AI-BOM) - a mapped inventory of every model, dataset, and library in use, the way you'd maintain an SBOM for software?
Have you classified what sensitive data has already moved through public AI tools before any policy existed?
Do you know, model by model, which AI systems are customer-facing versus internal-only - because the risk profile and disclosure obligations differ sharply?

If you can't answer most of these with evidence rather than a guess, the honest answer is that shadow AI isn't a future risk for your organization - it's a current, unmeasured one.

Questions to ask AI-SPM / AI discovery vendors

Does discovery cover SaaS-API-based AI feature detection and runtime discovery (agents, inference servers, model endpoints), or only one of the two? Static and API-based scans alone miss workloads deployed outside normal pipelines.
Do you generate and maintain an AI-BOM automatically, including third-party models and open-source libraries?
Can you detect prompt injection or anomalous model behavior at runtime, or only misconfigurations at rest?
Do you classify sensitive data within training and inference pipelines, not just in the surrounding infrastructure?
Do your reports map to NIST AI RMF and, where relevant, EU AI Act risk tiers?
How does this integrate with our existing SIEM/SOAR, and what's the actual false-positive rate in production, not in the demo?

RFP criteria for AI-SPM and shadow AI discovery tools

Criterion	What to require
Discovery breadth	Both SaaS-API-based and runtime (e.g., eBPF-based) discovery, not one alone
AI-BOM generation	Automated, continuously updated inventory of models, datasets, and libraries
Runtime monitoring	Detection of prompt injection and anomalous model behavior in production
Data classification	Sensitive-data detection inside AI pipelines specifically, not just general DLP
Compliance mapping	Reporting mapped to NIST AI RMF and applicable regional AI regulation
Integration	Native integration with existing SIEM/SOAR and ticketing workflows
Remediation workflow	Actionable remediation guidance, not just a finding dashboard
Pricing transparency	Clear per-asset or per-seat model that scales predictably as AI usage grows

Vendor evaluation scorecard

Score discovery breadth and runtime monitoring depth highest - a tool that only sees what was formally deployed will systematically under-report exactly the shadow AI usage Chuvakin warned about.

One more thing worth knowing

Ask any cloud or AI vendor to put "shared fate" versus "shared responsibility" in writing in the contract, not just in a blog post - the practical difference shows up exactly when you need it most, during incident response, and a verbal claim of "shared fate" that isn't reflected in the contract's liability and support terms isn't worth much in a crisis.

All Articles