In this Help Net Security interview, Brandy Wityak, VP of Complex Matters at LevelBlue, explains what happens in the hours after a shadow AI incident.
She describes how quickly logs roll over, why firewall records of outbound traffic to AI platforms are often gone before responders arrive, and what regulators look for when they assess whether a company did enough. Wityak also discusses the gap between an AI policy in a wiki and a control a company can defend, and when documentation helps or hurts.
When you walk into an organization after a shadow AI incident, what is the first artifact you ask to see, and how often does that single request surface a gap the company didn’t know it had?
The very first artifact to be requested should be the user’s endpoint being secured. Any logging, which might show any user action should also be preserved to prevent rollover.
Typically, this will lead to an organisation not knowing or understanding which logs they have or indeed where they keep them.
On numerous occasions we have asked for logs only for the organisation to come back three days later saying they can’t find them, or that they don’t actually store them even though they thought they did. In some cases they weren’t logging certain events at all, despite believing they were. The gap between what an organisation thinks its logging environment looks like and what it actually looks like is one of the most consistent things we see.
How long after an incident does the evidence window begin closing, and what specifically is the first thing to disappear?
It starts closing the moment the incident occurs. Logs have limited retention periods and will begin to roll over immediately. The first thing likely to have already gone is firewall logging showing outbound connections to AI platforms — api.openai.com, claude.ai, gemini.google.com. Those connections are often the clearest evidence of what data left the organisation and when, and they are frequently no longer available by the time we are engaged.
If the data never left the endpoint at all, the situation is even more time-critical. The window further shortens, if evidence exists only on the user’s endpoint and is held in memory. Every action the user takes on that device after the incident, risks overwriting that data permanently. In those situations, the speed at which the endpoint is secured is everything.
Walk us through the difference between a regulator who concludes an organization was unlucky and one who concludes it was negligent. What specific piece of evidence, or absence of it, tends to tip that judgment?
It is unlikely a regulator would conclude an organisation was simply unlucky. The incident will be measured against the regulatory standards the organisation is bound by. Under UK and EU GDPR, that means whether appropriate technical and organisational measures were in place relative to the risk.
The use of shadow AI by an employee is never unlucky from a regulatory perspective — the organisation may be found to have failed in its duties and held accountable. The central question in shadow AI incidents is likely to be whether the organisation took measures within its power to restrict employee activity and mitigate risk. That is where the judgment tends to land.
Plenty of companies have an AI usage policy sitting in a wiki. How does a regulator distinguish a policy that merely exists from a control that demonstrably functions, and which side of that line do most companies fall on?
Currently, we believe most companies are at the start of the maturity journey around AI governance and technical controls. The question is not simply, do they have a particular control – whether that be a written policy, governance plan, or technical restriction. It’s whether the actions of the organisation to mitigate shadow AI risk was appropriate.
The regulator will cite instances where the organisations didn’t present evidence (or that it was insufficient) for why they didn’t have a particular control. Organisations that have a good record of documenting their decisions and reasons for some non-implementation will have a leg up in building a narrative after the fact. This is particularly important for issues like legacy systems that may not be able to be in full compliance with current guidance – thorough vetting of mitigations and compensatory controls will be essential. Most organisations are not there yet, which is why the gap between having a policy and being able to defend it to a regulator remains wide.
Is there a scenario where over-documenting works against a company, by creating a paper record showing a known risk was identified and then ignored? How do you counsel clients through that tension?
We have seen scenarios where an organisation has documented that certain controls are required but simply haven’t been implemented, which not only affects regulatory outcomes, but insurance coverage as well. Almost every incident we deal with involves an organisation telling us the improvement or patch was on their roadmap and just about to be implemented.
The answer to this tension is better governance around what happens after something gets written down, not less writing. If a decision is made not to address a risk immediately, write down why. Note what mitigating controls are in place in the meantime and when the issue will be revisited. A paper trail that shows a reasoned, considered decision is defensible. A paper trail that shows something was flagged and then forgotten is not.
Download: The ultimate guide to network operations management