The First 24 Hours of an AI Agent Attack: Incident Response and Agentic AI Governance — With Commvault's Danielle Sheer

Episode Summary

What happens when the attacker inside your network isn’t a person at all? David Simon and William Ridgway, co-heads of Skadden's Cybersecurity and Data Privacy Practice, walk through the first 24 hours of a hypothetical AI agent attack, from containment to law enforcement and notice obligations. They also share takeaways from recent conversations at the Brussels Privacy Symposium and Incident Response Forum. Danielle Sheer, chief legal and trust officer at Commvault, also joins the conversation to discuss the evolving role of chief legal officers as AI accelerates the importance of trust. Tune in for Danielle's insights on why companies should supervise AI agents like employees and how to build credibility with the board before a crisis.

Voiceover (00:00:01):
From Skadden, Decrypted is a podcast exploring the latest developments in cybersecurity and data privacy strategies, risks, and regulations.

David Simon (00:00:11):
Hello, everyone, and welcome back to Decrypted, Skadden's podcast on cybersecurity, data privacy, and AI, where we look at how these issues play out inside companies and boardrooms and during actual incidents. I'm David Simon, Co-head of the Cyber and Data Privacy Practice at Skadden and formerly the Pentagon and the Cyberspace Learning Commission.

William Ridgway (00:00:30):
Hey, everyone, and I'm Bill Ridgway. I co-lead the practice with Skadden, and we're grateful for you all joining us.

David Simon (00:00:36):
Today, we're walking through the first 24 hours of an AI agent attack from the perspective of the company being attacked. What should happen in the first two hours? How do you interrupt the activity? What evidence do you need? When do you call law enforcement or other government authorities? What's the role of legal counsel and privilege and who must be notified, and what would give you confidence that it's safe to restore operations? Later on, we'll hear from Danielle Sheer, the Chief Trust Officer and Chief Legal Officer of Commvault. And she's going to share with us her perspective on the evolving role of chief legal officers, the role of chief trust officer, and also what it all means in an age where AI is accelerating the importance of both functions.

William Ridgway (00:01:16):
In our last episode, we discussed the Hugging Face incident and the questions it raises about autonomous agents. We also welcomed the Financial Times' Elaine Moore for a conversation about AI and the challenges facing business leaders. Today, we're really taking the next step. What does it mean for a company receiving the incident response call?

David Simon (00:01:33):
And we're returning to the format of our very first episode when we walk through the first 72 hours of a ransomware attack. This time, there will be no ransom note, no demand, and no person on the other side explaining what they want.

William Ridgway (00:01:47):
And unfortunately, your company doesn't need to have deployed an AI agent to become the victim of one.

David Simon (00:01:52):
Before we start though, we wanted to share with you a few reflections on some recent developments before we get into that scenario. It's October everyone, which is Cyber Awareness Month, and Bill and I have both been out talking with people, talking with clients, with key stakeholders and opinion leaders working through these issues. I just returned from Brussels where I attended the Future Privacy Forum in Brussels Privacy Hubs, a symposium, and had a chance to interact with some of the key opinion leaders in industry, but also folks in the EDPB and the EU AI Office. There was some substantial discussion about the Digital Omnibus, about the relationship between GDPR and AI, the AI Act, how Europe can make its digital rules easier to apply when preserving protections that are really relevant today. And one of the things I thought I'd call out is I had a chance to speak with Carolina Foglia, who is the head of a legal affairs function, Head of Sector at the European Data Protection Board Secretariat.

(00:02:45):
And one point that she emphasized was the need to tackle the interplay between data protection law and the other major laws in Europe's digital rule book. Companies do need to understand how those obligations work together when applied to the same system, the same data and the same activity.

William Ridgway (00:03:00):
And David, maybe you could share what should a general counsel or chief privacy officer take away from all of that?

David Simon (00:03:05):
First, you watch for implementation guidance. Carolina pointed to forthcoming detailed guidance on safeguards and emphasized the EDPB's role in developing templates and promoting harmonization across the European Union. As you know, different data protection authorities take different approaches, but it's the role of the EDPB to help explain how to take that approach in a harmonized way across. Those tools can make a real difference to how companies document decisions and demonstrate compliance across jurisdictions. But companies can already identify where their privacy, security, and AI governance processes overlap and where they produce inconsistent answers. So for a general counsel, this means establishing a coherent view of the company's obligations. For a chief privacy officer, it means connecting the data protection analysis to how the system operates. And for a CISO, it means helping translate safeguards into controls, permissions, access restrictions, logging, and the ability to intervene.

William Ridgway (00:03:58):
So it certainly seems like these important and sometimes disparate teams, they need a shared understanding of the system even though they're looking at different risks.

David Simon (00:04:06):
Exactly. Second, anonymization is a hot topic and it's getting renewed attention. Carolina highlighted the EDPB's request for public input as it revisits the guidance and this consultation's open till the 30th. So as many folks who are GDPR watchers know, anonymization has continued to be a challenge because it's really in the eye of the organization or individual that is most relevant for that personal data. If your AI or analytics strategy depends on treating information as anonymous, the supporting analysis does matter a lot. Removing names alone doesn't resolve this whether someone could reasonably be identified using other available information. And as we know, with the advent of generative artificial intelligence and many of the more advanced tools, re-identifying individuals is a lot easier than it used to be even for an ordinary user. Privacy and security teams should test those assumptions together about re-identify how you would anonymize.

(00:04:57):
Companies with practical evidence about what works or where the proposed guidance is difficult to apply have an opportunity to contribute to that discussion, that public consultation.

William Ridgway (00:05:05):
Got it, David. Anything else stand out to you?

David Simon (00:05:07):
European Data Protection Supervisor emphasized the importance of the purpose of the processing itself. So my takeaway was that using AI doesn't eliminate the need to explain what the company is trying to accomplish, why it needs the data and how the activity fits within an applicable rule.

William Ridgway (00:05:22):
Did you hear anything from the AI office about whether the AI Act can keep up with agents that we're seeing?

David Simon (00:05:27):
I had a chance to speak to Margherita Corrado who's a lawyer in the office and emphasize that the AI Act's capacity to accommodate technological change is significant. It was really built to evolve and to adapt as our understanding of AI does evolve and adapt to different types of deployments and circumstances. And this is especially important when asked about the role of autonomous agents, of AI agents.

(00:05:49):
So I would frame that really carefully. Article 112, for example, provides for evaluation review of the framework, and it's really part of the machinery for assessing whether rules need to evolve as capabilities and risks change. So many people ask, how do I think about AI agents in light of the AI Act? And I think the answer is it's not really that different. It's really just about asking the same fundamental questions.

(00:06:09):
She also emphasized fundamental rights protections and both representatives from the EDPB and also Margherita Corrado of the AI Office emphasized that really this is about the Charter of Fundamental Rights. Protecting the rights enshrined in the EU Charter is an expressed objective of the legislation alongside safety and functioning internal market and supporting for innovation.

William Ridgway (00:06:28):
So what does that mean for a company deploying an AI agent today?

David Simon (00:06:32):
So it means you shouldn't assume a new technology label takes the activity outside the existing framework. You have to examine the system's intended use, what it can do, whom it can affect, and the role of your company. For a general counsel, that means assessing existing obligations while tracking these changes. And for privacy as an officer, it means keeping the GDPR analysis connected to AI governance. For CISOs, it would mean making controls proportionate to the agent's authority, especially when it can change records, communicate externally, or take consequential actions. The message I took from these sessions in Brussels is that companies have implementation work to do now, even as the policy debate continues. Now, Bill, you were at the Incident Response Forum in Beverly Hills, isn't that right?

William Ridgway (00:07:12):
That's right.

David Simon (00:07:13):
So I understand the agenda included some of these same issues, AI and cyber attacks, third party incidents, privacy obligations, and the evolving landscape. What would you highlight?

William Ridgway (00:07:22):
Yes. Well, I would say I wish there was a bit more sunlight than I anticipated, but on the substance, there were three questions that I think are worth going through for this team. So first, what can your defenders actually do at the speed of attack? Obviously the program included a session on AI in both attack and defense. The practical question is what your tools and providers can detect and interrupt and what still depends on someone reviewing an alert and approving an action. So if you rely on automated containment, it's something you ought to test, know what it can disable, what disruption that could cause, and who has approved those boundaries. A second issue that was emphasized is really how dependent is your response on another company? Obviously, third party supply chain incidents remain a focus. You may need a provider's logs, assistance, or access to controls to help it stop the incident. And that makes your contracts and escalation arrangements certainly operationally important. Who answers the call? What evidence can you obtain? How quickly can you revoke the connection?

(00:08:19):
There's also an important set of questions around whether your contract gives you a right to reimbursement for costs, and those are worth evaluating now before an incident strikes.

(00:08:27):
And the last thing that I thought was interesting, we heard from the lead prosecutor in the Central District of California focusing on cyber to discuss the President's National Security Memorandum around cyber offensive capabilities for the private sector, which we have talked about in the past and we've certainly done some writing on. During that conversation, I thought it was interesting. It struck me that DOJ may not be viewing this memorandum as broadly as others in the industry because the examples that were discussed involved botnet take downs and the like that frankly have long been an area of coordination between DOJ and the private sector.

(00:09:01):
And at least at the meeting, the DOJ certainly disavowed any interpretation that would allow hacking it back. So as we discussed previously, we're still waiting on the key details for this memorandum, but I thought it notable that there are at least some in federal government who don't anticipate this being quite the sea change for the private sector as some predicted.

David Simon (00:09:19):
That's really interesting. I think for folks in industry to be hearing that and knowing that they're taking a more narrow view of that authority is instructive, particularly for companies that are looking ahead at trying to be a part of that program. These are particularly interesting questions too, given the role of AI agents and how many organizations are thinking of them as a vendor or a third party.

William Ridgway (00:09:39):
Exactly. The authority to act, access to evidence, and coordination with the people controlling the affected systems are all things you need to prepare for before the incident.

David Simon (00:09:48):
One resource that we'll turn to today as we think about this sort of AI tabletop we're going to walk through with you here is the AI Underwriters Company's standard AIUC-1, which we see a number of organizations starting to take an interest in. There's a consortium focused on it. The AI security and assurance standard has been developed with input from a number of different stakeholders, particularly respected CISOs. Its work does draw on an important distinction that companies need to defend against autonomous attacks from outside while ensuring that agents they deploy stay within their own authority.

William Ridgway (00:10:19):
That's right. And we should distinguish the standards requirements from its implementation examples and the consortium's broader recommendations. So terms like mandatory within the standard don't automatically mean required by law. We're using those materials alongside incident reports and other guidance to build a practical response. So AIUC-1 doesn't prescribe a universal two-hour or 72-hour incident response timetable.

David Simon (00:10:44):
That's right. I mean many clients are asking us, how do I secure AI agents? What are the standards? This is just one standard that's really configuration based. There's others like OWASP and obviously NIST and ISO. And I think the key thing is this is just one way to frame our discussion today. Our scenario today starts with an outside attack. Later we'll see how that intrusion can affect the company's own agent.

(00:11:04):
So let's get started. It's Monday morning at 8:15. Our fictional company is a multinational business with US and European operations. It holds customer information, proprietary technical documents and credentials connecting different parts of the business. And at 8:15 on that Monday, security detects unusual outbound traffic. A service account is accessing documents it doesn't normally use. Unfamiliar commands are running in a cloud environment and blocking one connection doesn't stop the activity. Several accounts and workloads are probing different applications at the same time.

(00:11:38):
The business is still operating. There is no ransom note. Nobody yet knows whether AI is involved. Bill, what happens next?

William Ridgway (00:11:46):
Well, this is probably going to be a more common scenario. So at the very least, let's activate the incident response process. We have evidence of potentially unauthorized activity. We don't need to decide whether the attack is a person, an agent, or a person using an agent before starting the response. So you bring together security, the infrastructure and identity odors, legal, relevant business leaders, and outside responders as appropriate and established command and secure communications.

David Simon (00:12:12):
So here we're using the existing cyber incident response structure.

William Ridgway (00:12:15):
Right, exactly. With additional expertise where needed. You don't want an argument about which committee owns AI while someone is downloading your files and the work overlaps. Evidence preservation, legal assessment, government engagement and communications, they all begin at the outset.

David Simon (00:12:30):
Okay, so let's start thinking about the first two hours and also how this framework, the AIUC-1, can help in those first minutes.

William Ridgway (00:12:36):
Sure. It's response planning requirements call for accountable owners, notification and remediation procedures and outside support where needed. Its evidence guidance contemplates capabilities to freeze effective systems and preserve evidence. So the immediate question is whether your named responders have the authority and technical support to act.

David Simon (00:12:55):
As you're thinking about this in the first two hours of an incident like this where AI agents are attacking your enterprise, a lot goes into containment stopping the bleeding, et cetera. So your security wants to disable an account supporting the customer transactions. Operations says that will disrupt business. So who makes that decision?

William Ridgway (00:13:13):
Yeah, your plan should identify what security can isolate immediately and what requires executive approval with an alternate if the decision maker is unavailable, which happens. Someone must weigh the harm of the interruption against the harm of continued unauthorized access, document the decision and its basis. Waiting also has its consequences though.

David Simon (00:13:31):
That's right. The team might disable the account, but activity is continuing through another credential and then a scheduled job is still running.

William Ridgway (00:13:38):
So now we know the containment is incomplete. So we got to check active sessions, additional credentials, delegated access and work that has already been launched. Changing a password may not terminate every session or invalidate every token. So stopping the process you first notice may not stop a job if it was created.

David Simon (00:13:56):
So let's distinguish between the external attacker on the one hand and an internal agent. And again, we're sharing with you our perspective on what should happen. We're lawyers here. Naturally the internal security teams and hopefully a forensics firm would be helping to make sure this is all happening.

William Ridgway (00:14:10):
Right. Now for an external attacker, you generally cannot switch off its model. You control your infrastructure, access paths, identities, applications, network boundaries, and affected workloads. For an internal agent, you may also control its execution environment, tools and scheduled work. So AIUC-1's controls unauthorized actions and tool use help identify those intervention points.

David Simon (00:14:34):
This means what services it can reach, what tools it can call, and what happens before a tool actually executes, right?

William Ridgway (00:14:40):
That's right. Are permissions and parameters checked? Can you disable an integration or remove the agent's privileges? Suspending a workflow or revoking access is a response decision informed by those controls. A standard doesn't prescribe one shutdown procedure for every incident.

David Simon (00:14:56):
So asking the agent to stop isn't the same as removing its ability to act.

William Ridgway (00:15:00):
Right. You need enforceable restrictions outside the model's own instructions.

David Simon (00:15:04):
And recent reports illustrate why this escalation is really important. OpenAI described 30-minute assessment window after paging for its most severe alerts with activity paused unless responders establish a false positive. The UK AI Safety Institute reported containment within roughly an hour of discovery. Those are examples from environments those organizations actually controlled. They're not universal enterprise deadlines or measures of how quickly the original activity was detected.

William Ridgway (00:15:32):
They certainly reinforce the need for a process that can act quickly though.

David Simon (00:15:36):
So we're also seeing attempts change after our systems reject them. Failed commands are followed by revised commands and activity switches to a different application. Is that evidence of AI?

William Ridgway (00:15:48):
I suppose it's consistent with agent-driven execution, but it isn't proof. Conventional automation and coordinated human attackers can also adapt as well. So speed, many IP addresses or simultaneous activity do not necessarily establish that you're facing an AI swarm.

David Simon (00:16:05):
What evidence should we secure while containment is happening?

William Ridgway (00:16:09):
Certainly conventional identity endpoint cloud application and network records remain essential for internal agents. AIUC-1 requires activity logging where permitted. Additional evidence examples include tool parameters and results, delegated tasks, approvals, and execution context. So preserve relevant evidence that's available, protected against alteration and apply appropriate access and retention controls.

David Simon (00:16:35):
And just to underscore, many organizations may not actually receive this type of evidence, so it's important to ensure in advance that you have access to that kind of telemetry so you can actually analyze what's happened if it does. But one key question is what if the attacking agent appears to belong to another company?

William Ridgway (00:16:51):
And here's where you need to request the relevant records promptly. You don't want to make your investigation dependent on receiving those though. Establish what happened in your environment using your own evidence, distinguish proposed, attempted, blocked, and contemplated actions. An agent saying it downloaded a file doesn't prove the download succeeded.

David Simon (00:17:09):
Logs can themselves contain sensitive information as we've seen.

William Ridgway (00:17:12):
That's right. Evidence preservation doesn't mean indiscriminate collection of unrestricted access, protected personal information, secrets, and confidential business material can be in the evidence.

David Simon (00:17:23):
And now again, if you're following the AIUC-1 approach, this also does address monitoring third party connections. That matters when an intruder acts through a legitimate integration.

William Ridgway (00:17:33):
Right. Establish which connection was used, what it accessed and when, and that will help you identify where to intervene and which provider's assistance you need.

David Simon (00:17:42):
Can our security provider use defensive agents to accelerate the response?

William Ridgway (00:17:45):
Good question. Potentially, but certainly examine their authority. Correlating alerts is different from disabling a production identity or changing network rules. So use tested automation with clear boundaries and records of what it does. Higher impact actions may require human approval here. That approval process must work during an active incident.

David Simon (00:18:05):
And that authorization, it has to cover where the defensive tools actually operate. Finding the source of an attack doesn't give an agent permission to enter somebody else's systems.

William Ridgway (00:18:15):
That's right. Keep defensive actions within the authorized boundaries. If intervention elsewhere is needed, you got to coordinate with that provider, the system owner or law enforcement.

David Simon (00:18:25):
So let's talk more about law enforcement here. We've got this many different pieces moving very quickly. Do we wait until we can prove this is AI before calling the FBI?

William Ridgway (00:18:34):
Not necessarily so. I mean, in this scenario we have a significant unauthorized intrusion, so you can engage the appropriate FBI field office early alongside with relevant reporting channels, explain what we know, distinguish the evidence from hypotheses, and ask whether investigators are seeing related or similar activity.

David Simon (00:18:53):
And of course, many clients will reach out to us to do that initial outreach to law enforcement, but you don't have to do that, but it is important to engage with clarity and making sure that you're doing it with a strategic objective in mind. So what do we bring to that conversation?

William Ridgway (00:19:06):
Yeah, I think you want to certainly have kind of a factual timeline, the technical indicators of the affected systems, known harm and a point of contact, coordinates evidence sharing through response team and council, preserving originals and considering privilege, privacy and other restrictions. You don't need a completed forensic report to have that initial outreach.

David Simon (00:19:27):
Should we also report to the cyber agency here in the US?

William Ridgway (00:19:31):
Yeah, I mean, you can consider CISA for operational coordination and information sharing, particularly where critical infrastructure or multiple organizations may be affected. Relevant sector agencies and trusted information sharing organizations can also help you connect the dots. Assistance depends on the circumstances though. A report isn't a guarantee of a particular operational response.

David Simon (00:19:54):
And what about for the company's European operations?

William Ridgway (00:19:56):
Sure, you want to identify the relevant CSIRT and component authorities and coordinate with national cyber crime investigators where appropriate. Those operational investigative relationships sit alongside the regulatory notices that we'll be talking about in a minute.

David Simon (00:20:10):
And of course, we're not going into depth here, but under the Cyber Resilience Act, there could be a 24-hour notification obligation if it's impacting products or digital elements in the European Union and it's a severe incident or an actively exploited vulnerability, which sounds like this could implicate we don't know at this time. So look, if government engagement has several purposes, what do we focus? We would be helping to establish whether this is a broader campaign. We would want to exchange useful indicators and coordinate action beyond systems we actually control. We also think about how to protect the business because we really don't know the scope yet and we can't lose control by handing over the keys to government authorities.

William Ridgway (00:20:48):
Right. And of course, contacting law enforcement does not by itself satisfy regulatory reporting duties, including the ones you just alluded to, David. If a delay is available under a particular law, you can follow that specific process, but don't assume that opening an FBI investigation gives you a blanket extension in all of your deadlines.

David Simon (00:21:07):
So now that's a lot of stuff to happen in the first two hours, but let's just think about, okay, hours two to six. Two hours in, a provider says some traffic may be associated with an externally operated AI agent and the investigators, they find a shared task file containing assignments, results, and newly discovered access paths. Different processes are picking up unfinished tasks and one process discovers credentials, another uses them, and a third continues after we block the first two. Are we dealing with several independent attacks or agents coordinating?

William Ridgway (00:21:41):
Yeah, it certainly seems like we have stronger indication of coordination. We still need evidence to establish whether these are in fact AI agent scripts or a combination, preserve the task records, correlate them with the identities, execution times and the actual activity.

David Simon (00:21:56):
So a possible agent collective or agent swarm, we don't use the label as a substitute for understanding the actual architecture, what's really happening.

William Ridgway (00:22:05):
Yeah, that's right. The operational question is what connects the workers that share credentials, task queues, infrastructure or communication channels. Blocking one connection may leave the rest operating, so containment must address the paths we can control and a provider or government cooperation may be needed for activity elsewhere.

David Simon (00:22:26):
So the CEO then asks whether the company can call the operator and have everything turned off.

William Ridgway (00:22:32):
In that scenario, I think you can establish contact through a verified security channel that asks for interruption of the relevant activity, preservation of evidence, and technical cooperation. A stopped run doesn't establish that your environment is clean. The agents may have left credentials, processes, or changes behind.

David Simon (00:22:49):
Now investigators discover the intruder altered a document used by our procurement assistant. That assistant followed instructions embedded in the document and accessed information outside its intended task.

William Ridgway (00:23:02):
So now we have both an external intrusion and a manipulated internal agent. The AIUC-1 questions become quite practical. Did the agent exceed its intended scope? Did an approved tool execute an unauthorized action? Which control should have prevented it?

David Simon (00:23:17):
Does deleting the document solve the problem?

William Ridgway (00:23:20):
Not necessarily, David. You got to check whether the instructions or effects persisted elsewhere, whether the work was delegated and whether business records changed. So follow the evidence to related runs, identities, integrations, and systems. You'll need to have a defensible investigative boundary and you can revisit it as the facts emerge.

David Simon (00:23:39):
Now, Anthropic's retrospective investigation is useful here. Its initial search apparently missed another incident and then the review expanded. The lesson is to challenge the assumption that the first activity discovered was the only activity.

William Ridgway (00:23:53):
Right. And really keeping this evidence driven. Not every incident requires an unlimited review of every system, right?

David Simon (00:24:00):
So what would you want to know by hour six?

William Ridgway (00:24:03):
Which paths have been interrupted and what might still be running, which systems and parties could be affected and what important questions remain unanswered? Those are objectives, not a promise of complete answers, certainly within six hours.

David Simon (00:24:15):
Now an outside agent has entered the company systems without permission. Where does the Computer Fraud and Abuse Act fit in? I mean, if I'm not mistaken, you used to prosecute these cases.

William Ridgway (00:24:26):
I am quite familiar with a Computer Fraud and Abuse Act. It's our main tool here, and it certainly can be relevant here to unauthorized access and computer damage, and it can support the criminal investigation where the requirements are met as well as civil claims, but we can't jump from a AI agent enter the system to the model developer is somehow liable. We need facts about who directed or operated the activity, what they authorized or knew, the applicable mental state requirements, and certainly causation.

David Simon (00:24:54):
So the AI did it, doesn't end the inquiry, but autonomy can complicate the attribution, I would think.

William Ridgway (00:25:01):
Yeah, that's right. You want to preserve the access evidence and communications instructions where available, as well as the operational timeline. So document the response and restoration costs and business disruption as well as potential damages and distinguish unauthorized access from misuse of information somehow they were otherwise entitled to access. So not every policy violation or out of scope business action is necessarily a violation of the Computer Fraud and Abuse Act.

David Simon (00:25:27):
What if the operator says this was a security evaluation and the agent went off course?

William Ridgway (00:25:33):
Yeah, and we've seen this happen and the label here doesn't decide the issue. DOJ has a charging policy addressing good faith security research, but it's not blanket immunity or permission to access other companies' systems. The facts and applicable law will still matter a lot.

David Simon (00:25:48):
And our response shouldn't create a second unauthorized access problem, right?

William Ridgway (00:25:52):
That's right. Being attacked doesn't generally authorize private hack-back, as we were reminded recently from our friends at DOJ. If our defensive agent starts reaching into another organization's infrastructure, you have to stop the access and the authority for that action.

David Simon (00:26:07):
What else should legal already be doing?

William Ridgway (00:26:09):
Certainly preserving evidence, assessing the reporting and contractual obligations, coordinating outside support, reviewing insurance requirements and protecting potential claims, cooperating with the outside operator may be important as well, but preserve independent judgment about the investigation, particularly if that operator may share responsibility. You want to structure the investigation deliberately, copying counsel, as we know, doesn't automatically make facts or investigative reports privileged.

David Simon (00:26:37):
That's exactly right. Okay, so let's look now at hours six to 24. By Monday afternoon, the obvious activity appears to have stopped. Investigators find altered customer records and an unauthorized communication and the CEO asks, "Was data stolen?"

William Ridgway (00:26:54):
Right. We need to investigate that, but also sounds like integrity and availability is also an issue. What changed, what actions followed? An incident can cause serious harm by modifying payment instructions, changing code or causing legitimate workflow to act on false information.

David Simon (00:27:10):
A valid credential doesn't establish that an action was unauthorized.

William Ridgway (00:27:14):
That's right. May have access to an application while the action falls outside the agent's legitimate task.

David Simon (00:27:20):
So looking at the AIUC-1 standard, how does that help us here?

William Ridgway (00:27:24):
Yeah, it's deployment environment control directs attention to the infrastructure supporting the agent, including access control and authorization. A prompt change won't repair a compromised execution environment. Its vendor diligence requirement provides a reason to revisit assumptions about an affected provider. What did we understand about its security arrangements and what has the incident revealed?

David Simon (00:27:46):
Now the GC asks, who do we have to notify?

William Ridgway (00:27:49):
Well, you have separate personal data breach notices, operational cyber incident reports, product security reports, AI specific reporting, securities disclosures, contractual notices. So in some ways it's like who do we not need to report to? One incident may trigger several of these. The recipients, thresholds and clocks can differ. AIUC-1 regulatory crosswalk does not answer those legal applicability questions.

David Simon (00:28:14):
Great. So there's still a role for lawyers even though everything's been baked out.

William Ridgway (00:28:17):
At least for now, David.

David Simon (00:28:18):
Give it a little time, right? So our ordinary breach notification laws do still matter even if an agent carried out the attack.

William Ridgway (00:28:25):
That's right. We need to analyze the affected information, individual states of residence and relevant state law triggers. Some laws focus on acquisition, others also reach access. So the definitions, exceptions, risk of assessments, all of that still matters. The forensic questions must support that analysis, what was accessible, accessed, or copied, and what protections were applied.

David Simon (00:28:47):
And we also will have sector specific obligations depending upon what industry you're in.

William Ridgway (00:28:51):
Exactly. Whether it's health, financial services, government contracting, there's a host of other sector specific obligations. Some operational cyber reports can be required without a reportable personal information breach. So don't overlook notices to customers, business partners, and insurers under contracts and policies.

David Simon (00:29:10):
And then for public companies.

William Ridgway (00:29:12):
Yeah, right. We have the SEC Form 8-K, 1.05 can apply. So you need to assess materiality without unreasonable delay. The filing is generally due within four business days after materiality determination is made. Importantly, that's different from rather than four days after discovery of the incident itself. Now you can't simply postpone that process though until every forensic question is answered.

David Simon (00:29:35):
And it was before I had a chance to practice on the ground in Brussels, I knew GDPR does require us to consider all the different factors, confidentiality, integrity, availability. So this unauthorized alteration of personal data can matter even if nothing was actually stolen. For a controller, notification of the competent supervisory authority is required without undue delay and where feasible within 72 hours of awareness unless the breach is obviously unlikely to result in a risk to the... Individuals' rights and freedoms. And communication to affected individuals was a separate high risk threshold, which I think our listeners will know about, but subject to limited exceptions. The processor's obligation, of course, is to notify its controller without undue delay, and that's also a separate obligation.

William Ridgway (00:30:14):
Got it. What changes if the company falls within NIS2?

David Simon (00:30:18):
That's a great question, Bill. So first we would assess whether there is a significant incident under NIS2. An incident under NIS2 can be significant if it causes or could cause severe disruption of essential services or financial loss or considerable harm to others. This is really about critical infrastructure in Europe, of essential services in Europe, but it's really broadly defined. For example, it does include certain digital service providers such as data centers and social media, and those will have even more specific EU thresholds for notification. So that's the EU-wide framework for what an incident would be under NIS2. But importantly, this law is transposed at the national level. So there are specific definitions and very specific notification thresholds to check under the relevant national implementing law and applicable sector specific rules. So if you're a company in the financial sector or you're a company in the transportation sector or in the chemical sector, among many others, there will likely be very specific national rules to follow.

(00:31:16):
And even if you have an EU-wide incident, there'll be specific rules you have to apply depending upon the jurisdiction. The sequence would go like this. If you become aware of a significant incident, then you would notify within 24 hours of that awareness, and then there would be an incident notification within 72 hours. This is then generally followed up with a final report about one month after notification, but in many incidents you end up providing updates until you have enough information to provide that full report. And then you provide updates as appropriate about ongoing activities and steps that are taken to remediate.

William Ridgway (00:31:50):
So in the scenario where we have a disruptive AI agent, it could trigger NIS2 even if the privacy analysis reached a different conclusion or result?

David Simon (00:31:59):
Exactly. And it could be a company with almost no sensitive personal data in Europe, but operations there, manufacturing, or for example, data center operations. So it's really looking at the effects in the European Union. And again, not every organization will be subject to NIS2, so you have to have done that analysis and hopefully you've gotten a board resolution and taken your appropriate steps to comply, which is something that we can obviously help with.

William Ridgway (00:32:22):
Got it. And I think previously, David, you mentioned the Cyber Resilience Act. What's that? How would that apply here?

David Simon (00:32:27):
Another great question. The Cyber Resilience Act reporting obligations, they have applied since September 11th, 2026, and they concern manufacturers of covered products with digital elements, including relevant software and remote data processing solutions needed for product functions. So if our victim company is also a manufacturer of products with digital elements, we'd have to assess whether the incident reveals an actively exploited vulnerability in that product or a severe incident affecting its security. A severe incident can include one that compromises or could compromise protection of important product data or functions, or even could lead to malicious code executing in the product or a user's systems. It's a totally different framework. There are much different standards. This is not about personal information at all.

(00:33:18):
Let's walk through the sequence. The sequence would include a 24-hour early warning notification and then a 72-hour notification from awareness followed by the applicable final report. Manufacturers would report via ENISA's single reporting platform to the coordinator of National CSIRTs and ENISA. ENISA being the European Cyber Agency. So basically you end up going to this form and you click which National CERTs are relevant based on where the product is used, and there's a lot of detail to provide and you have to register in advance. There's a whole process we lay it out in our client alert around this topic.

(00:33:51):
And so for actively exploited vulnerabilities, the final report is due within 14 days after the corrective or mitigating measures become available. For a severe incident, it's generally due within one month of the incident notification. Affected user information requirements are also needed for attention. So that would mean that you would need to tell users, tell customers that this has happened and really encourage them to patch as appropriate.

William Ridgway (00:34:14):
Got it. So would buying and using vulnerable software, does that automatically make the company a manufacturer under this regime?

David Simon (00:34:22):
No. So a company that in the context of the Cyber Resilience Act, it's if you offer a product service that has digital elements, that's where you would have the obligation. So many organizations would say, no, we don't do that, but they may have an app in the app store available in the European Union. Obviously, if they're selling manufactured products that go into transportation systems, that go into data centers that go into any number of industries, they would have those obligations, but it's not if you're really the company that's pulling all those things together.

William Ridgway (00:34:51):
Got it. How does the AI Act fit in our scenario here?

David Simon (00:34:55):
That's a great question. Many companies think that AI Act is really about compliance with certain risk assessment requirements, but there are notification obligations too. So here we would start with the role and the scope. Being attacked by an external agent does not by itself make the victim a provider or deployer of that attacking system. Providers of AI systems and particularly providers of general purpose AI models with systemic risk have serious incident reporting obligations under Article 55 of the AI Act. That's to report without undue delay to the AI office, which would in turn notify competent national authorities as appropriate. This is what we understand Anthropic to have done, for example, in the recent wave of incidents. The report should include relevant information about serious incidents and possible corrective measures to address them. The Commission also says that that can include serious cybersecurity breaches involving the model or its infrastructure.

William Ridgway (00:35:52):
So not every agent related incident is going to require an AI office report from the victim at least. Okay. Well, California has an AI specific reporting law. How does it affect the victim in the circumstance?

David Simon (00:36:04):
The California Transparency in Frontier Artificial Intelligence Act or SB 53 requires covered frontier developers to report defined critical safety incidents involving their frontier models. The ordinary deadline is within 15 days of discovery to the Office of Emergency Services. And if the developer discovers that the incident poses an imminent risk of death or serious physical injury, there's a 24-hour disclosure requirement to an appropriate authority such as law enforcement or public safety agency within the jurisdiction. These are defined critical safety incidents, not every AI error or ordinary cyber event would be relevant.

William Ridgway (00:36:37):
So the victim doesn't automatically inherit that developer reporting duty.

David Simon (00:36:41):
That's right. California also provides a mechanism for members of the public to report critical safety incidents. Our victim should assess its ordinary breach in cyber obligations, notify the operator with useful facts, and consider an appropriate voluntary safety report. We shouldn't assume that the developer's report substitutes for the victim's notices.

William Ridgway (00:37:01):
There's no single AI incident notification that satisfies everything here.

David Simon (00:37:05):
Again, another example of how AI and agentic AI is creating a lot more work for security operation centers for CISOs and for lawyers. So you'd have to build a reporting matrix at the start, the obligation, the trigger, the awareness date, deadline, recipient owner, and other information that you might need and then update the investigation. When just thinking about the Cyber Resilience Act, you should already have a map of your products with digital elements, markets that they're offered in and everything else so that you can track when something happens, that way you'll be ready to fill out the form. Let's talk about the third party harm piece and board oversight. Now in our scenario, our supplier reports similar suspicious activity. Our procurement assistant also accesses some of the systems. We don't yet know whether the supplier was independently targeted or reached through us.

William Ridgway (00:37:50):
So if that's the case, it may well change the scope. You want to coordinate those technical indicators and timelines with the supplier and preserve that evidence, share the new facts with the investigators if appropriate, and response authorities that have already been engaged. They may be able to help connect activity across victims or coordinate with providers beyond our specific reach.

David Simon (00:38:11):
And then later, the external provider correlates some of our timestamps and identifiers with agent runs and delegated sub-tasks in its own records. That gives us substantially stronger evidence of coordinated agents.

William Ridgway (00:38:22):
Right, but continue to reconcile that account with what actually happened in our systems. We need evidence of the executed actions and consequences, not just the operator's description of its workflow.

David Simon (00:38:33):
So what goes to the board during that first day?

William Ridgway (00:38:36):
In the first day, you want to convey the confirmed facts and the significant uncertainties, business consequences, containment status, and decisions requiring oversight, include the affected third parties, reporting assessments, government engagement, and the next investigative milestones. The board needs really a useful account without becoming the incident command team itself.

David Simon (00:38:57):
So that's a lot to cover in the first 24 hours. I'm already exhausted. We could cover the next 48 hours at some point in a subsequent episode of Decrypted. But what we want to do is jump now to the key takeaways.

William Ridgway (00:39:08):
So maybe one takeaway, we want to ask whether you can interrupt unauthorized activity, revoke machine access and suspend affected workflows. You want to identify who approves the consequential actions and then ask whether you can reconstruct what happened across identities, tools, and applications. You can't create missing historical logs after the incident. Test whether containment stops delegated work, active sessions and scheduled tasks. Know which outside parties you depend on and establish government context before the emergency.

David Simon (00:39:41):
I would add you'd have to assess agents by what they can do as well as what they can see, right? An agent that changes records, deploys code or initiates transactions presents different risks from one that just summarizes documents. And the standard we've been talking about, AIUC-1, it helps make preparation concrete, focusing on accountable responders, enforceable boundaries, usable evidence and visibility into providers and tested safeguards.

William Ridgway (00:40:08):
And those capabilities also support the legal response. You need evidence to determine what was unauthorized, what harm occurred, and which reporting requirements apply and whether restoration is justified.

David Simon (00:40:19):
For an external attack, the immediate task remains stopping unauthorized activity in the systems that you control. If it reaches your own agents, additional controls help determine what to suspend, investigate, and validate. And our sequence here is really detect, interrupt, contain, investigate, and restore. The work before the incident is making sure your people, authority, and technical controls can carry that out. Well, look, we hope that that discussion of what to do in the first 24 hours when AI agents attack will help you think, okay, if I were Hugging Face and Hugging Face's position, what would I need to do? And again, every scenario is different, but it's good to start thinking through this and how you would apply a standard like AIUC-1 or another OWASP framework.

(00:41:01):
So that brings us to our conversation with Danielle Sheer, who's the Chief Legal and Trust Officer of Commvault, and looking forward to that conversation.

(00:41:09):
Today, I'm so pleased that we're joined by Danielle Sheer, who is the Chief Legal Officer and the Chief Trust Officer at Commvault. Danielle sits at the intersection of a number of issues we spend a lot of time talking about on this podcast, not just cybersecurity, AI, governance, resilience, and the changing role of a general counsel, but the broader question of trust and what does it mean not just as a leader in a tech company, but in the boardroom, in communicating with users and other businesses. It's really at the core of the key questions that I think our clients and our listeners are paying attention to. And so one of the things I'm particularly interested in discussing today is how those issues are beginning to be covered at the executive level and in the boardroom.

(00:41:50):
We're moving very quickly from AI that generates content to AI agents that can actually take actions inside companies, inside governments, and playing an important role in geopolitics. That raises some pretty interesting questions about trust, governance, and resilience and about what management teams and boards should be thinking about now. Danielle, thank you so much for joining us.

Danielle Sheer (00:42:11):
I'm really happy to be here. Thanks for having me.

David Simon (00:42:13):
So to start, we'd love it if you would just tell us a little bit about your professional journey to becoming the Chief Legal Officer and the Chief Trust Officer at Commvault, and if you wouldn't mind sharing some of the experiences along the way that have shaped how you approach the role today.

Danielle Sheer (00:42:26):
Well, I have been practicing as a chief legal officer at public tech companies now for almost 20 years, and I found over and over that the legal answer only took me part of the way to the business outcome. And I could see the ripple effects in strategy and show up with customers and with employees and in transactions and increasingly in cybersecurity. So my career has really been an evolution from legal advice to enterprise judgment and now almost to organizational design. We had the opportunity to design around the outcome we were trying to create, which is trust, rather than the function where I originated from. So that's sort of how the evolution from chief legal officer to chief trust officer was born several years ago.

David Simon (00:43:14):
Was there a point in your career along the way where you started to think about the GC role differently, less as a company's lawyer and more of a business leader?

Danielle Sheer (00:43:24):
There were many times where I was involved in conversations that I needed to provide legal advice, but there was a collision of cyber and privacy and the AI, regulation, geopolitics, and it all collided in issues of reputation. And when you've been practicing in a tech company for years and years, you get a certain fluency with technology, with business, with the way different functions run. And I started to find that I was connecting those disciplines more and more, that I was showing up with just the legal answer and closing the book.

David Simon (00:44:00):
So you're getting to my next question already about how the roles converge, the chief legal officer, GC, chief trust officer, but I'd be interested in your take as how that's changed in the last even just five years and where you think it's headed. Because as we are speaking here now, many of the listeners who are senior lawyers at tech companies or senior security executives or in a trust officer role or a CEO wondering, is my team set up right for the moment that we're in, the moment that we're heading into? Would be interested in your reaction on how these roles have converged and then what do you think it will look like in the next coming five or 10 years given the direction of travel?

Danielle Sheer (00:44:37):
I think that's one of the best questions people are starting to ask and CEOs and boards are starting to ask. Today we are spending so much of our time talking about AI as a technology transformation, and I don't think we're talking enough about it as a management transformation. As machines process more information, as they perform more analysis, and even as they and we get more comfortable with them taking more actions and executive actions, I don't think that diminishes leadership. I think it changes what leadership is for. So scarce capabilities become judgment, communication, the ability to be transparent and convey information in an absorbable way, the ability to create relationships that matter and can sustain, and the ability to create trust. Which is kind of what brings me back to this infusion of disciplines into a chief trust officer role. As machines become more capable, I think trust becomes more valuable.

(00:45:35):
And thinking about leadership roles that are not siloed by functions, but are driven by the outcome that you're trying to obtain gives you the ability to think about a structure totally differently.

David Simon (00:45:48):
You've already started to discuss this, the transformation aspect, not just from a technology perspective, but from a management perspective, from an organizational perspective. So when AI agents are beginning to move beyond generating information or recommendations and taking actions on their own, accessing systems, using tools, making decisions, and carrying out tasks with limited human involvement, from a legal perspective, from a trust and risk perspective, what changes when AI is no longer just assisting employees, but it's really acting inside the enterprise and on the company's behalf?

Danielle Sheer (00:46:24):
So I think that's the question everybody is wrestling with, and my answer is that agency changes everything. When AI tells you something — and you know, a lot of us are starting to swap out Google for ChatGPT or Claude to receive information — when AI tells you something, it's governing information. But when AI can do something, when it can access a system, when it can write code, when it can communicate externally, when it can make a decision, you move from governing information to governing authority. So the question becomes, or changes from "What does this model know?" to "What is this agent allowed to do?" And I think that's a much more consequential governance question. I guess I would start with a very human analogy. I would not give an AI agent more authority than you would give a new employee without supervision. Identity matters, permissions matter, least privileged access matters, auditability matters, and there need to be very clear thresholds where a machine's authority stops and a human has to make the call.

(00:47:30):
You would not onboard a new associate to Skadden and give them the financial forecast numbers for the quarter for the firm. Similarly, you should not give access to an agent. But who's thinking about that? Who's designing that? How many agents are you spinning up at once and do you have a handle on it?

David Simon (00:47:49):
You've already really answered one of the key questions I had next, so I want to underscore it because I think this governance issue around, you're talking about agentic governance, the hard question management teams are coming to us about, and it sounds like you've already taken this on and I'm not surprised at all given your leadership role in the tech legal community beyond just being a trust officer, it's that where do you draw the line around autonomy access, and human oversight?

(00:48:14):
I saw this to a different extent about 10 years ago when I was in the Pentagon and we were asked to provide advice on autonomous weapons and where do you think the role of human oversight is? But it seemed too simple then and certainly the case now to say, oh, just have a human in the loop on every decision that matters when maybe the whole structure of a business is depending on agents to make certain types of decisions. It's not possible to have or productive to have human oversight over every single thing. So drawing those lines and making sure to have metrics on how you see those unfolding seems like one of the hardest problems today. Sort of on this, maybe I'd be interested in your take about not just where would you think about making sure that an AI agent doesn't have access to information given the sensitivity, are there areas where you see on the horizon that you might think with appropriate controls, having an agent taking on the role or the access level and authority of an employee is in the near term?

Danielle Sheer (00:49:11):
I don't have a good answer to this yet, and I struggle with it because on the one hand, I feel like I need to be the voice inside of a company that advocates for human oversight because we've got a lot of people who want to move fast with what technology is capable of today. On the other hand, machine speed action requires machine speed controls. I know that human oversight alone cannot keep up with the speed of an agent. And so I struggle a lot with making certain that the teams that are designing the outcomes they want in an agent to perform has the proper checks in place that they might want to know about along the way. One of the ways that we think about this is when we are reviewing our incident response process and bringing it up to machine speed because the rate and pace of incidents are happening at a faster clip than a human can keep up with.

(00:50:12):
But at some point, a human needs to be involved to know if something really is a problem or what we want the agent to do next in terms of investigation or shutting down systems. I don't have an answer today, but what we think about it every single day and we sort of test it in a sandbox, we're trying to find ways to make our human experts reserved for the highest level of judgment instead of all the little pieces in a process of an incident response, but we're building it.

David Simon (00:50:44):
So your reaction to this is I think exactly the kind of conversation we're hearing with executive teams in boardrooms in reaction to the Hugging Face incident that for our listeners, we just discussed this on our last episode in some depth, but this example involving obviously autonomous AI agents raise questions about systems behaving in ways that are not expected and in some cases ways that are deceptive. What should legal and security leaders take away from these examples in particular? Because you've now just laid out, I think, a very clear sense for what responsibly looks like, how to have a process that can be flexible and evolve, but there are some fundamental assumptions about not just the role of a human in the loop, but also how we think about cybersecurity where our tools may act in ways we expect and sometimes they actually may take steps to make it harder for us to know what they're doing to be somewhat deceptive.

Danielle Sheer (00:51:37):
Okay, it's a great question and there's a piece of this that I have been spending a lot of time thinking about. You can answer that question with a technical response, as if you were a cybersecurity expert. You can answer it with a board level response, considering enterprise risk. But what's most interesting to me right now is that it's so apparent to me that ownership of addressing this can't sit in one silo. It's simultaneously a cybersecurity, technology, legal, governance, enterprise risk problem, which is exactly the problem that a trust model is designed to address. When you bring in a collection of leaders like a tabletop exercise, every single one of them will answer that question from their purview. Who's thinking about it from the holistic purview and how do you then design a system, test a system comprehensively?

David Simon (00:52:31):
Do you think that boardroom conversation should be focused on how do I react if I'm the next Hugging Face?

Danielle Sheer (00:52:37):
Absolutely. We're talking about it in our boardroom. I do try not to bring the board technology problems. I try to bring them enterprise consequences and decisions. So we talk a lot about what could happen, are we prepared, what decision or investment or oversight might I need from them? Boards, they don't need every signal. They need to know which signals could change the trajectory of the company. We have our CISO report to our board. That's incredibly important. When technical teams report to directors, they tend to want to explain what happened and how it works. Directors tend to want to understand what does it mean? What does it mean for customers? What does it mean for reputation? What does it mean for revenue? What does it mean for resilience? And so there does need to be somebody whose job is translation and making these consequences more legible.

David Simon (00:53:31):
I want to just underscore a couple things you just said there because often board members will ask, what are the questions I should be asking when I'm receiving these briefings? So much work has been put into thinking about how to articulate what happened and then the business impact or the relevance for a given stakeholder. But I just heard you say, look, it's making sure they understand what does it mean from a CFO's perspective on the bottom line or what it might look like in the future. What does it mean for our ability to operate as a business in certain markets? And it's often not something that a CISO or a CIO is positioned to explain, but I think less commonly are board members hearing that this is what it'll mean for our customers, for our end users, increasingly that's the level of translation, business impact of impact on the overall message of the company that I think board members should be asking about.

(00:54:18):
And it sounds like this is exactly the kind of activity that you are all seeing happen when you get together.

Danielle Sheer (00:54:24):
Exactly right.

David Simon (00:54:25):
So when we talk more about the role of the board, I was wondering from your perspective as a general counsel and as a chief trust officer, what do you think are the most important things that other GCs, chief trust officers or folks in similar roles should be doing to build their credibility with the board on these issues before a crisis so that if the unfortunate event occurs, not just a ransomware attack or the types of cyber incidents that are increasingly common, but one of these, I'm not really sure how to deal with this, we are being confronted at machine speed at scale by a so-called collective of agents, what are some things you think that your peers at other organizations should be doing to build their credibility?

Danielle Sheer (00:55:05):
You can't let the crisis be the first time the board hears your voice. Credibility is accumulated in small deposits. Transparency when the news isn't great, resisting the temptation to overstate uncertainty or certainty or positivity, being transparent about what you don't know and following through. Trust built in ordinary times becomes your operating capital in extraordinary times. Or the way I say it to my team is "Make a relationship before you need a relationship."

David Simon (00:55:33):
And how does that work when it comes to the role of the CISO? Because there's only so many voices that the executive team and the board may be accustomed to hearing. How have you found that role evolve at Commvault and how would you advise your peers to think about it? And then just to frame it, in some cases, clients will ask, well, where should the CISO sit in the organization? Who should they report to? In different organizations, there'll be a different answer, but a lot of this comes down to empowerment. Is the CISO empowered to speak to the CEO, to the board? And how is the voice of the CISO viewed relative to other key stakeholders? But would welcome your take on this because as many of our listeners know, how it works in a mature global tech company is different where everyone or many of the members of the team may have a fair amount of technical acumen and appreciate the underlying product.

Danielle Sheer (00:56:18):
So I'm going to answer this in two ways. The first is it's really important if you're going to move into this sort of multidisciplinary trust executive role that that person knows that their job is not to become a second CISO because if you're doing that, you've probably weakened both roles. The job is to make the CISO more powerful, exactly as you just said it, to empower them by connecting cybersecurity to the board, directly to customers, regulators, business strategy, and by giving the CISO peers and an ecosystem who understand that that person's success with theirs is interconnected.

(00:56:54):
The second way I'll answer your question is where could the CISO report? And I love this question. I've thought about it for years and years. The easiest answer is the CISO should report to the CEO. But if you have ever, ever talked to a CISO before in your life, there is no way that the CEO can be the clearing house for everything that that CISO is working on, thinking, escalating. It is a 24/7, all-on, highly paranoid job and there needs to be a direct line to the CEO. That doesn't mean that the CEO needs to be the manager of that function.

(00:57:30):
The second place that that function historically has reported is the CFO. And depending on the type of leader that the CFO is, that can be a great place, especially if the CFO is generally responsible for enterprise risk. But if the CISO is placed under the CFO to make sure that the security function is properly financed, that's not enough. Because then I don't think you're really helping the CISO learn how to translate enterprise consequences. One of the things our CISO and I talk about all the time, he has a monthly report to the CEO and CFO, and we have a quarterly report to directors of our board. He is living in incidents. He is living in agentic design. He is living in product security. And these are opportunities for him to step back and take a look at the whole and say, "This is why it matters."

(00:58:22):
One of the conversations we just had recently, I asked him, "What's our critical systems and services? If they were to go down, we'd be in trouble. What's the list?" I ask him all the time, "Okay, we've got a list. Are they backed up? Have those backups been tested? Have those recoveries been tested?" Now, that's traditionally a question that IT would answer. But they're interconnected. If the system goes down because of some kind of cyber incident, you close the door on the CISO and the team and open the door on the IT team and say, "Can you get us back up and running?" Those things work together. They work hand in hand.

(00:58:54):
Now, I come from a cyber resilience company, and so the CISO wants to know, do we use our own products to actively recover our critical services? It's a great question. And he starts going one by one. And if we're not using our own products in one or two cases, he wants to provide that feedback to my head of product and explain why. That is what a great CISO does. Now, depending on how you think about multidisciplinary collision, you may or may not coach the CISO to think about things like that.

(00:59:28):
The third place that CISOs have reported into is the CIO. The CEO of my company was a former CIO of RSA, and he just does not believe that you should commingle security and information. He thinks there should be a separation of duties there. And I wasn't the person who came up with the chief trust officer idea. I think that was Adobe. They came up with it, and there are a number of other companies that have moved in this direction, Celonis, they have a chief legal and trust officer. I think you're finding a lot of efficiency and a lot of clarity. And a lot of speed by marrying these functions, many of these functions, it could be cybersecurity, it can be business development, it could be corporate development, it could be legal, policy, public affairs. When you merge all of those together, when you marry them, when you make those teams figure things out together before they go out into the broader employee base, into the broader company, you really remove a lot of friction.

David Simon (01:00:24):
So what you're saying I find extremely interesting because in many organizations there's this natural tension, particularly in a mature or even emerging tech companies between legal and risk and one hand, and then the innovation focused folks who are trying to rapidly deploy AI or other technologies. And knowing you for a number of years now and also hearing what you're saying, I think it'd be really great to tease out for the audience, for our listeners, is it right that one of the wonderful things about the sort of roles that are merged in yours is that there isn't a natural tension. Your job in part is to make sure that there is alignment around both so that it's not just about the legal risk or the trust deficit that you're trying to overcome, but how to build in a way that is meeting both?

Danielle Sheer (01:01:07):
Almost. There is a tension, but the idea is to work out that tension without requiring the CEO or CFO to become a mediator to work out the tension. So work out the tension in the right place in the process so that you don't have legal pointing at cybersecurity or cybersecurity pointing at public affairs. Work that out under that layer and then the organization just operates more efficiently.

David Simon (01:01:34):
I want our listeners to hear this because I think at this time and in many, not just conversations of every afternoon with clients or in conferences or boardrooms, these questions about how do we govern agentic AI? And often you get very technical answers, which are extremely important, human oversight and the like, but it goes to the very top. How are you organized as an executive team? How are your responsibilities positioned? And we hear all the time now about alignment or misalignment of AI, but what about the key executive functions in a company that is trying to maintain the trust of its customers, its employees, and everyone else? I think it's really important at this moment to underscore that because most management teams I think are not thinking about that right now.

(01:02:12):
So I want to turn to talk for a bit about just in your mind, companies that are looking ahead, not just in terms of the roles and how they're aligned at the executive level, but in terms of companies you think that are doing a great job at embracing the sort of AI summer that we're in, whether it's because they're extremely quick on smart applications of generative AI or because they're just going through this transformational period in a way that's setting a great precedent. And I'm not asking for you to call out specific companies if you don't want to, but be interested. Many management teams are wondering, are we doing compared or do other organizations are trying to do this as well? Everyone's building the plane while it's taking off, but it's still difficult to know when you're doing that, is it supposed to be this bumpy or is this smooth sailing?

Danielle Sheer (01:02:55):
There's still a spectrum of companies that are totally uncomfortable with AI and the narrative publicly is from one end to the other and it's very hard to know how all of our lives are going to change. I think it's created a lot of anxiety for employees and for the future of jobs and the future of life. And then I think it runs all the way to having FOMO that you're not doing enough fast enough. I don't know what the right answer is. I do think that the better companies are not rushing to connect data sources without knowing why. I think the best companies are not rushing to create thousands of agents and abandoning them because they don't really know what they're doing.

(01:03:36):
Things started to click for me when GDPR came around because to me it was the simplest analysis that was the hardest to do. What data do you collect? Who has access to it? Where is it stored? Who do you share it with? That's it. Just answer those questions. How hard can that be? Actually turns out it can be really hard if you never asked those questions and collected those answers before. But with the development of AI and the ability to connect data sources, you can answer those questions from the beginning. And the best companies are doing that. We're going to create an agent. Why? What's it intended to do? Who's going to have access to it? Who's responsible for it? Who's checking in on it and at what rate and pace?

(01:04:15):
I'll tell you in the beginning at Commvault, people were really annoyed to have to answer those questions because they just wanted to move fast. Well, we don't want to hire another 10 recruiters. We want to create an agent to do recruiting. I got it. I'm totally there with you. Just tell me exactly what that agent is going to do. Tell me exactly what data sources that agent is going to have information to. Who is going to check that that agent is doing the work the way we want to do that work? We have decided internally that agents are going to be synonymous with employees. So they have to have all the rights, responsibilities and obligations that an employee has. And they have to be treated and supervised as an employee. So you got to think about inventory, you got to think about permissioning, you got to think about data access, accountability, testing and monitoring. And not after this has exploded inside your enterprise, but right now, if we have learned anything from ship-then-fix or putting the genie back in the bottle when it comes to GDPR, do it right now.

(01:05:16):
And you just have to start with a few use cases because as soon as you get the organization accustomed to answering this formula, they'll just do it. You can just do it in your sleep. Look, NIST, for example, is already focused on agent identity because they're aware of the fact that agents need authorization and access in order to be useful. So it's a good thing and we should be focusing on it and architecting it correctly from the beginning.

David Simon (01:05:42):
So that's I think the clearest articulation I've heard about how to develop the muscle memory to do what everyone's trying to do right now, because it's easy to say, and we often say on this podcast, cybersecurity is a luxury for companies that know where their technology is. And you can say the same thing about data privacy for your data. But machine identities and thinking about the roles of agents and how much privilege and access you give them, it's really next level stuff even for companies that are making these tools. If you're not building the process to enable people to move, they're not going to be able to move fast. And it sounds like that's how you make sure that they can take flight.

Danielle Sheer (01:06:15):
And the best part of that, David, is that if you do not build the process, you will very quickly become a victim of your own success. We already have enough cybersecurity problems to deal with. We do not need friendly fire.

David Simon (01:06:30):
That is a great place for us to land here because many organizations want to have all the benefits and to think about how they can manage the downsides. And that's a great example.

(01:06:38):
Danielle, this has been an amazing conversation. We're so grateful for your time. And one of the things that really comes through is that this age of innovation that we're in right now, it's creating an entirely separate category of risk that companies can't just simply hand off to an AI team and that governance isn't just something that we're implementing the operational level. It's also something that really can be reflected in the role of executives and how you arrange your senior management team. And this isn't just for companies that are in the cybersecurity or cyber resilience business. It really is relevant for any organization that's trying to figure out how they can operate in this age as a developer or deployer. So for GCs or chief trust officers or CISOs or other senior technology leaders right now in the middle of some of these consequential decisions, I hope that they get a chance to listen to this and hear from you.

(01:07:27):
And just want to say Danielle Sheer, thank you so much for making the time to join us on Decrypted.

Danielle Sheer (01:07:32):
I really appreciate it. Great podcast.

David Simon (01:07:33):
Our thanks to Danielle for joining us and sharing her perspective.

William Ridgway (01:07:37):
And thanks to everyone for listening. Today's scenario comes back to decisions every company should prepare for: how to interrupt unauthorized activity, establish what happened, meet one's legal obligations, and restore operations on a defensible basis.

David Simon (01:07:50):
We'll include resources in the show notes, including the AIUC material, the incident-response guidance discussed today for teams that want to use these questions in their planning and exercises and our client alerts that go into some of the key subjects that we talked about.

William Ridgway (01:08:04):
Great. And if you found the episode useful, subscribe to Decrypted wherever you get your podcasts and share it with your legal, security, and business colleagues.

David Simon (01:08:12):
Thanks again to Danielle and thank you for listening. We'll see you next time on Decrypted.

Voiceover (01:08:18):
If you're enjoying Decrypted, be sure to subscribe in your favorite podcast app so you don't miss any future episodes. Additional information about Skadden can be found at skadden.com. Decrypted is a podcast by Skadden, Arps, Slate, Meagher & Flom LLP and Affiliates. This podcast is provided for educational and informational purposes only and is not intended and should not be construed as legal advice. This podcast is considered advertising under applicable state laws.