Observed and attested evidence
Developing
Configuration evidence remains separate from interview attestation
An MSP opens an application list and sees ChatGPT, Copilot, an AI meeting assistant, and three products whose AI features arrived during ordinary updates. The list looks alarming before anyone asks what each record proves. I want the next move to be slower: name the application relationship, permission, assignment, and available activity first. Then decide what deserves attention.
The preface of my book declares who it serves, in three sentences I sweated over:
"This book is for them. Not the consultants selling solutions. Not the vendors selling fear. The ones actually running businesses."
That is also the audience test for every AI claim SCOUTz makes. If a sentence about AI capability would impress a conference stage but fail a business owner asking "show me," it is theater, and it comes out. Evidence carries the show, or the sentence comes out. I published that standard in a book with my name on the spine, which makes it inconveniently permanent, and that is the point.
From The 3AM Test by Steve Copeland.
The evidence ladder matters. An application can exist, be installed, be assigned, hold OAuth consent, have a license, show a sign-in, show supported activity, or handle prompt content. Those are different states. Flattening them into "Shadow AI detected" makes the headline scarier and the assessment worse.
SCOUTz operates at the assessment, application-governance, and intelligence layer. Where supported sources expose it, we can review application identity, publisher, permissions, consent, owners, assignments, licensing, and available activity clues. We do not read prompts, employee messages, documents, or private files. We do not claim to be a runtime AI gateway or a complete data-loss-prevention system.
That boundary does not make the evidence weak. It makes the recommendation honest. A broadly permissioned AI application without a clear owner is worth reviewing. A Copilot license assigned to an inactive account may be a spend and governance question. A verified sign-in is stronger evidence than a product name found on a web page.
The MSP's job is to ask what the organization approved, who owns it, what access exists, what activity can be established, and which controls belong around the use case. The answer may involve policy, identity, application governance, data controls, training, runtime monitoring, or several of them.
AI risk is real enough that we do not need to exaggerate it. Keep the states separate, put the source next to the claim, and let the evidence decide how urgent the conversation should be.