TL;DR: Start your AI alerts from failures, not from logs. Write five to ten AI events your security operations center (SOC) would open a ticket for. Beside each one, write the first check an analyst makes. Those checks pick the logs you collect. Identity and data movement come first. Prompt content comes last and never pages anyone.
Key takeaways:
Security teams raised AI watching on six client calls between August 31 and October 8, 2026, and the October 8 team showed what happens when logs come before decisions.
On October 8, 2026, a SOC lead at a large manufacturer called the company's AI policy "a paper policy." Blocking needed senior approval that hadn't come, so the cost showed up in SOC hours, one alert at a time.
Two detections need no new log feed: large or frequent uploads to AI sites, and new OAuth approvals for AI apps (OAuth is the "sign in with" permission an app asks for).
NIST's Cybersecurity Framework 2.0, published February 26, 2024, defines Detect as possible attacks being "found and analyzed." The October 8 team had the finding and lacked the analyzing.
Prompt and chat content is an investigation source. Legal and privacy teams should rule on it before anyone collects it.
What should a SOC alert on first when staff use AI?
Start with the failures. Write down five to ten AI events your security operations center would open a ticket for. Beside each one, write the first thing an analyst would check. Those checks tell you which logs to collect. The October 8 team opened the other way around.
The same question reached me on six client calls: August 31, September 3, September 28, October 1, October 5, and October 8, 2026. Each team wanted a way to watch AI use at work. The October 8 team opened by asking which logs to turn on.
That order fails. Logs are cheap to turn on and expensive to read. A SOC that collects everything gets everything, and none of it ties to a decision. On the October 8 call, a SOC lead at a large manufacturer described "an avalanche" of endpoint and network alerts. Analysts checked each user against the approved groups in Active Directory by hand.
NIST splits detection into two jobs in its Cybersecurity Framework 2.0. One is continuous watching, where assets are monitored for anomalies and other adverse events. The other is adverse event analysis, where those events are analyzed to decide whether an incident is under way. The October 8 team had alerts in volume. It had no written list of which AI events deserved a ticket.
Which AI failures belong on the first list?
Start with four. A bulk upload of design files to a personal AI account. A new app connection approved for an AI service. An AI agent fetching data the person prompting it couldn't reach. Audit logging switched off, or a connector turned on company-wide. Each one is a ticket an analyst would open today, and each has a clear first check.
I gave the October 8 team those four starters. The target is five to ten failures in total, and a failure earns a spot only if someone would act on it. Here's how each starter pairs a first check with a log you probably have:
Bulk upload to a personal account.
First check: is the account company-managed, and was the data sensitive? Log: web proxy or endpoint upload records.
New app approved for an AI service.
First check: who approved it, and which permissions did it ask for? Log: the identity provider's consent record.
An AI agent reaching data the requester couldn't.
First check: whose identity did the agent use, and does it match the requester's own access? Log: the cloud app's audit log.
Audit logging off, or a connector on for everyone.
First check: who changed the admin setting, and when? Log: the AI platform's admin audit trail.
Look at what happened to the log list. It fell out of the checks, so nobody had to guess which feeds to buy.
Which two AI detections need no new log feed?
Alert on large or frequent uploads to AI sites, and on new OAuth approvals for AI apps. Both work from logs a SOC already receives. Uploads show up in web proxy and endpoint data. Approvals show up in the identity provider's consent record. That's why they go first.
The October 8 team already caught bulk uploads, and it had playbooks for them. New app approvals are the natural second detection. I wrote up how to read those approvals as a free inventory in our post on OAuth consent grants. The consent record tells you which AI apps people connected to company accounts, who approved each one, when, and what each can reach.
Both detections sit on identity and data movement. Those are the signals that hold up. A person signed in and files moved. Neither fact depends on reading what anyone typed.
Why shouldn't prompt content page the SOC?
Prompt and chat content works as an investigation source and makes a poor alarm. It's private, and using it takes a ruling from legal and privacy teams first. Identity events and data movement make reliable alerts. Pull content after one of those fires, and only under rules the company has already written.
On October 8, one of the incident responders asked the question directly: "Should it be all logs, activity, chat?" He added that the feed his team had tested for Claude showed only the conversation's title, and he wondered if that was enough.
For detection, it's enough. A title plus the identity and the data movement tells an analyst what to check next. Reading the chat comes later, and legal should know before it happens. I told the team to bring legal and privacy in before anyone pulls prompt content from a vendor's compliance interface.
What if the SOC doesn't run the AI platforms?
Write the list around what the SOC already receives. At the October 8 company, a workplace technology group administers the AI platforms, and security sees access only through user groups. Pick the failures visible in proxy, endpoint, identity, and cloud app logs, and ask the platform owners for the rest.
That team also had a counting problem. Three inventory tools each showed which AI apps were running. In the lead's words, "every tool seems to give us a different picture." A written failure list settles the argument, because each failure names its own source.
There was a second pressure. When the company announced a partnership with an AI vendor, personal accounts went up. Staff read the announcement as permission. The policy banned personal AI, but the SOC couldn't block it. The lead's name for it was "a paper policy."
One fix is a proxy that adds a header telling the AI service to accept only company accounts. It turns part of a paper policy into a control, and it needs no company-wide blocking vote. It has limits. The post on why security tools can't see what AI agents do covers the blind spots that remain.
How do you start this week?
Spend one hour writing the failure list. Spend the next week confirming that each failure's first check can be answered from a log you hold. Then run 60 days of discovery, with coaching messages to staff, before you buy anything. Whatever the list still can't see tells you what a new product has to cover.
For each AI platform, walk six layers: identity, platform audit feeds, endpoint, network and egress, data, and agent tracing. Give every layer five yes-or-no columns:
Who owns it?
Is the feed on?
Does it reach the SIEM, the system where security alerts are collected?
Is one detection written?
Has anyone tested it?
The October 8 team asked me to read those five columns twice. One of them wrote them down. A blank cell is a task with a name beside it. And the first cells to fill are the ones in the identity and data layers, because those are where the first two detections live.
Frequently asked questions
Do we need a new AI security product to start?
No. The first two detections use proxy and identity logs that most SOCs already collect. Run the list first. Whatever it can't see after 60 days becomes your shopping list.
Should we ingest prompt and chat content?
Not as a first step. Identity and data movement carry the dependable alerts. Content is something an analyst reads during an investigation, after legal and privacy teams say who may read it and for how long.
How many failures should the list hold?
Five to ten. Fewer than five leaves the SOC guessing. More than ten turns the list into the avalanche you started with. Add a failure only when someone would act on it.
What do we do about personal AI accounts if leadership won't approve blocking?
Alert on large or frequent uploads, and pair that with a proxy header that limits sign-in to company accounts. Add coaching messages while you collect 60 days of data. The data is what you'll take back to leadership.
Who owns the failure list?
The SOC owns the detections. Each AI platform has its own administrator, such as a workplace technology group, who owns the settings and the audit trail. One named person owns the list as a whole and keeps the five columns current.
The failure list won't catch every AI failure. It gives the SOC five to ten events it can act on Monday morning, which is five to ten more than a paper policy hands it.