# The Security Digest

Expert insights on AI security, agentic orchestration, SOC operations, and enterprise cybersecurity. Weekly updates on deepfakes, compliance, and observability.

## AI Impersonation Leaves Employees Paying A Trust Tax. Independent Verification Cuts The Bill.
URL: https://www.thesecuritydigest.com/news/ai-deepfakes-expose-security-vulnerabilities-jothi-dugar-ty-hughes
Published: 2026-10-26T01:23:02.327Z
Section: Industry News
Summary: Cybersecurity strategists Jothi Dugar and Ty Hughes explain how matching verification to what a request can set in motion keeps routine work fast and high-risk approvals safe.
Full text:
Workplace security training often teaches employees to slow down when something about a message or a call seems off. Generative AI lets attackers produce a convincing impersonation quickly and cheaply, whether it arrives as an email, a text message, a cloned voice, or a faked video call. The signals employees typically use to confirm who they're dealing with, such as a familiar voice, a face on a call, a writing style, or a caller ID, are easier to fake, and a request can now arrive looking and sounding exactly right. Security teams now have to fix the processes that let a single convincing interaction authorize a payment, a password reset, or the release of sensitive data. Jothi Dugar and Ty Hughes , both cybersecurity strategists, have built much of their work around what they call Cyber Wellness, an approach that counts human and organizational health as part of an organization's security resilience. Dugar, known across the industry as JoJo D., "The Chaos Guru," has more than 25 years of experience as an executive and strategist in organizational transformation, technology, and cybersecurity, and she's also an international bestselling author . Hughes, a transformational technologist widely recognized as "The AI Alchemist," has spent nearly 25 years helping organizations manage the technical and human sides of complex change, and he's a President's Management Council Interagency Rotation Fellow. Their latest work treats AI-enabled impersonation as a problem for an organization's security controls to solve. "Multiply each judgment call across every suspicious email, unexpected text, MFA prompt, voice call, video meeting, and 'quick favor.' That is the trust tax: the operational and cognitive cost created when employees are repeatedly asked to authenticate reality because the organization has not adequately authenticated the request," says Dugar. Attackers often target the places where a weak business process leaves a consequential decision to a single employee, because those attacks tend to work. What the voice can authorize A finance employee on an urgent video call might see a familiar executive ask for a confidential wire transfer. A help-desk analyst might hear from an executive who says they're locked out of an account ahead of an important meeting and can cite the right colleagues and projects. In one long-running campaign, impersonators of senior U.S. officials have used text messages and AI-generated voice messages since at least 2023 to request wire transfers, authentication codes, and personal documents. Hughes points to what the employee on the other end is able to approve. "A synthetic voice is dangerous because of what the voice is allowed to cause," he says. "A convincing message becomes an enterprise incident when it can reset credentials, change a vendor's banking information, release sensitive data, create privileged access, or trigger an operational change without sufficient independent verification." Business email compromise drew 24,768 complaints and just over $3 billion in reported losses in 2025. Complaints that referenced AI totaled 22,364, with about $893 million in losses, although a reference to AI doesn't mean AI caused the loss. Hughes points to a vendor's banking change that arrives in a genuine, ongoing email conversation. "Replying to that same thread does not independently verify the request if the mailbox itself is compromised," he notes. "A familiar voice calling the help desk does not establish identity if voice can be cloned." Federal digital identity guidance now requires systems at the middle assurance level to offer a phishing-resistant sign-in option, and requires phishing resistance outright at the highest level. Hughes applies the same principle beyond sign-in, holding that the more a request can set in motion, the less weight an organization should give to an employee's sense that a voice, face, or message seems familiar. "Identity and authorization are related, but they are not the same question," he explains. "Identity asks who is present. Authorization asks what that identity is allowed to cause." The "quick favor" Finance analysts, help-desk staff, and IT administrators all field urgent requests from senior leaders, by email, by phone, and on video calls. "When controls are weak, the organization quietly transfers the burden to the employee," says Dugar. "The finance analyst has to decide whether challenging an executive will damage a relationship. The help-desk analyst has to decide whether denying a senior leader's urgent request will affect their reputation." Dugar warns against answering the pressure on those employees with blanket caution. "If every interaction carries the same warning, every request requires extra approval, and every employee is expected to remain hypervigilant all day, people will adapt," she explains. "They will click through prompts, delay legitimate work, move conversations to unofficial channels, or find workarounds." Dugar starts from what an employee can reasonably watch for in a working day. "Human attention is finite security capacity," she adds. "Good security does not maximize friction. It concentrates friction where failure matters most." Outside the conversation Hughes favors what he calls " consequence-based verification ," and under it, routine coordination that touches no money, access, sensitive data, or system change stays fast and simple. Stronger checks apply when a request looks out of the ordinary, comes through an unfamiliar channel, asks for secrecy, carries surprise urgency, or could disrupt operations. "High-consequence actions, like payment changes, account recovery, privileged access, sensitive-data release, or material operational changes, should require controls strong enough to withstand a convincing impersonation," he says. The controls Hughes has in mind start with calling back on a number the organization already has on file and requiring a second approver. They extend to splitting duties between employees, checking contacts against a trusted directory, phishing-resistant sign-in, waiting periods before financial changes take effect, privileged access granted only for limited windows , and a logged record of every exception. He puts the most weight on the word "independently," and applies it to email, phone calls, and existing conversations alike. "If a request arrives by email, do not use the phone number supplied in that email to verify it," Hughes advises. "If a caller claims to be an executive, do not rely on facts supplied by the caller as proof." A change requested in the middle of a familiar thread should be checked against a trusted record that existed before the request arrived. "A compromised conversation can validate itself," he adds. "Independent verification has to begin outside the conversation." In Dugar's view, attackers create urgency on purpose because it shortens the time a target spends thinking, so she gives employees a brief routine for the moment a request feels pressing. She calls it "Pause, Breathe, Summarize, then Verify," and uses it alongside technical controls. "Pause interrupts automatic action," Dugar explains. "Breathe reduces the physiological pull of urgency. Summarize forces clarity: What exactly am I being asked to do? Does this involve money, credentials, secrecy, sensitive data, authority, or a change in normal process? Verify then turns uncertainty into a defined next step using a separate, trusted method." From Hughes' perspective, security leaders should track how well verification protects the organization alongside what it costs employees, including how long verification takes, where employees abandon the process or build workarounds, and how often executives ask for exceptions. "Fraud losses tell you what failed," he says. "Verification telemetry can tell you where failure is forming." Every executive exception Employees learn that the rules bend for senior people each time an executive skips a required step or sends a sensitive request outside approved channels. A leader sends the same message by pressuring someone to "just get it done," or by reacting with irritation when an employee stops to confirm an odd instruction. Dugar looks at the next such request from the employee's side. "Employees then have to calculate two risks at once: cyber risk and career risk," she notes. Dugar wants leaders to visibly follow the same checks as everyone else, route urgent needs through sanctioned emergency procedures, and thank the employees who stop to question an odd request , so that confirming an instruction counts as protected behavior. "If executive exceptions are normal, an attacker does not need to invent a strange scenario," she says. "They only need to reproduce the exception convincingly. Every executive bypass teaches the attacker which impersonation will feel normal." An employee who feels ashamed of a mistake may delay reporting it while an attacker keeps working, a risk Dugar and Hughes have also examined. The trust tax comes before any mistake, at the moment a fake or hijacked request first reaches an employee with the authority to act on it. Hughes puts responsibility for both moments with an organization's leaders. "Organizations need safer decisions before action and rapid, candid reporting if prevention still fails," he concludes. "They need leaders who respond without humiliation after an error and leaders who do not demand exceptions before one."

## Enterprise AI Policies Lose Their Reach When Employees Choose Tools Outside Their Control
URL: https://www.thesecuritydigest.com/news/nethusha-ravisuthan-ai-governance-insights
Published: 2026-10-25T22:47:26.426Z
Section: AI
Summary: Nethusha Ravisuthan, Sales Support & Operations Manager at Microsoft, explains why effective enterprise AI governance requires clear permissions, accountable oversight, and employee training to reduce security risks from unauthorized AI use.
Full text:
Companies can establish AI security policies and provide approved tools, but that doesn't mean employees will use them. More convenient alternatives can draw workers toward unauthorized tools, limiting visibility into how company data is handled. As AI becomes more embedded in enterprise operations, governance must account for employee behavior, system permissions, and oversight. Nethusha Ravisuthan is a Sales Support & Operations Manager at Microsoft, where she works on enterprise product adoption and operational governance. She also lectures on AI security and governance and is developing a course on responsible AI and security for students in Sri Lanka. "People tend to use the tools they're comfortable with, instead of the ones their organization provides," Ravisuthan says. Employee preferences pose a threat to enterprise AI security policies Ravisuthan identifies employee preferences as a source of shadow AI , where workers use AI services without organizational authorization, potentially exposing confidential information outside established security controls. "Let's say an organization gives employees access to Claude, but one employee is more familiar with ChatGPT and inputs confidential information into it. If ChatGPT were then compromised, the company's confidential information could be exposed," she explains. Preventing unauthorized use requires more than prescribing an approved platform. Employees also need access to the capabilities they rely on, along with sufficient training to use them effectively. Similar concerns about access and authorization arise when enterprises deploy AI agents. Even within approved environments, organizations must determine what these systems can do and how to restrict their permissions. AI agent permission limitations as a governance priority An AI agent assigned to sales operations may require access to specific business systems, but excessive permissions could allow it to perform tasks beyond its intended function. "What if it has the capability to do things beyond sales that you haven't authorized or granted access to?" Ravisuthan says. Drawing on her experience at Microsoft, she describes how organizations can restrict agents to defined responsibilities. "Without sharing confidential information, we have agents for sales, client analysis, market analysis, and so on. But we limit and tailor them to a specific range of activities," she says. Setting those restrictions also requires clear accountability , particularly when business teams and security specialists have different responsibilities for overseeing AI deployments. Clear ownership and provider transparency strengthen AI oversight Ravisuthan recommends assigning oversight according to an agent's purpose, with operational managers defining its responsibilities and security specialists advising on access restrictions. "If it's a sales agent, a sales manager needs to oversee it. If it's related to security, a cybersecurity expert should advise on when and how to limit access," she explains. AI providers should explain how their systems enforce these restrictions so enterprise customers can establish appropriate internal controls. "These rules should be documented, and the enterprises providing the services should be transparent about them, rather than leaving all responsibility for regulation to the enterprises using the services," Ravisuthan says. Employee training brings AI security policies into practice While documented permissions help organizations govern autonomous systems, managing employee AI usage also requires continued education, especially as approved platforms introduce new features. Ravisuthan points to Microsoft's internal Copilot training as an example of how organizations can encourage employees to use approved technology instead of turning to familiar alternatives. "We can't just offer Copilot to users and expect them to adopt it automatically," she says. "They might prefer OpenAI tools or Claude." Employees may not realize their approved tools already offer capabilities they're seeking elsewhere. "We held an event on Copilot last April, and even I learned how much more there is within Microsoft Copilot because we had an expert come in and train us," Ravisuthan says. She recommends regular training and dedicated teams to keep employees informed about new features and reduce reliance on unauthorized alternatives. "When employees use the tools provided by the company, the organization can monitor their use and manage security more effectively," Ravisuthan concludes.

## Vulnerability Severity Alone Doesn't Determine Security Priorities in Critical Infrastructure
URL: https://www.thesecuritydigest.com/news/vilas-shewale-on-cybersecurity-prioritization
Published: 2026-10-20T15:29:18.443Z
Section: Leadership
Summary: Vilas Shewale, Principal Specialist at Energy Transfer, explains why vulnerability severity scores alone can't determine cybersecurity priorities in critical infrastructure, where operational risks and remediation constraints demand careful judgment.
Full text:
A high-severity vulnerability doesn't always present the greatest operational risk, particularly in infrastructure environments where remediation decisions can affect essential services. A severe flaw in an isolated development server may warrant less immediate attention than a lower-severity vulnerability affecting a vital operational system, especially when taking that system offline for remediation could disrupt service delivery. Vilas Shewale , Principal Specialist at Energy Transfer , has nearly 30 years of experience across enterprise IT, including banking, technology, and energy environments. His work spans endpoint security, system hardening, and large-scale infrastructure deployments, giving him firsthand experience with the operational constraints that influence cybersecurity decisions. "Standard vulnerability scores and real-world risk rarely match. That's one of the biggest misunderstandings in cybersecurity," Shewale says. Cybersecurity risks extend beyond infrastructure operators Cybersecurity incidents in the energy sector can have consequences far beyond the organizations directly affected, as disruptions to power grids, pipelines, and other essential infrastructure can interrupt services that communities and businesses rely on. The Colonial Pipeline incident demonstrated how a compromise affecting corporate IT systems could disrupt fuel distribution across multiple states. "People waited in long lines for fuel, and multiple states along the East Coast were affected," Shewale recalls. Maintaining the infrastructure that supports these services presents additional security challenges. Energy operators often manage environments where legacy operational technology (OT) and supervisory control and data acquisition (SCADA) systems coexist with newer equipment. "They still work beautifully, so organizations keep them running," Shewale says. Replacing or upgrading these systems can be expensive, while their importance to daily operations may limit opportunities for maintenance. As a result, security teams must evaluate vulnerabilities in the context of the assets they affect, including how exposed those systems are and what would happen if they were compromised. Technical severity doesn't tell the full risk story While standardized vulnerability scores help identify technical weaknesses, they can't fully account for the environments in which those weaknesses exist. Shewale illustrates this distinction with a hypothetical vulnerability carrying a CVSS score of 9.8 and affecting two development servers isolated behind firewalls. "The vulnerability still exists. I'm not denying that, and we still need to address it. But the practical business risk may be very low, so the patch can wait," he explains. A lower-scoring vulnerability in a production database could require a more urgent response. Shewale describes a flaw rated 4 or 5 that could, under certain conditions, allow an attacker to exploit SQL injection and expose sensitive information, including Social Security numbers and other personal data. "Even with a lower score, that vulnerability becomes a top priority," he says. Energy infrastructure brings additional considerations, as the operational importance of a system can increase the consequences of exploitation while limiting remediation options. "A control system could have a medium-severity vulnerability, but you might be unable to shut it down for several months because you're in a critical operating season and have no maintenance window," Shewale says. "That operational constraint must be part of your decision-making." Operational demands complicate vulnerability remediation Maintenance windows in energy environments depend on operational demands, environmental conditions, and regulatory requirements. "You can't schedule maintenance without considering the weather and energy demand," Shewale says. "If a hurricane is coming, you don't want to take critical systems offline." Extreme heat and winter storms can impose similar restrictions, particularly when electricity and fuel infrastructure are already operating under significant pressure. Delaying maintenance, however, means security teams must continue managing vulnerabilities until remediation becomes possible . Shewale emphasizes the importance of monitoring affected systems, evaluating compensating controls, and documenting remediation decisions. "You need to document your reasoning and weigh not just the security score but also the importance and criticality of the system," he says. Those decisions also require coordination with operational stakeholders, who must understand how security changes could affect ongoing services. Recommendations that work in conventional enterprise IT environments may be unsuitable for infrastructure where an unexpected interruption carries wider consequences. "A consultant coming from a traditional IT environment might recommend an immediate change. You sometimes have to slow down and assess the operational implications before following that recommendation," Shewale says. Across large IT and OT environments, security teams face the added complexity of assessing vulnerabilities across thousands of assets. Each finding requires an understanding of the affected system and its operational importance, creating opportunities for AI to accelerate analysis and help teams identify the most pressing risks. AI brings new possibilities to vulnerability management AI can help security teams analyze vulnerabilities by correlating alerts, assessing asset importance, and identifying potential threats. "Work that might take a human team weeks can potentially be done by AI in minutes," Shewale says. However, “we shouldn't trust AI to make decisions that could shut down a pipeline, disrupt a power grid, block a critical system, or alter train routes without appropriate oversight," he cautions. For Shewale, AI's immediate value lies in helping security teams identify and prioritize threats while leaving operational decisions to experienced professionals . Before granting these systems greater autonomy, he wants evidence that they can explain their decisions, handle unexpected conditions, and allow human intervention. Until then, human judgment remains central to balancing cybersecurity risks with operational continuity. "It's about making systems safer for the public, making smart trade-offs, and keeping the lights on for years to come," he concludes.

## How CMMC Is Reshaping the Relationship Between Cybersecurity and Business Growth
URL: https://www.thesecuritydigest.com/news/cmmc-certification-importance-for-contractors
Published: 2026-10-19T07:16:59.323Z
Section: Leadership
Summary: Thanh Thai, CISO and VP at Constellis, explains how CMMC requirements are reshaping government contracting and why effective compliance depends on stronger security controls, operational evidence, and organizational alignment.
Full text:
Cybersecurity requirements are increasingly shaping eligibility for government contracts, with technical expertise alone no longer enough to compete. Although the Pentagon suspended the next phase of CMMC implementation in July 2026, existing rules remain in effect, leaving contractors pursuing higher-level certification with substantial technical and organizational compliance challenges. Thanh Thai , Chief Information Security Officer and Vice President at Constellis , has extensive experience aligning cybersecurity programs with business requirements. He helped rebuild the company's security operations following a major cyber incident and led efforts to achieve CMMC Level 2 certification, strengthening technical controls while improving how security teams work with the broader organization. "I don't think the question is, 'Should I go from Level 1 to Level 2?' It's, 'Do you want to do business with the government or not?'" Thai says. For contractors seeking opportunities that require Level 2, certification becomes part of their ability to compete. Meeting those requirements involves decisions about security investments, operational processes, and the evidence needed to demonstrate that controls work. CMMC raises the stakes for government contractors Contractors with Level 1 status remain ineligible for opportunities requiring Level 2, regardless of their ability to deliver the project. Thai sees similar requirements appearing beyond the Department of Defense, extending the commercial implications of compliance across government contracting. "If we want more contracts, we need to meet the government's requirements or our customers' requirements," he says, pointing to frameworks such as CMMC, NIST 800-53, and Cyber Essentials Plus. "Those are hard requirements to win contracts." For contractors seeking certification, there’s a financial burden involved which depends partly on how they define the assessment scope. "Cost is interesting because if you don't scope it properly, it can cost you. Scope is very important," Thai explains. Defining which systems and processes fall within that scope helps organizations identify the controls they need to implement and the resources required to demonstrate compliance. Security compliance requires operational evidence Documented security policies establish expectations, but CMMC compliance also requires organizations to implement controls that enforce those policies and demonstrate their effectiveness. Technical safeguards can prevent unauthorized actions, while assessment evidence helps establish that security practices operate consistently across systems and teams. "We focused on controls so that you couldn't do something if it was against policy," Thai says. His team approached implementation by consistently asking, "How do I prove this?" That emphasis on evidence guided efforts to strengthen existing security systems and verify that controls worked as intended. Meeting technical requirements can involve substantial changes to existing infrastructure. For example, configuring firewalls to operate in FIPS mode may affect established security rules and authentication processes. Thai encountered these complications firsthand. "The hardest part for us was putting all our firewalls into FIPS mode. I think it took us three solid weeks, and that was all we did. It broke a lot of existing rules and user authentication," he says. Implementing 802.1X introduced additional challenges, even with a security operations center and SIEM already in place. Assessments also examine how employees apply security controls in practice. Beyond reviewing documentation and technical evidence, assessors may interview the engineers responsible for maintaining systems to verify their understanding of established procedures. Thai recalls that assessors spent little time interviewing him directly, concentrating instead on technical staff. "Because if the engineers don't know it, that means you don't do it," Thai says. Security decisions extend beyond compliance checklists Compliance frameworks define required controls, but organizations still make decisions about how to satisfy them. Those choices can produce different levels of protection even when the implemented controls meet the stated requirements. Thai uses multifactor authentication as an example. Organizations may implement MFA through email or SMS, satisfying a basic requirement while leaving opportunities to strengthen authentication through methods such as FIDO security keys or authenticator applications. "It's about understanding the spirit of the requirement," Thai says. "Why are they telling you to use MFA? To protect your credentials." Evaluating controls against their intended security objectives helps organizations make more informed implementation decisions. Thai's team followed this principle during its CMMC efforts, beginning with the security problems it needed to prevent and developing controls that could address them. "CMMC was important to us, but we didn't do it solely to be compliant," he says. Long-term security requires organizational commitment Building a mature security program requires more than implementing technical controls. Organizations also need to establish security as a shared responsibility, with leadership and business teams understanding how cybersecurity supports commercial objectives . Thai emphasizes the importance of connecting security investments to business priorities, particularly when compliance requirements influence contract eligibility. "When we frame it as pursuing more business, everyone understands," he says. As cybersecurity requirements become more closely integrated into business operations, collaboration across departments becomes essential to maintaining effective controls and demonstrating compliance. For Thai, the long-term priority is developing security capabilities that strengthen the organization while supporting future certification requirements. "We're not aiming for certification. We're aiming for security, which then feeds easily into certifications," he concludes.

## Cyber Reporting Deadlines Put Pressure On Businesses To Trace AI Agent Actions
URL: https://www.thesecuritydigest.com/news/ai-agents-cybersecurity-compliance-risks
Published: 2026-10-16T20:25:19.303Z
Section: Observability
Summary: Simon Gooch, Field CIO at Saviynt, explains why autonomous AI agents are creating new compliance challenges and how organizations can establish governance, oversight, and accountability from the start.
Full text:
AI agents can take unexpected routes to complete tasks, leaving businesses unable to explain exactly what happened when something goes wrong, especially in a cybersecurity investigation. This uncertainty becomes a compliance problem when regulators require companies to report security incidents within strict deadlines. For CIOs and CISOs, the challenge is shifting from approving AI deployments to proving they can govern them and adhere to the latest compliance guidelines. Simon Gooch , Field CIO at Saviynt , has seen companies make similar mistakes with compliance before. He spent more than 25 years at Accenture, leading cloud transformation, security, and digital identity initiatives. He worries companies are giving AI agents access to important systems before establishing the controls needed to manage them. “To some degree, up to this point, the guardrails, the considerations of the impact, and the governance of all that technology have been secondary,” he says. AI adoption is exposing a familiar governance blind spot Gooch thinks companies often view compliance as an afterthought when adopting new technology. He recalls how some organizations approached GDPR. They focused on what they could legally defend and how much time they could buy to change their processes. "How do we argue our position legally? And if that doesn't work, how do we give ourselves enough time to adjust whatever process we need to adjust to be roughly compliant?" he says. As a reference, Gooch remembers the migration from on-premises to cloud computing. Employees could use services even before companies knew who was accessing them, how much they cost, or what risks they posed. AI adoption is following a similar trend. New rules now focus on product security, AI risk, and supplier accountability. "There's a big coming together of some of these different regulations. I think they're forcing organizations to really start asking: where are we from a governance perspective?" Gooch says. He thinks pressure will make it harder for companies to use technology first and manage its governance later. New cyber rules put AI's accountability gap on the clock The EU's Cyber Resilience Act makes the problem immediate for manufacturers of covered digital products. Since September 2026, they must give an early warning within 24 hours of discovering a serious vulnerability or security incident. A detailed notification follows within 72 hours. "How are you going to report and understand the breach, or all the information you need to report, within your 24-hour window when you don't necessarily understand in detail what your machine is doing?" Gooch asks. The initial warning doesn’t require a full investigation. Organizations must collect enough information to find affected products and establish initial facts. Starting in December 2027, other CRA requirements will add more responsibilities for managing third-party components and vulnerabilities during a product's support period. Th e EU AI Act sets risk-based rules. These include documentation, logging, and human oversight for high-risk systems. More requirements will take effect in 2027 and 2028. The UK's proposed Cyber Security and Resilience Bill aims to extend security and reporting duties. This will affect more critical service providers and suppliers. Gooch notes that these laws differ, but they all need clearer responsibility for connected technologies."It's making everyone understand accountability all the way up and down the chain," he says of the CRA. The next compliance check starts when an AI agent is built Gooch argues that organizations must establish controls during AI development. He compares this to software development, where teams set up CI/CD pipelines as they began releasing software faster. These checks helped teams find and fix problems before the software went live. "We understood that as a governance approach: build the controls required for compliance as early as possible in the lifecycle of whatever you're doing," he says. He believes the same approach should apply to AI agents. Organizations need to know which models are being used, where they came from, what data they handle, and what permissions they have. They also need records that help investigators reconstruct unexpected actions, with controls suited to the system's risks and applicable regulations. "If you're developing AI agents in your organization, you need to think about controls at the point those things are created," Gooch says, "If you wait until they've been rolled out to check whether you're compliant, particularly now that compliance itself is being looked at differently, it's too late." But documenting an agent's behavior only addresses part of the problem. Companies also need to establish who is responsible for the actions that agent takes. Autonomous agents still need someone accountable for their actions Gooch argues organizations should view AI agents as separate entities. They need clear ownership and control over what these agents can access and do. "If you don't treat them as first-class citizens, almost like another identity type, and put governance around them, you run into problems," Gooch says. As agents take on more duties, companies must track who gave access. They also need to know who is accountable when issues arise . "There needs to be accountability for the AI agent," Gooch adds. He believes organizations can’t avoid responsibility just because a decision came from an autonomous system. That responsibility also changes how companies should approach compliance. Gooch believes the new regulations can help businesses build stronger controls early. This way, they can understand AI risks more clearly and feel more confident using autonomous systems. The goal is to make governance useful throughout an agent's lifecycle. "It has to be about building a system of control that enables you to use this technology effectively while remaining compliant," he says.

## Get Identity Governance Right, and the Autonomous SOC Earns Its Autonomy
URL: https://www.thesecuritydigest.com/news/agentic-soc-identity-shain-jacob-texas-hhs
Published: 2026-10-13T02:18:54.801Z
Section: AI
Summary: Shain Jacob, Interim Chief Information Security Officer at Texas Health and Human Services, on why identity ownership and human validation still decide whether an agentic SOC is worth the tooling.
Full text:
The network perimeter that security programs spent two decades hardening has effectively dissolved, but it hasn't been replaced by a cleaner boundary. It's been replaced by a sprawl of identities, most of them not human . Service accounts, API keys, workload credentials, and now autonomous agents all authenticate continuously and carry permissions that would set off alarms if a person held them. Defense now turns on a narrower problem: who or what is authorized to act at the exact moment an action happens, and whether anyone can prove it afterward. Shain Jacob has spent more than twenty years securing large, regulated environments, and now oversees enterprise technology and information security for one of the largest state health agencies in the country. As Interim Chief Information Security Officer at Texas Health and Human Services , his mandate covers security architecture, cloud modernization, and compliance across HIPAA, NIST, and state frameworks, for systems that hold the data of millions of Texans. His view of the identity problem starts with a correction to how most teams frame it. "Identity is where the majority of tool sprawl happens, and the network perimeter has effectively disappeared," Jacob says. "Without clear ownership of governance decisions, more tools doesn't mean anything." The perimeter multiplied instead of moving Jacob's central concern isn't identity in the abstract. It's the volume and opacity of non-human identities now operating inside enterprise systems. Knowing who has access to what, and whether that access still makes sense, is the baseline. The more challenging layer sits underneath it, where machine identities authenticate against each other with no person in the loop. Recent survey work from the Cloud Security Alliance found that most organizations have no clear ownership or accountability for their AI and machine identities, and that a large majority don't trust their legacy IAM tooling to manage the risk at all. Service accounts are where Jacob has watched this go wrong most often. Because a shared account gets handled by multiple people, accountability dissolves the moment something breaks. His team has moved to eliminate them and tie every privileged identity back to a named person. "We now ensure there are no service accounts in play. Every one is associated to a named account, and we know who authorized it, when, where, why," he says. "We make sure it's either just in time, or a time-based one-time password is enabled for that particular session." The approach lines up with the zero trust principles NIST laid out years ago, which pull the security decision away from network location and onto the identity and the moment of the request. Tooling alone doesn't close the gap, and Jacob is direct about the cost of assuming it will. "Every new platform is another integration that we have to maintain, another vendor to risk-assess, another source of logs competing for a security team's limited attention," he says. He still runs multiple scanners and redundant endpoint tools on purpose, so that a miss by one gets caught by another. "We don't rely on just one tool, because if one fails, the other one picks it up." What keeps that redundancy from compounding the noise is governance sitting on top of it. Someone has to decide which tool is active and which is passive, and that decision has to have an owner. When authority gets delegated Delegation is where the trust chain starts to fray. When a request passes through a service account, then an API, then a database, and on through several more machine identities, the logs stay accurate but accountability loses its grip. Jacob's answer is architectural. His team is building toward an agentic SOC layered on a medallion data model, with bronze holding immutable raw capture, silver holding normalized and vendor-neutral schemas, and gold holding the enriched entity timelines the security team actually investigates against. The point is total visibility into what's happening across the infrastructure, so that any deviation has a traceable path back to a source. On top of that data, behavioral analytics watch for identities acting outside their normal pattern, and a library of playbooks flags anything that looks malicious or out of the ordinary. When something trips, an agent raises it, and a human steps in to confirm whether it's benign. "A human gets into the loop and then makes sure that, 'hey, this is nothing wrong, he was accessing GitHub or he was doing this or that,'" Jacob says. That human validation is fixed, not optional. Detection engineering and behavioral baselining are exactly the kind of work that keeps pulling the SOC's structure toward outcomes rather than console-hopping. The agentic SOC's real ceiling The capability is genuinely impressive, and Jacob is careful not to undersell it. The agentic SOC in his environment can write back to disable a compromised account and reach into the endpoint platform to contain an affected host automatically. He's chosen not to enable that autonomous containment yet, keeping a person on the trigger. The reason is accuracy, and he has the failure cases to justify it. Given a set of source and destination IP addresses and asked to separate genuine work activity from malicious traffic, the agentic system has returned wrong answers. "It will tell that this IP address is a good IP, but in all reality it is a bad IP. It only looks at one or two databases," Jacob says. The agent streamlines correlation well. It doesn't yet clear the bar for judgment. "Validation, we need to do it ourselves." That gap is why triage and containment can move to machine speed while irreversible action stays human-directed, and it's the same tension that keeps surfacing when teams try to improve detection coverage without inheriting a flood of false confidence. For a regulated agency, a confident wrong answer that auto-contains a legitimate host is its own kind of incident. That's also the argument for governance running in parallel with identity governance rather than trailing it. The reason to invest in an agentic SOC, in Jacob's framing, is speed against a threat landscape where the majority of attacks he now sees are AI-driven. Matching that speed safely is a governance problem before it's a tooling one, which is the through-line in how readiness frameworks are being built for agentic operations elsewhere. More automation, more people The expectation that autonomous tooling thins out the SOC runs opposite to what Jacob is seeing. Headcount is going up, not down. "As more and more AI tools are coming into play, the workload has increased drastically. Especially with AI identity coming into play. We need a lot more AI engineers in security," he says. The skill mix shifts toward agent governance, detection engineering, and oversight of autonomous workflows, but the net demand climbs. Part of that pressure comes from how development has decentralized. AI has made it easy for people well outside the security org, in HR, sales, marketing, or on a product team, to build and ship applications. "It's very easy for people to build applications now, and how good is it? We cannot predict that," Jacob says. Stale or outdated records that never should have left a controlled system can end up pasted into public generative AI tools by someone who doesn't know better. Governing that requires an escalation model rather than a gate, and it puts the insider exposure problem in front of teams that were built to watch the perimeter. Jacob does credit AI for real wins on the build side. "Some of the applications that no vendor was willing to touch, we were able to convert into a production application and modernize it," he says. He pairs every one of those wins with a hard caveat. "We just have to be very careful that there are no bugs and no backdoor open, so vulnerability scans are being done in a timely fashion. Cloud security is done, DSPM is done." That means the whole thing runs through a DevSecOps lifecycle meant to catch what speed introduces. Foundations before autonomy For all the attention on the agentic layer, Jacob keeps returning to the plumbing beneath it. Metadata tagging lets his team correlate where an incident happened and how the attack vector was exposed. Data lineage tells them where sensitive data originates and where it flows, so exposure can be traced and scoped when something goes wrong. The visibility problem he's most focused on is that most enterprises can see activity around the perimeter but have almost none into application and database logs. "One of the things that we are trying to do is get these basic foundational things set up so that these datas are being protected," he says. The agentic SOC and the volume of alerts it's meant to tame both rest on that groundwork. Get the lineage, tagging, and log coverage right, and the autonomy has something trustworthy to act on. Skip it, and every downstream decision inherits the gap.

## Exposure Resilience Helps CISOs Decide Which Vulnerabilities Matter As Exploit Windows Shrink
URL: https://www.thesecuritydigest.com/news/exposure-resilience-attack-path-vulnerability-prioritization-sunil-varkey-hexaware
Published: 2026-10-09T04:59:52.498Z
Section: Leadership
Summary: Sunil Varkey, EVP and CISO at Hexaware Technologies, explains why security teams should focus on the weaknesses attackers can reach and the context SOC agents need to act.
Full text:
AI is speeding up vulnerability discovery for defenders and attackers alike, and the time between disclosure and a working exploit is getting shorter. Patch cycles built around days or weeks of testing weren't designed for that pace, and not every vulnerability carries the same risk. Many security leaders now focus first on the weaknesses an attacker could reach and close off the path to them. That takes telemetry, identity, and exposure data viewed together, which AI agents in the SOC also need before they can safely act. Sunil Varkey is the EVP and Chief Information Security Officer at Hexaware Technologies , a global IT services and consulting firm. Over more than 30 years in cybersecurity leadership across banking, telecom, IT services, and manufacturing, he has served as global CISO at Wipro and led cybersecurity assessment and testing at HSBC. Varkey makes the case that security teams should move from vulnerability management to exposure resilience, which means understanding which weaknesses an attacker can reach and how to cut off the routes to them. "The vulnerability always existed, but the terrain changed. Now there are more people outside who know how to attack," Varkey says. For years, teams could leave low- and medium-severity flaws in older applications unpatched because exploiting them took time and skill. AI makes many of those flaws easier to exploit, so teams need to look again at risks they once considered safe to leave open. Beyond the severity score Security teams have traditionally decided what to fix first based on each vulnerability's severity score. A high CVSS rating meant patch it now, and a low one meant it could wait. Varkey says that score alone no longer tells teams how dangerous a flaw is. Whether an attacker can use it depends on who has access to the system, what privileges they hold, and how the system connects to the rest of the environment. "Now we are saying if it comes from an ID with a particular privilege, from this environment, and this sequence is followed, then we have a problem," he says. Most teams aren't set up to see those conditions together. A typical system runs dozens of applications, and vulnerability teams usually review each flaw on its own, without looking at how flaws connect across those applications. Scanning tools tend to check one type of asset at a time, such as operating systems, applications, or network devices. As a result, information about identities, misconfigurations, and exposed systems sits in separate places. Exposure resilience means bringing that information together so teams can see whether an attacker could reach a given system. That work starts with knowing what software the organization runs and where. In late 2021, security researchers disclosed a critical flaw in Log4j , a free, open-source logging tool built into thousands of applications. Log4j often sat inside other software, so many organizations had no list showing which of their systems used it. Without a software bill of materials , which records every component inside an application, teams had to search system by system. "We knew it was used heavily, but we never knew where it was used. There was no inventory of it, and that took most of the time," Varkey says. Revisiting old permissions When business teams rush new systems into production, security often takes a back seat. Accounts get elevated permissions to make testing easier, and those permissions frequently stay in place after launch. Users and service accounts end up with far more access than they need. Security leaders can see the risk but can't always remove access that other teams rely on, and Varkey says CISOs need backing from executives to clean it up. "You gave this privilege to a service account or an AI environment. Is that really needed? CISOs should be empowered to clean that environment up and reduce exposure," he says. The first step is being able to trace every account and see what it's allowed to do. Each user, system, and service account should have only the access it needs. Teams also need to keep configurations in check and find old systems that are still on the network but no longer have an owner. Every one of these steps removes a route an attacker could use. This also changes the vulnerability management team's job. The team has mostly focused on tracking flaws and making sure patches get applied . Now it also needs to watch accounts, permissions, system settings, and anything exposed to the internet, since each of these affects whether an attacker can get in. "Vulnerability management teams have to evolve into a bigger group that looks at attack surface management and identity exposures together, maybe an exposure resilience group," Varkey adds. Where agents step in AI agents in the SOC depend on that same combined view. Many identity tools pull data from directory services to flag over-privileged and inactive accounts. Varkey sees more value in pairing that identity data with telemetry from across the environment, which shows how those accounts behave day to day. "If I take the same data, put it into a large language model, and correlate it with my telemetry, I may get more insight," he says. Teams decide how much freedom to give an agent based on the cost of a mistake. Varkey expects agents to start with routine tasks that entry-level analysts handle today. For example, if a user logs in from two distant cities within an hour, the account has likely been compromised. An agent can reset the password and log the user out of active sessions, just as an analyst would. If the agent is wrong, the impact is limited to one account. Decisions with wider impact are harder to hand off. Shutting off access to a system that brings in revenue can disrupt the business, and weighing that tradeoff takes people who understand the company's priorities. "If my key revenue-generating application is exposed to the internet, am I going to immediately block it completely? I may not do that," Varkey says. Many teams design agent workflows with that line in mind. Automation handles contained responses, and a person approves anything that affects live business systems. Varkey expects the industry to reach a point where faster patching can't keep up with how quickly AI uncovers new vulnerabilities. Teams that already know what systems they run and who can access them will be better prepared when that happens. "The current norm is not working. We need to go back to the drawing board and look at how we redesign this," he says.

## Security Leaders Trade Bloated Legacy Platforms For Tools Built For Today's Threats
URL: https://www.thesecuritydigest.com/news/legacy-security-platforms-ai-machine-speed-brad-gorka-veritiv
Published: 2026-10-09T04:58:42.039Z
Section: Industry News
Summary: Brad Gorka, CISO at Veritiv, on why security leaders are moving their budgets to platforms built for current threats as AI native challengers gain ground.
Full text:
The legacy security platforms that led the market five years ago now charge their customers twice, once for the original product and once for the AI features added later. Many security leaders are no longer willing to pay for both. Switching vendors has become cheap enough that newer companies built for current threats are taking accounts from the slower incumbents. Brad Gorka is CISO at Veritiv, a leading, global full-service provider of specialty packaging solutions. In addition to packaging, Veritiv provides JanSan, hygiene, print, and publishing products and services. Gorka has spent more than two decades in IT and security and has worked at organizations ranging from a few hundred employees to more than 300,000. Before Veritiv, he spent seven years as CISO at CommScope, where he helped build the security function and team from the ground up. He has bought security tools across that entire range, and he has watched the vendors selling them fall behind what their customers need. "You have to walk away from these old legacy tools that served you well five, six, or seven years ago, but aren't really meant for today's threats," Gorka says. Those tools worked well when they were installed. Attacks have gotten much faster since, and much of the activity security teams need to see has moved somewhere the older tools can't reach. He points to a network monitoring platform that a colleague recently raised with him, one that did an excellent job a decade ago. "Things have transitioned to more about identity telemetry than network telemetry, and you've got all this stuff out in clouds where you're not even able to monitor the network," he says. Bolted on Gorka isn't arguing for throwing out everything the older platforms were built to catch. "Those threats that those tools dealt with have not entirely gone away, so you can't abandon that. But you need to evolve into the newer tools that can detect and mitigate modern threats," he says. In his experience, younger companies get there first. They build for current attacks, then work backward to cover the older ones, a pattern he has seen play out in email security in particular. Legacy vendors tend to move in the other direction, holding on to the monolithic platform they already have and adding AI on top of it. "It usually looks and feels poorly integrated, but then you get the quote for it and it's twice as much as one of these younger companies is asking for," Gorka says. "You've already put together this Frankenstein's monster that's clunky, and you want to charge me double for it." What he'd rather see from the large vendors is a straight answer about where their investment is going. They have the research budget to find a promising startup, buy it, and stand behind it, and Gorka thinks they should say so plainly, then offer customers a licensing path off the old product. "We bought it. We stuck our logo on it. We're putting R&D dollars into it, and we think it's great," he says, describing the pitch he'd like to hear. Holding on to the old product line carries a bigger risk for the vendor. "Do you want to lose those SKUs and get them onto some new SKUs, or do you want to lose the entire account? Because that's what's happening right now." Fixing at speed The same AI that helps a security team is now in the hands of the people attacking it. "The bad guys have access to these tools too, and they've raised the bar on the quality and quantity of their attacks," Gorka says. On the team's side, AI works through more security data than people can review by hand, sorting it quickly and flagging what matters. It's also taking on more of the analytical work. Gorka has followed AI in third-party risk management closely over the past few years and has watched the output improve. "A couple of years ago it was a little bit sloppy, and I had to fill in a lot of gaps. Now it's performing work that's the equivalent of a human with 150 years of experience, and there is no human with 150 years of experience," he says. An attack that once took days can now run in a fraction of that time, and the window to catch and fix a flaw shrinks with it. Faster discovery doesn't make every finding urgent, though. "It doesn't matter if it found 150 low vulnerabilities that it can string together into a critical. If any point of that isn't achievable from your attack launch point, then it alters how important it is to really get it fixed," Gorka says. For the flaws that do matter, Gorka wants his team to close them at machine speed , before the affected code reaches production. "Hopefully we can get to a point where we're remediating the code as fast as something like Mythos can identify the flaws. That's where we're going to have to get to," he says. A platform slower than that leaves his team exposed while the attack runs ahead of it. Staying mobile Gorka keeps contracts short, taking nothing longer than two years and some at one year, because the market resets every few months and a long commitment leaves no room to react. "I'm very strict about the duration of a contract. Know what your exit strategy is, try to set things up in such a way to drive down the cost and complexity of switching, and be willing to walk away," he adds. He also pushes vendors to commit in writing that features promised at signing stay available and that any price increase carries a ceiling. Not all of them will, and knowing which is part of how he decides . One large vendor told him an AI feature was included in the platform, and he asked for that to go into the software agreement. The vendor refused, though Gorka's team did secure a cap on increases from one contract to the next. "They knew where I was going, and they weren't buying it. But I think we have to try and do as much of that as we can, otherwise the pricing can go wild," he says. The leverage has shifted toward buyers. "With all the API capabilities we have now and everything cloud-based, the switching costs have gone substantially down on this stuff. So I think the market will govern itself to a certain degree," Gorka says. Smaller vendors also move faster on customer requests. One startup told him it could take an idea from a customer and have it in production days later. "Go tell that to a big company such as Microsoft or Cisco and they'll laugh at you," he says. "Every time you go ask them for something, they knock it out of the park and deliver in short order. You're going to stick with them." Gorka now reevaluates the market roughly every three months and keeps his options current, since AI has lowered the barrier for new companies to reach the market. "It's like, 'Hey, you're not the only game in town. I've got people beating my door down for this stuff, and they've got better prices,'" he says. "You've got to be willing to walk and look at other options that are out there." Faster on both sides Gorka has watched this pattern repeat across his career. A new capability arrives and gives one side an advantage, then the other side catches up and the two even out. He expects AI to move the same way. "It's going to be the same battle we've been doing for the past 10 or 20 years," he says. The cycle runs faster now, and cost decides how fast each side can move. Running these models costs money in compute, and Gorka expects attackers to keep chasing the biggest payoff for the fewest tokens. "The more their costs go up and the more their time and effort goes up, they consider those things too, just like a regular business does," he says. Defenders are watching the same expense. He sees them matching the model to the task, running a cheaper, older one where it does the job and saving the newest for the work that needs it. "I'm starting to see organizations ask, 'Do you need the platinum-level AI to do this task?' And it's, 'No, we could use the AI from a year ago that costs very little now,'" Gorka says. Used that way, AI stays affordable even as teams lean on it more. "When it comes to adversaries, it's about economics and it's about cost. The speeds are going to dramatically shorten, and they're going to have to shorten on both sides," Gorka says.

## Security Leaders Prepare For Improvised Attacks By Changing Their Own Operating Speed
URL: https://www.thesecuritydigest.com/news/shekhar-kachole-turiya-digital-ai-security-strategy
Published: 2026-10-07T14:27:44.988Z
Section: Industry News
Summary: Shekhar Kachole, Founder and CTO at Turiya Digital, explains why a company's own practices and the industry's hard-won lessons both have to feed its security program.
Full text:
Security teams typically write their detection rules from attacks that have already happened, a method that works when attackers repeat themselves. In July, an OpenAI agent cheating on an internal test reached Hugging Face's production systems by chaining a zero-day with credentials exposed on other services, inventing how it moved as it went along. A rule covering one particular path is easy to add, but covering a path that gets assembled fresh depends on how fast a company can change its own practice between one incident and the next. Shekhar Kachole is Founder and CTO of Turiya Digital, a technology advisory firm he started in 2025 to advise boards and executive teams on AI strategy, governance, and cybersecurity. He also serves as a non-executive director and takes fractional CTO and Chief AI Officer roles with AI-native startups. Shekhar spent 30 years in engineering leadership across payments, telecom, and financial services before founding it, most recently as chief technology officer of Worldline's online payments platform. "In the old era, there used to be enough lag between development of the technology and the tooling to create a process that people could follow. With AI, the pace of the development has increased so much that you need to completely change the mindset," says Shekhar. The three pillars he works from are people, technology, and process. Shekhar sees those three arriving out of order now, with tooling landing before there's a process to govern it or staff trained to run it. Preparing for what comes next Most security teams can handle the threats in front of them, though coverage of known attack techniques remains incomplete even there. Shekhar counts that as the easier part of the job. "Most of the teams are prepared to take care of all the threats happening at the moment," he says. "What is really missing is they are not prepared for what happens next, especially when quantum computing is going to take over and the probability of the threats is going to go exponentially higher." Shekhar sees most companies starting from somebody else's breach, and the response often closes without reaching the root cause . Each new incident adds a guardrail against the specific thing that happened, and the exercise repeats when the next one surfaces. "The current approach of most of the companies is, we know something has happened, there are some incidents that happened with some other companies," he explains. "Let's learn from that and try to have guardrails to protect ourselves from that. They are not prepared to really think about how the cyber attackers are moving forward. They are moving forward at a much higher pace than the companies are able to." Companies fall behind at different points, and Shekhar singles out the ones carrying compliance requirements. A regulated business can sign a contract for new tooling well ahead of the approvals and training that have to follow it. "Many of the companies are not able to do that," he notes. "They are either able to bring in the tools very fast, but then their people are not ready. Especially in the companies where you have compliance and regulatory requirements, which slows you down, you're not able to adapt at the pace when the tools are being deployed." Security inside the build Agentic development is recent enough that most companies have no settled practice for building it securely. A development environment is where Shekhar wants the security checks run, and he applies the same rule to performance. He counts both as part of what makes code finished, alongside a feature's main purpose. "Try to do things first in your development environments, and ensure that your security is not done at the production environment," he advises. "If you are really looking at DevSecOps, ensure that you are shifting left, meaning all your security practices should be applied as early as possible in your development time itself. When I’m writing code, it’s not just production-ready — it is also security-compliant and performance-compliant." Shekhar's test is whether those checks reach the teams writing code . He has led the same change inside engineering organizations before, and the hard part was getting developers to count security as their own work. "Get those earlier on and have your development copilots, whatever tools that you use, get your prompt engineering to really ensure that you have enough guardrails to already create the code which is going to be compliant," he notes. "The mindset needs to be at the developers level. If you have a security department acting separately, trying to bring in new practices that aren't applied in your downstream environments, then it's not going to work out." Bringing the outside in Shekhar splits this work into two directions, starting with the one most companies already run. "There should be one inward focus where you are looking at everything happening internally, from the architectural practices to your security practices to your development practices," he says. "Just look at how things need to be developed from a holistic point of view on the core purpose of your business." The second direction points outside the company walls. "The outward focus is what is happening in the industry," Shekhar explains. "Some companies are propagating the ideas on what are the best practices, and there are many forums where they talk about it. Encourage your staff to start engaging themselves and bring that industry information from outward to in, and these days it is really important to have both. If you are only internally focused and you don't care what other companies are doing, then an OpenAI Hugging Face situation happens." Tool selection is where Shekhar puts the most weight, and he'd start with the duplicates left behind by acquisitions. A business that grew by buying others tends to run two tools for the same job in different environments, and extending the stronger license costs less than a new deployment. "The most critical part here is your tool selections," he notes. "You might have to relook at the current tools you're using for your security and threat mapping. I have been using X as one of the tools at the moment. When I see what's happening in the industry, maybe it is Y, and I need to bring that in, because they have all the capability to look at the outward threats and bring those practices into the tooling they provide." Hiring for prediction Asked where the money should go, Shekhar puts people ahead of tooling, and he moves the retraining interval from every two years to every three or six months. "Less than ten years ago, we were dealing with all the security aspects manually," he says. "It is the human capital that has really adapted themselves to the level that we are now. I would invest much more on people, to make them aware, train them, get them really vigilant on what's happening around." Security org charts are already being redrawn around outcomes . Shekhar wants a company to finish acting on what it already knows before it starts hiring to predict. "When it comes to threat intelligence becoming predictive, especially in the era of AI, you really need to start thinking about how to build an AI-savvy team that can predict what is going to happen," he notes. "I would rather start bringing in real AI experts inside the team. The mindset of these new AI engineers is entirely different than a traditional developer or a traditional engineer." Shekhar is emphatic that security cannot remain the exclusive job of the security team. "Security is the responsibility of everyone," he says. The real question for any organization is where it currently sits on that scale. Acting on a prediction is where Shekhar pushes agent autonomy furthest, all the way to production. He keeps a review step in the loop, and leaves open whether a person or another system does the signing off. "I would really start ensuring that not only my people, but my systems are also able to predict what could happen and take necessary actions," he concludes. "My agentic AI implementation would also be flexible enough. The agent itself is able to detect that something could go wrong, go change the code, get through whatever your review process is, manual or automatic, and deploy that code on production quickly."

## AI Agents Handle SOC Triage And Gain More Freedom As They Build A Proven Track Record
URL: https://www.thesecuritydigest.com/news/agentic-soc-ai-agents-human-approval-georges-kaddoum
Published: 2026-10-05T15:07:03.301Z
Section: AI
Summary: Georges Kaddoum explains why critical SOC actions still require human approval as AI takes on more of the detection and triage work.
Full text:
AI agents now handle much of the routine work in security operations centers, including alert triage and threat analysis. The access that work requires also makes them a target. Attackers can hijack an agent by hiding commands in a website or document it reads, and the agent carries them out as if they came from legitimate sources. Until defenses catch up, some security leaders want agents to monitor and recommend, with a person approving any action before it runs. Georges Kaddoum is Senior Manager of IT Security and Operations at a private research university, where he oversees cybersecurity across both, including the SOC and organization-wide incident response. He has more than 20 years of experience in IT and previously served as the institution's IT Operations Manager, leading its information security and risk management unit and contributing to the medical center's electronic medical record rollout. He sees AI as a necessary part of how a SOC defends itself today. "Attackers are taking AI very seriously and relying on it heavily. From a defense and response perspective, we need to leverage AI as well," says Kaddoum. Over the past year, AI-powered attacks have hit companies across nearly every sector and disrupted daily operations. The tools behind those attacks are affordable and easy to find. Kaddoum doesn't think a SOC can keep up using traditional methods alone. Deciding how far to trust agents once they're inside the environment takes more care. Agents take the first pass AI-powered SOC platforms can now handle the first-line review and escalation work that level one analysts have traditionally done. Those analysts are often recent graduates who need weeks or months to build confidence on the job. An agent trained on a team's established procedures can start on well-defined tasks much sooner. Kaddoum sees agents taking over that work. They move quickly and surface useful insights, though their analysis goes only so far without context. Most alerts a SOC receives depend on the specific infrastructure being monitored , so an agent has to learn that environment to judge them well. Building that knowledge means charting every system, including the weakest points. Attackers do the same groundwork before they strike. Once that picture exists, teams need tight limits on who and what can reach it. If the agent is compromised, an intruder inherits everything it knows. "AI should be very controlled from a roles perspective and from an exposure perspective on the environment being monitored," he adds. People make the call Someone in the organization has to decide how much risk it's willing to accept, and that person answers for what happens next. Kaddoum doesn't think an agent can carry that responsibility. In some models, agents handle detection and forensics. "Agents should play the role of recommending actions. The action always needs a human approval or rejection in order to run," he says. Kaddoum is most cautious in critical sectors. At a hospital or a power utility, one wrong automated step can put lives at risk. He holds agents to the same zero trust rules that govern users and devices, where nothing is trusted by default. Outside those sectors, he's more flexible. For well-defined, low-risk work, he sees a place for agents to take predefined, tightly controlled actions against known threats. "In a few weeks, things might change due to the fast evolution of most AI platforms. We might identify other controls that can help give agents the right privileges, including action privileges," he notes. Keeping approvals moving Cost is speeding up adoption. An AI-driven SOC is much cheaper to run than a fully staffed one, and Kaddoum expects agents to reach into level two analyst work as well. That frees analysts to move into higher-value roles. He wants organizations to help them get there quickly while keeping the effect on their people in view. Agents can surface recommendations far faster than a team can review them, which puts pressure on the approval step. "With AI providing a huge amount of recommendations, decision making at the human level will become a bottleneck. We need to find solutions at this level so the operation can run more smoothly," Kaddoum says. Kaddoum expects agents to earn more responsibility as they prove themselves. He measures them against the analysts doing the work today. "A human actor can also commit mistakes. Once an agent's errors reach the same level as a human's, I believe we can trust these agents more," he adds. The views and opinions expressed are those of Georges Kaddoum and do not represent the official policy or position of any organization.

## When AI Agents Act On Their Own, Infrastructure And Security Need One Accountable Owner
URL: https://www.thesecuritydigest.com/news/agentic-ai-infrastructure-security-ownership-ciso-jake-hammock
Published: 2026-10-04T23:06:09.943Z
Section: AI
Summary: Jake Hammock, former CISO for the City of Seattle, explains how unified teams and risk-based metrics prepare organizations for agent-driven operations.
Full text:
AI agents can now rotate credentials and change firewall rules without waiting for human approval. Those changes fall under both the infrastructure team and the security team. When the two functions report to different leaders, no one clearly owns an agent's action if it goes wrong, and organizations often discover that gap in the middle of an incident. Jake Hammock is a Cybersecurity and Technology Executive with more than 16 years of experience leading security and infrastructure teams. He began his career as a U.S. Army Military Intelligence and Cyber Warfare Officer supporting U.S. Cyber Command and the National Security Agency. He later held CTO and CISO roles in telecom, SaaS, fintech, and energy. Most recently, he served as Chief Information Security Officer and Assistant CTO for Security and Infrastructure at the City of Seattle , where he helped lead a division spanning cybersecurity, identity, networks, cloud operations, and telecommunications under a single program. Agents acting on their own have only made the case for that structure stronger. "When autonomous agents rotate credentials and change firewall rules on their own, there's no longer a separate infrastructure decision and security decision. It's one decision, and it needs one accountable owner," Hammock says. Security leaders have debated for decades whether the security team should report into IT or stand apart from it. Agents reshape that debate . An agent can update a system in seconds, which leaves no time to route the work through two teams for review. Everyone's on security Large public organizations rarely run as a single entity. A major city can have dozens of departments, and a state government can have even more. "Most of these departments run autonomously. They have their own budget authority and their own legislative priorities," Hammock notes. Whether in government or in an enterprise with independent business units, security progress depends on department leaders trusting the central team enough to let it inside their operations. That trust has to reach the engineers doing the work, too. Many security programs are moving toward continuous threat exposure management (CTEM). In this approach, teams prioritize and fix exposures across the environment on an ongoing basis, and remediation belongs to the people who run each system. Under that model, network engineers, telecommunications teams, cloud and Unix operators, middleware engineers, and enterprise architects all take on security work as part of their jobs. "When you move from centralized vulnerability management to decentralized continuous threat exposure management, you flip the entire program on its head so that everyone becomes security. Welcome to the party. You're all cyber now. That's a hard sell, especially if people weren't hired to do that job," he adds. Buy-in comes more easily when security is part of the targets engineers already have. One way to do that is to write security into team standards and measure staff against them. For example, if a team's goal is to deploy three new applications by the end of the quarter, it only counts as met if each application passes security testing and is built from a golden image, a pre-approved template with security settings already in place. Because security is written into the deadline, engineers treat it as part of finishing the job. Scoring real risk Once security is built into everyone's work, leaders need to show that it's making a difference. The clearest way is to measure security by what it protects . Pointing to compliance rules or the risk of regulatory fines rarely motivates department leaders or engineers. Showing how security safeguards revenue is more persuasive for a company. For a city, the equivalent is public trust, meaning residents' confidence that essential services will keep running. "I don't really care about the volume of vulnerabilities we've mitigated. I care whether we mitigated them in time to prevent a catastrophe, and whether I can tie a business dollar to that," Hammock says. In practice, that means giving teams credit for steps that lower risk even when a flaw stays open. If a patch isn't available yet, a team can isolate the affected system from the rest of the network so attackers can't reach it. That work keeps the organization safer until a fix arrives, and the metrics should reflect it. Tying security to dollars works at the program level, but it isn't a tool for grading individual engineers. In Seattle, staff reviews looked at two things. The first was whether engineers deployed security controls the way the standard required. The second was whether they automated their procedures, so the team could spend less time reacting to emergencies. To track overall progress, the division built its own cyber health index. The index scored the City's security on a scale of 0 to 100, using the NIST Cybersecurity Framework 2.0 and automated data feeds. A perfect score was never the target. The index gave leaders a consistent view of where the City stood, tailored to its own mission. Hammock expects more CISOs to build scoring models designed around their own operations. Humans in the lead As AI becomes part of most security tools, the people overseeing those tools matter more. The shift is a move from humans in the loop to humans in the lead. In that model, people set the direction and limits that agents work within. That role calls for different skills than security operations required 15 years ago, when teams relied on antivirus software and early intrusion detection. At the City, the answer was to invest in staff before adding new tools. Employees received AI and risk management training, and leaders gave teams time to experiment and design their own solutions. As agents take on more daily operations, the people supervising them need to understand both the systems being changed and the security risks those changes create. Every organization's environment is different, so teams also need people who can adapt their tools to fit it. That kind of judgment takes time to build, and organizations need it in place before agents start making changes on their own. "Invest in your people and create space in your organization for creative thinking and reasoning," Hammock says.

## The Hardest Part Of An AI Kill Switch Is What To Do Before You Pull It
URL: https://www.thesecuritydigest.com/news/containment-strategies-ai-agent-shutdown
Published: 2026-09-30T01:57:04.919Z
Section: AI
Summary: Mohit Bansal, Senior Manager, Security Engineering at Webflow, explains why effective AI kill switches depend on early detection, tight permissions, and layered containment.
Full text:
An AI kill switch sounds straightforward until security teams try to define what they’d actually be shutting down. An enterprise agent may hold credentials, call other agents, interact with APIs, send email, write to production systems, and retain context in memory. A useful shutdown mechanism therefore depends on a broader incident response architecture that provides several opportunities to detect, restrict, and contain an agent before a full shutdown becomes necessary. Mohit Bansal is Senior Manager, Security Engineering at Webflow, where he leads infrastructure security, incident response, corporate security, and vulnerability management. He has more than seven years of experience across application security, DevSecOps, automation, and cloud infrastructure, and is also a member of the AIUC-1 Consortium working on standards for secure AI agent adoption. “An AI kill switch isn’t just a single button. It’s a spectrum of controls, and figuring out how we get there is the biggest challenge before we even reach the kill switch itself,” he says. All about agent dependencies The first layer is basic security hygiene. “You have to do all the boring but essential tasks before reaching the kill switch,” Bansal says. That means knowing which agents operate inside the environment, what dependencies they have, what permissions they hold, and which systems those permissions expose. This becomes more complicated once agents begin interacting with one another. “If Agent A can communicate with Agent B, and Agent B has write access, that inherently means Agent A also effectively holds that write access—even if it was not directly granted,” he explains. Traditional threat modeling gives security teams a way to reason through those paths by mapping trust boundaries, external connections, read and write access, and communication between agents and sub-agents. Once those relationships are visible, teams can estimate blast radius based on how access moves through the environment. “Assuming that every agent that you’ve deployed is eventually compromised can help you design for survival,” Bansal advises. Why containment should narrow capability before shutdown Once teams understand what an agent can reach, containment can become more precise. Permission reduction and quarantine provide a practical bridge between normal operation and a full shutdown. Teams can strip write access while preserving read access, revoke credentials, disable email-sending permissions, or withdraw API keys connected to sensitive services. Each step narrows what a compromised agent can do without unnecessarily disrupting wider systems. Network restriction sits further along that containment path. “Restricting network access might be a higher-level kill switch option right now, but it should usually be a last resort,” Bansal says. “API keys, write credentials, and permission sets should be the first levers you pull.” The same principle should shape human oversight. Rather than requiring approval for every autonomous action, teams can allow routine activity to proceed while reserving human intervention for high-risk or irreversible steps. "When I use Claude Code with auto mode on, it still pauses on higher-risk actions and asks me to confirm before anything irreversible happens," Bansal says. "That is a practical hybrid approach to keeping a human in the loop." Bansal expects containment to eventually extend beyond permissions to the semantic layer, including ways to interrupt a prompt in progress or clean compromised memory so it cannot influence later actions. Those mechanisms, however, remain far less mature. Detecting malicious behavior early changes the response Containment options matter less if the security team recognizes malicious behavior too late. For Bansal, the response framework starts with notifications and logging, with telemetry scaled to the consequence of the action. Read activity may not require exhaustive detail, but writes and irreversible actions do. “Every write, every irreversible action needs to be logged,” he says. Those records should include timestamps and trace information showing where a command originated, especially when one agent may have triggered another. A parent trace ID can help determine whether an agent initiated a malicious action itself or received instructions through another compromised component. That traceability becomes critical in multi-agent systems, where the agent carrying out an action may sit several steps away from the original compromise. Higher-level signals such as token consumption, tool calls per session, error rates, and cost per run can then help surface unusual behavior across a session. Together, those signals give teams the evidence to trace an anomaly back to its source and decide whether to restrict permissions, quarantine an agent, or escalate toward a full shutdown. The kill switch creates an attack surface of its own A shutdown mechanism has to survive the same threat model as the system it controls. As enterprises become more dependent on agents, the ability to disable those agents becomes increasingly valuable to an attacker . If a threat actor compromises the credentials, APIs, identity layer, or control plane behind the kill switch, a defensive mechanism could itself become a way to interrupt legitimate operations. “As AI agents become widespread, an improperly secured or easily exploitable kill switch could cause immense harm across an entire organization,” Bansal says. That risk underscores the need for layered authorization, strict separation of privileges, and clear boundaries between automated containment actions and those requiring manual human approval. A path of best practices Bansal is candid that the industry still has unresolved questions around what a reliable AI kill switch should look like. But the work required to get there is already pushing security teams to improve visibility, permissions, containment, and traceability, all of which matter before a full shutdown ever becomes necessary. “I don’t think an AI kill switch is going to be an easy thing to attain,” he says. “But in the path of attaining that, I think we’re going to make a lot of good decisions which are going to help us in the way that we can detect those things faster.” As agents become more deeply embedded in enterprise systems, the ability to intervene earlier may matter as much as the final switch itself.

## Enterprise AI Is Forcing Security Beyond Centralized Review
URL: https://www.thesecuritydigest.com/news/ai-security-governance-challenges-enterprise-adoption
Published: 2026-09-28T06:44:48.688Z
Section: AI
Summary: Scott Brammer, Chief Information Security Officer at RegEd, explains why AI security has to move closer to product and engineering teams as models, agents, and data connections evolve faster than centralized review processes can keep up.
Full text:
AI adoption is moving faster than the security processes companies built to govern new technology. A centralized security team may once have been able to inspect deployments individually, approve a narrow set of enterprise tools, and revisit those decisions on a predictable schedule. That model becomes harder to sustain when employees are using multiple models, product teams are building agents, engineering teams are connecting new data sources, and vendors are embedding AI across the software stack . Scott Brammer is Chief Information Security Officer at RegEd , a compliance technology company serving financial institutions, insurers, and brokers that recently crossed $100 million in annual recurring revenue. He previously built security, compliance, privacy, and corporate IT functions as CISO at Symend, after earlier security and risk roles at Travelers and Visa, where his work included embedding security checkpoints into development pipelines. That experience now informs how he approaches AI governance inside a regulated environment. “If you have proper guardrails and you're already managing agents, MCP servers, and data flows, the model doesn't matter. It should be as pluggable as software is,” Brammer says. His point is that security architecture has to withstand constant model change without forcing teams to rebuild the review process around every new version or provider. Why security review has to move closer to the builders The first phase of enterprise generative AI governance was comparatively contained. Security teams could focus on approved subscriptions, access controls, and preventing sensitive information from reaching unmanaged tools. It was a simpler environment than the one most companies are now managing. “We are now in a space where it's much more nuanced,” Brammer says. “We've approached agentic AI. Everybody is using, everybody is delivering, everybody is developing, which means you need a lot more flexibility with your control sets.” Hybrid environments add more complexity. One team may use one commercial model, another may prefer a different provider, while an engineering group builds something custom around internal data. Agents and MCP servers add another layer of connectivity, and the volume keeps growing even when security headcount doesn’t. “There's going to be more AI tomorrow, and I don't know of any security teams that are getting extra people right now,” Brammer notes. Security capability has to move closer to the teams building and operating AI . “You're going to need centers of excellence,” Brammer argues, “which means you are going to need a product-enabled team, and an engineering-enabled team that knows how to do guardrails, how to check them, and how to evidence them.” Risk determines how far controls need to go, while data sources and data sinks show where systems connect and what they can reach. Brammer reduces the baseline to three fundamentals: sandbox the environment, sanitize what enters it, and certify what comes out. “If you have those three basics,” he says, “you can reach for all the rest.” The broader objective is to push those controls earlier into development rather than leave security to inspect finished systems after the fact. Security controls have to outlast the model A model upgrade, downgrade, or provider switch is often treated as an event that can invalidate the previous review, but the governance built around restarting the process with every change won’t scale. “We are in month four of the largest Patch Tuesdays in software history,” Brammer says. Companies already manage constant software updates, and he expects model changes to become similarly routine. If development, deployment, agent, MCP, and data controls are designed properly, a version change should be absorbed by that system rather than forcing security back to the beginning. Model management challenges remain. Different models behave differently, carry different costs, and perform better or worse across specific tasks. Centers of excellence therefore also have to guide users toward the right models and configurations while communicating changes when one option disappears, or another becomes available. Brammer's own organization is working toward an environment where models can be made as hot-swappable as possible. “If you're doing some no-code solutions, you might need X,” he says. “If you're doing some highly mathematical functions, you might need Y. If you're writing policy or data comments, you might need Z.” The model can change while the surrounding governance remains in place, with observability showing whether the swap is actually working. Observability as a control layer for distributed AI Once security execution is distributed across product and engineering teams, visibility becomes the mechanism that keeps that model governable. Security needs to know what systems are running, what they’re touching, and whether the controls around them are working as intended. For Brammer, those signals should already be part of daily and weekly operating metrics, giving product and engineering teams visibility into usage, cost, configuration, and output quality. “You need to be able to show them: 147 prompts occurred in this product today. These were the weights that were applied. Here were the results. Ninety percent of them were certified as accurate,” Brammer illustrates. “If you don't have that built into the pipelines, into the delivery, and have that telemetry, that's what you need to work on.” That visibility gives the CISO better evidence for the product and budget decisions that shape AI deployment. Adoption rates, lagging teams, security flaws, and system performance can all move into the same conversation, giving leadership something more concrete than a generalized warning about AI risk . Observability also exposes the difference between documenting a control and proving that it survives real use. A disclosure page can show what should be happening, while production telemetry shows what’s actually happening once prompts fail, integrations change, or agents behave in unexpected ways. “I want to insist this is our most imperfect science in the security space right now,” Brammer cautions. Higher exposure requires more rigorous testing Not every AI system creates the same level of exposure. Brammer contrasts a private, sandboxed AI environment with a client-facing application connected to backend systems, where the consequences of a control failure are much higher. In a tightly contained model, prompts and weights are controlled and end users have no direct contact with the models. That kind of environment may not justify the same penetration-testing budget as something exposed directly to customers. “As soon as you get into the client-facing chatbot that incorporates data visualizations, has access to backend systems, etc., even if that's controlled agents, controlled MCP servers, or plentiful AI guardrails, that's a space where new skills are required,” Brammer says. Higher-exposure environments raise the standard for what security needs to know before testing begins. Teams need access to successful and failed prompts, telemetry from agents, and information about the decisions those agents are making. MCP servers require the same level of instrumentation. “If you can't see that information, then you don't know,” Brammer notes. Testing can then become more continuous. “You can automate daily injections,” Brammer says. “So here's all of the attacks that we're doing against the system today, tomorrow, the following day.” Vendors in continuous assessment and exposure management are already bringing more of this capability into AI security tooling, although Brammer cautions that the market is still developing and not every product performs as advertised. Inputs and outputs remain the durable security boundary Security teams can’t control how quickly agents, MCP servers, and models change, but they can control the boundaries around how those systems handle data and interact with infrastructure. For Brammer, that means defining guardrails according to risk, understanding what enters the environment, verifying what comes out , and continuously testing the path between the two. “AI agents and MCP servers may continue to evolve,” Brammer says. “They may continue to have different versions and versioning. But inputs and outputs, my friend, that's where the game is played.”

## AI Reopens The Security Build Versus Buy Debate And Moves The Value To Data
URL: https://www.thesecuritydigest.com/news/ai-revolutionizes-security-build-vs-buy-debate
Published: 2026-09-09T00:23:15.918Z
Section: AI
Summary: Arpan Maheshwari, Vice President of Product at CloudSEK, argues that AI is changing which parts of the security stack companies can realistically build themselves, while specialized data remains in vendors’ hands.
Full text:
AI has made it possible for security teams to do internally what would have required a dedicated engineering group a year or two ago. Teams can pull data from several vendors, correlate it, and stand up a working dashboard in a day. It’s a capability that reopened a build-versus-buy debate. Arpan Maheshwari , Vice President, Product at CloudSEK , has spent his career moving from software engineering into product leadership, including at Ontic, a physical security software company serving Fortune 50 clients, before joining CloudSEK to work on external threat intelligence. That experience has repeatedly put him across the table from enterprise security buyers asking whether AI now allows them to build more themselves . "Companies may have 10 different security products in their stack. They’re now asking whether they can build their own layer to correlate them all," he says. Specialized data remains a vendor advantage Maheshwari argues that teams shouldn’t focus on building data collection. “There's a lot of investment in both the initial setup and ongoing maintenance. So get the data from security vendors.” Those vendors have spent years accumulating specialized datasets that would be prohibitively slow and expensive for an individual organization to recreate. “If I talk about credential leaks, for example, that's something our company has been working on for the last 10 years. So we have a dataset covering roughly the last decade. Now, as an organization, if I wanted to build that myself, it would be next to impossible,” he says. The barriers extend beyond engineering. "A lot of this kind of data contains PII," Maheshwari notes. "If you decide to get into the data business yourself, you're introducing significant legal risk into your organization." Access can be equally difficult to replicate. Sourcing infostealer logs from dark web forums, for example, depends on relationships built over years inside those communities. AI cannot shortcut the trust required to gain that access. Data formats also change constantly, creating ongoing parsing and maintenance work. The build opportunity lies in correlation Getting the data from vendors only solves the first part of the problem. Since no single vendor supplies every category of data a security organization needs, companies have to bring different sources together. Historically, that required centralized engineering teams and lengthy integration projects. Maheshwari sees that changing. “What people are asking in the industry now is, 'Do you have an MCP server through which I can access your data?'” he says. Because MCP servers can connect with other MCP servers, teams can build an internal layer that pulls from multiple vendors rather than relying on each vendor to produce the final analysis. Work that once demanded significant engineering resources can increasingly be handled in-house. Risks still remain. Correlation can involve proprietary, sensitive, and regulated information, so organizations still need infrastructure that prevents data from leaving controlled environments. "When we look at companies like Anthropic and tools like Claude, they're also developing their own security layers," Maheshwari notes. Once those safeguards are in place, the case for building internally becomes much stronger. Speed and specificity make the build case stronger The strongest advantage of building the correlation layer is that internal teams can create what they need faster and tailor it more closely to their organization. "Business insights, dashboards, or reports that previously took months and months to build can now be built within a day and shared across the organization," Maheshwari notes. Another advantage is specificity. Incident response procedures vary between organizations, and getting an external vendor to understand and encode those workflows can take considerable time. "Once I have the data and the insights, I can create those SOPs pretty quickly myself," Maheshwari says. The tradeoff is financial. "AI gives you a lot of power, but there's an inherent cost associated with it," Maheshwari cautions. "The number of tokens companies are using is increasing, and it's becoming a substantial expense on the balance sheet of any technology company today." So building internally doesn't shrink the security budget; it only changes where that budget goes. Organizations still need to pay vendors for specialized data because internal AI systems have little value without reliable inputs. But some of the money previously spent on vendor-built dashboards, analysis, and custom insights can now support internal experimentation and development instead. The next frontier is cross-domain security intelligence Maheshwari sees one of the untapped opportunities in connecting physical security and cybersecurity , two functions that sit inside the same enterprise but typically operate with separate teams, technology stacks, and reporting lines despite increasingly overlapping risks. "Until now, nobody has really thought about correlating both datasets because there isn't a company in the world doing it at scale," he argues. Groups like Scattered Spider have used physical-world social engineering as an entry point for cyber intrusion, yet signals from each stage often remain in separate systems and investigations. As AI makes it easier to connect previously siloed cybersecurity tools, the same capability could eventually bridge physical and cyber security, revealing patterns and use cases that have so far been difficult to see. "If someone can crack that, it's a gold mine, in my opinion, at least in the security world," he concludes.

## A Governance Lens Stops Security Teams From Wasting Resources on the Wrong Risks
URL: https://www.thesecuritydigest.com/news/case-for-running-security-through-a-governance-lens
Published: 2026-09-08T17:47:28.614Z
Section: Leadership
Summary: Kristofer Wilson's path from data governance into security shapes how Newell Brands prioritizes risk, communicates it to executives, and scales it across a global footprint.
Full text:
A security team built around threat specialists will find every critical vulnerability on the network but may struggle to distinguish which ones affect the systems the business depends on. Severity scores don’t show what exploiting the flaw would cost the business, which can lead organizations to spend their resources on technically serious issues that pose relatively little risk. The alternative is a security function led by people who learn to read the business first and the vulnerability second, treating "how bad is this exploit?" as only half the question. Kristofer Wilson , Governance Manager, Global Information Security at Newell Brands , approaches security from that broader organizational lens. His work in data governance and records management taught him to understand where an organization’s data lives, how it moves, and where the risks emerge. He now applies that same structural view to security, connecting technical risks to the systems, processes, and priorities they affect. "I try to look at things more from the business side than strictly the threat and vulnerability side, making things make sense. Traditional information security can get laser-focused on a specific vulnerability or threat and how to remediate it, without always accounting for what happens next." The value of seeing beyond the vulnerability The strongest security teams combine technical depth with broad business understanding. "You really need both," Wilson says. "You need those specialized individuals that can go through the data and find the ways others can’t, or know the inner workings of all these things. But then you need someone else who can translate that into more of the business language." A governance-trained leader, in this model, isn't replacing the specialist. He's the translator standing between the specialist and everyone the specialist's findings are supposed to reach. The expert who understands both the business and the security environment is better positioned to set priorities , particularly when a scanning tool hands the team a severity rating stripped of context. "You might see some infosec folks and they might get a notification that it's a highly critical vulnerability and it has to be remediated right now, and it's top of the queue for them," Wilson says. "But if you actually look at that server, it could be a server that stores everyone's favorite color. So it really isn't anything to put resources behind." A critical rating describes how easily a flaw could be exploited, not what an attacker would gain from exploiting it, and treating the two as interchangeable can leave teams racing to patch a system nobody would benefit from breaching while more pressing matters wait their turn. Putting a dollar value on cyber risk While red, yellow, and green risk ratings offer a fast way to signal urgency, they often raise doubts. "If you present something that's a red stop sign to an executive, they're going to say, okay, well, what does that mean?" Wilson says. Newell Brands is leaning on a more comprehensive approach. The company has moved toward cyber risk quantification, developed with the FAIR Institute , that converts a vulnerability into a dollar-based comparison between the expected loss if it's left unaddressed and the cost of fixing it immediately. "We look at where we sit in our markets, and any kind of breaches or incidents that have happened in the past, or typical remediation costs down the line, and put everything in a formula," Wilson says. "So we can run a simulation and say, okay, we have this vulnerability. If we don't remediate it, we can expect an $80,000 cost every time it's exploited, or we can spend $200,000 to remediate it right now." It’s the context severity ratings alone lack. Scaling governance across a global organization The same governance program applies at organizational scale. Once the environment stops being a single server and becomes a company with tens of thousands of employees spread across regions, the challenge is no longer just deciding which vulnerability deserves attention, but where security resources and controls are needed most. "We try to manage everything from a single point and then disperse it out," Wilson says. "And then if we do have sites that can't reach those standards, we look at specialized controls that we can put in place there." Constant scanning shows where a brand or region is falling short. Rather than forcing every site to the same timeline, the company builds the exception around its constraints. Newell Brands is a large company with almost 25,000 employees worldwide, spread across several regions and languages. One of their biggest initiatives over the past two years has been translating key materials and making them readily available in all of the company’s official languages. "We’ve seen a lot more people reaching out from EMEA, LATAM, and even the APAC region with not just questions, but just kind of, well, thank you. We didn't know we had this documentation available. It saved us a lot of time.", Wilson explains. The path to security leadership is rarely narrow Wilson doesn't think his own route into security leadership is the only one, but he's specific about what separates someone who can run a broad program from someone who stays an individual contributor indefinitely. "If you're going to specialize in one thing, you can go very far in that one thing, but you're always going to be that individual contributor, or maybe the manager of a small team," he says. "If you want to grow into a leadership role, you have to diversify." A historian who became a policy writer, then a data governance lead, then a security governance manager isn't a career path anyone would design on purpose. It's what width looks like when it's built one unrelated stop at a time, and it's the same width Wilson argues the whole function needs more of.

## Distributed AI Adoption Is Forcing Security Governance To Become An Escalation System
URL: https://www.thesecuritydigest.com/news/ai-governance-distributed-decisions-matthew-sharp-xactly
Published: 2026-09-05T11:31:22.218Z
Section: Leadership
Summary: Matthew Sharp, Chief Information Security Officer at Xactly Corp, argues that AI decisions now surface in too many rooms at once for any single governance model to review them all.
Full text:
A company can approve its AI investments at the executive level and still find many of its AI decisions happening somewhere else. Marketing tests a chatbot on customer lists, support pilots a summarizer against ticket transcripts, and developers lean on models to generate code. Independent choices move company data through a third-party system, but only some reach the formal AI governance process. Adoption is often running at the departmental and individual level , leaving security without a single point where it can meaningfully review every decision. The advice to "bring the CISO in earlier" assumes one conversation is happening, but AI adoption starts dozens of them. Matthew Sharp , Chief Information Security Officer at Xactly Corp and co-author of The CISO Evolution , has spent years arguing that security leaders need financial fluency to be useful in executive conversations. At Xactly, a Vista-backed revenue intelligence company, he's living it. AI decisions surface in product development, departmental tooling and individual workflows all at once, making a single seat at a single table insufficient. The approved list was never going to be the whole list Sharp frames enterprise AI as two obligations running in parallel. Companies have to "adopt AI to drive efficiency across the business," he says, and they also have to "embed AI into your value streams in order to deliver outcomes for customers." Both paths run through a stack of vendors, each with its own shared responsibility model, which puts third-party risk in front of security before anyone writes a line of integration code. A moving regulatory picture sits on top, so the questions read like scoping exercises: "What can we do within the constraints of the law, and if we do those things, what additional investments are going to be required for us to do them in a way that is compliant with the law?" Formal programs capture only part of this. In any company with an AI-first mandate, Sharp says, "there's a lot of people in your org who are not a part of that big central set of cohort investments that are going to still have exposure to AI tools and be eager to experiment with those tools" inside their own workflows. That experimentation is exactly what makes centralized governance incomplete, and it's hard to discourage when employees are just trying to do their jobs faster. Sharp's answer starts with expectations rather than enforcement. "At the highest level you have to have some tolerance for ambiguity," he says, "and then you also have to define your ROI as a hypothesis that gets measured and validated on the back end." Marketing, support, professional services and engineering each perceive a different payback, so the measurement has to bend to the work. Meeting ten times isn't governance Sharp is often asked how many people belong in the room, and his answer depends entirely on how the company is structured. If the company is running ten or fifteen AI initiatives across its core departments, there's room to experiment. Once the transformation touches everything, every department ends up in the room whether anyone planned it that way or not. "How many departments do you have? If they're all involved, then they're all involved." The waste shows up when a standing core team gets replicated department by department. Put general counsel, the CISO, the FP&A team and corporate IT on every initiative across ten departments, and those back-office players sit through "that same meeting 10 times. That seems relatively inefficient." The opposite failure worries him more, where a small group carries decisions it has no context to make. Four people running AI adoption for a large organization won't hold the security and privacy implications, and they almost certainly won't hold the cost picture. "Those four people had better be making high-level decisions and pulling in people in subsequent conversations," he says, "because if they're just driving it, what it means is they are aggressively adopting AI in a way that's going to put them in hot water. They just don't have enough context in order to make fully informed decisions." Both failures point to the same answer: an escalation system where the organization knows which decisions belong in which room and when one has crossed a threshold that requires security, legal, finance or IT. Expertise gets pulled toward the decision instead of seated permanently beside it. Moving security into capital allocation Inside those rooms, Sharp's answer is for security to speak the language already in use. Xactly works with a cyber risk quantification vendor "that's helping us identify a median annualized loss expectancy," he says, "and as we then map that to controls and control maturity, you can gain a sense for base rate metrics, and that helps direct investments in terms of capital allocation." Security needs a voice in investment decisions while they're still being shaped. For AI, Sharp builds the estimate from the pieces that exist. Control maturity gets measured against a cross-mapped framework covering the EU AI Act, ISO/IEC 42001 and several major vendor governance models. Regulatory exposure gets inferred from published penalty tiers, which under Article 99 of the EU AI Act reach 7% of worldwide annual turnover for prohibited practices and 3% for the provider and deployer obligations an enterprise software company is far likelier to meet. "This is the kind of data we have, here's the kinds of activities that we're doing with that data, and here is the range of inferred legal and regulatory fines that we're likely to experience." The number carries wide error bars, and Sharp would rather name them than dress a framework score up as coverage . Ask him how exposed the company is by putting one AI tool into one marketing workflow, and he'll answer that it sits a level above that question. AI risk still has no established price The math stays rough because the data barely exists yet. Quantification vendors work without deep historical loss data on AI incidents, and the courts haven't produced the enforcement record that turns a law into a dollar figure. Sharp expects the AI Act to follow GDPR's playbook: marquee cases against large platforms first, then litigation that works its way down into the enterprise and mid-market. He treats convergence among the major AI companies as another usable proxy. When the published responsible-AI approaches from Google, Microsoft, Meta, Anthropic and OpenAI broadly agree on a control, he argues, a security team has reason to treat it as an emerging standard of care. "All the major players include that these controls are considered best practices," Sharp says, so a team can expect them to "be considered reasonable by the legal community and become a part of the legal precedent." The rules themselves keep moving, which argues for an operating model that can absorb revision. Colorado's AI law became an early reference point for state AI regulation before lawmakers repealed and replaced the statute in May 2026 and pushed the effective date to January 2027, and the AI Act itself was amended in July by the Digital Omnibus. Programs anchored to one expected regulation went back to redo the work. "There aren't proven best practices in AI. There's no consolidation in terms of the best vendors in the space. There's no legal precedent established through long-standing years of litigation against these laws. All of those things create uncertainty that we're going to have to navigate," Sharp says. Security leaders don't have the loss history they'd normally use to price risk, so they're building estimates from what they do have: penalty tiers, framework maturity scores and whatever consensus the industry has reached so far. The governance model that holds up is the one that keeps making defensible calls as the data, the case law and the technology all continue to evolve.

## Security Leaders Win Budget By Auditing Their Own Operating Model First
URL: https://www.thesecuritydigest.com/news/hem-asher-security-leaders-budget-strategy
Published: 2026-09-05T11:31:22.218Z
Section: Industry News
Summary: Hem Asher, former Senior Manager of Information Security at Insurity, explains why a metrics program and a ranked risk register have to come before any request for more budget.
Full text:
Security operations leaders asking for more money usually start with what the team lacks. Security spending keeps climbing across the industry, and a team that can show where the last allocation went has a better claim on the next one. Leaders who spend a few months tracking response times, false positive rates, and vendor performance walk into the same meeting with a record. The tracking also surfaces problems that no amount of funding would have fixed, and those months of tracking turn a request into a case. Hem Asher , former Senior Manager of Information Security at Insurity , has built security programs at SaaS and technology companies across insurance, healthcare, and digital experience. At Insurity, he directed security operations, governance, risk and compliance, and third-party risk management, reporting to the CIO and CISO. At Contentstack, he led information security and IT across the United States and India, taking the organization through SOC 2 Type II and ISO 27001 certification. Both roles made him responsible for taking a security budget to executives and defending it. "Once you have the right metrics, you look at your operating model. If it's the same operating model that you've had for the last five, six years, it might not align with what the business needs today. You kind of have to look at it in all angles and then work from there, but tracking metrics is the first part," says Asher. A team that has measured itself can say where its capacity goes, and the business can check the answer. Asher treats every later step as dependent on that record. Metrics before the ask Security leaders who can't demonstrate where their team's capacity is being consumed will struggle to make a compelling case for additional resources. Asher typically starts by establishing a metrics program that provides that visibility before making the case for additional investment. Many security groups reach that question with a sense of where the time goes and no record of it. Without that data, executives are left evaluating a largely subjective request. "There's always the basic KPIs that you need to track, like mean time to respond, mean time to detect and false positives and all that," Asher says. "But really you should align those metrics with what your business might need. Align those KPIs with requirements that your business has to meet." Asher extends the same requirement to any provider carrying part of the work. An MSSP or MDR contract moves a share of the operation outside the team, and he wants those numbers collected on the same terms as the internal ones. He lets the program run before drawing anything from it, and he puts the point at which the data becomes useful in months. The wait gives a security leader something to hand a finance team. "Over a course of a couple months, I can typically start seeing data that shows me the performance and where it's at, which is a really good place to start in terms of improvement," he adds. Naming the top risks Operational metrics answer how a team is performing. Asher pairs them with a separate assessment of business risk that runs across the whole company and puts a cost on what a given system failing would do. "What I typically like to do is pretty much maintain a risk register for lack of better terms," says Asher. "Based on that you could go and assess all the risks that the business has, leveraging a certain framework that will identify what are your top 10, top 15, whatever you're looking for, risk for the business." The full register is maintained by Asher's security team, while a ranked shortlist goes to the business. He assembles it from the assessment work before any of it reaches an executive. Remediations, budgets, and proof-of-concept work all trace back to the same document. "The first step really is to be able to show the business, hey, here's the top five risks," Asher explains. "We've assessed it across the business. We've talked to different leadership, we've talked to different business operational teams. Here is what we see." Breach scenarios are the type risk a security team is expected to highlight. Asher widens the category once the conversation reaches leadership . "When people talk about presenting risks to the business, it's not only security risk, it's the risk of not accomplishing something," he notes. "And what are the trade-offs?" Lean teams and priorities Security teams describe themselves as short on people almost universally, and a third of security professionals report their organizations don't have the resources to staff adequately. Two teams carrying the same headcount can deliver very different amounts of work, and the difference rarely shows up in a hiring request. "You can have a lean team as long as you can prioritize the work that has to get done," Asher says. "At some point, if there's 20 things that are priority and that are critical, then you either have to add resources or you have to ask yourself, are each and every single one of these areas the real priority?" Skill gaps, tooling gaps , and capacity limits are real, and Asher's answer is to name them to the business as delivery constraints with options attached. The decision that follows belongs to the business, since the trade-off between security work and everything else the company wants is a business trade-off. "That doesn't mean you'll get the answer you want or the budget you want," Asher explains. "It just means you've done your job as a security leader in letting the business know, here's where we're at, here's what we need." Tuning before buying Asher's audit starts with what the company already owns: the tools already in the stack , the solutions layered on top of them, and the processes connecting both all consume capacity that may not show up as a budget line. "Not everything is about just replacing vendor A, vendor B and being able to do more," says Asher. "A lot of it is have your tools been configured to be able to leverage them at the fullest capacity? Are there any processes that are probably failing that have nothing to do with technology? Do you have the right process for people to submit requests?" A metrics program feeds the audit directly, since the numbers from the first step point at where the hours are going. Asher expects alert triage to account for a large share of them, and the two remedies he names both work on systems the company has already bought. "If you've tracked the metrics then you might find out that a lot of these are false positives," he notes. "Well, you should be going into your SIEM and tuning down the false positives. Does your SIEM offer any capabilities to automate the lower level alerts?" Asher's sequence ends where most budget conversations begin. The steps leading up to it run on tools and processes already in place , so a team can produce the record before anyone approves a dollar. "Do all of that before you start asking for more money and show that you've done all of these things to optimize," Asher concludes. "Show it with numbers. Hey, six months ago we were here. Here's the data that shows six months later, after all of these tweaks that we've made, we're here, we have improved, and to make even more improvement now, we need to have XYZ in place."

## The Security Org Chart Is About To Reorganize Around Outcomes, Not Handoffs
URL: https://www.thesecuritydigest.com/news/agentic-secops-outcome-based-org-chart-rinki-sethi-upwind
Published: 2026-08-26T20:21:00.798Z
Section: Leadership
Summary: Rinki Sethi, Chief Security & Strategy Officer at Upwind Security, on why agentic AI is pushing security teams to organize around outcomes rather than the functional handoffs between SecOps, GRC, and identity.
Full text:
For most of its history, the security organization has run on handoffs. Security operations catches something, documents it, and passes it to governance, risk, and compliance, which logs the risk and routes the control question to whoever owns identity or infrastructure. Each team has its lane, its tooling, and its queue. Agents do not work that way. The lines between functions are blurring because agents can execute workflows across them without the handoffs humans historically required. If the work no longer stops at the seams between teams, it's fair to ask why the team is still built around them. Rinki Sethi is Chief Security & Strategy Officer at Upwind Security and a four-time CISO whose past seats include Twitter, Rubrik, and BILL, with earlier stops at Palo Alto Networks and IBM. She is also a founding partner at Lockstep and has served on the boards of StrongDM, ForgeRock, and Vaultree. When she posted her own sketch of a future security org chart on LinkedIn , it drew a real debate, and she is the first to say the specifics are open. "I don't know for sure what the future org chart is going to look like, but it's going to be different," she says. "Maybe this is one view of what it could look like." The specifics may be open. The direction, she argues, is not. The work stops respecting the seams Sethi walks through a simple version of what she means. A detection fires. If the fix is something an agent can safely handle on its own, it handles it. If there is no control in place to mitigate it, the agent writes the finding straight into a risk register, and a high-severity entry there triggers an alert and pulls a human in to follow up. Trace that path on a traditional org chart and it crosses three teams. In her example, the workflow crosses all three without stopping for a human handoff. "The agents just went and did all the work," she says. "So it starts becoming more outcome-based, rather than security operations doing this task and then handing it over to GRC and then to these other teams." When the connective work between detection, risk, and response collapses into something an agent does in one motion, the case for keeping those as separate stops on an assembly line gets weaker. "This is an opportunity for us to think differently around the outcomes that we're after, and organize around that," she says. The specialized functions don't vanish. Identity and access management is still deep, hard work. The point is narrower and, in a way, larger: the organizing principle moves from who owns which task to which outcome the whole system is accountable for. Instead of organizing primarily around SOC, IAM, GRC and AppSec, teams may increasingly organize around outcomes: reducing exposure, protecting identities, securing production, maintaining resilience and managing enterprise risk. Ten times the reach, same headcount The economics are what make this more than an org-design thought experiment. Security has never scaled the way the threat has. The talent gap is old news, and hiring was never going to close the distance between the work coming in and the people available to do it. Agents change the math on that in a way Sethi finds energizing. "You could 10x your staff by having a team of agents that you're managing, even as an IC," she says. The multiplier applies to capacity. An individual contributor can run a fleet of agents that does what used to take a room of people. That reframes what a security job is. The interesting work stops being manual triage and becomes the design of the agent infrastructure behind it, a build problem more than a queue-clearing one. She has watched a version of this play out before agents entered the picture. Tier-one and tier-two analysis was already heading toward automation, and the career path was already bending away from it. "At Palo Alto Networks, we already saw a career path where we said, we're not going to call them analysts anymore. Everybody's an engineer, and you start getting into threat hunting and the more unique things you want to focus on," she says. As machines absorb more of the repetitive work, people can move up the stack toward threat hunting, engineering, and the incidents that demand judgment. Autonomy still needs accountability A person remains accountable throughout, even if a person isn't approving every individual action. Where the approval sits depends on consequence. Actions that are low-risk and reversible can run autonomously, while irreversible, ambiguous, or regulated decisions route to a human first. Deterministic guarantees still matter, regulation and compliance have not caught up to what the technology can do, and the depth of understanding that lets a defender build the right agent in the first place does not become optional. "You still have to have the understanding of how attacks happen, how the bad guys are thinking, to build the right kind of agent infrastructure," she says. Her non-negotiable is transparency into what an agent did and why. Any tool making consequential decisions has to provide enough evidence, context, and an auditable decision trail for a person to understand and validate what it did. "I can't imagine a world where folks are not going and looking at the reasoning and validating that," she says, at least in the near term. The role shifts over time toward governing which agents may talk to which, and with what permissions, but the instinct to check the machine's work stays put for a while. The CISO becomes a chief trust officer Push the outcome-based idea up the org, and it reshapes the top job too. Sethi sees the CISO role widening into something closer to a chief trust officer, with security increasingly intertwined with privacy and data governance. The accountability becomes how the enterprise establishes and maintains trust across its people, its machines, its data, its AI systems, and the third parties it depends on. As agents become actors in the enterprise with identities, permissions, data access, and delegated authority, the trust boundary expands well beyond traditional cybersecurity. Underneath that role, Sethi expects a new shared-services layer to form. In a lot of engineering organizations, tooling lives in a central platform team rather than being re-bought by every group. She thinks security is heading toward its own version of that, an AI security platform where the tools are managed centrally rather than each function running its own stack. What that layer needs from the people running it is a slightly different profile than the classic specialist. It calls for someone who can invent the next generation of capability and also explain it, translate it, and carry it across the business. Never waste a good incident The reason any of this feels urgent right now is that the threat side is moving at the same speed as the tooling. The autonomous agent that breached Hugging Face in July , chaining real vulnerabilities and running thousands of actions across a single weekend with no human directing the individual steps, is the kind of public, undeniable event that reorders a lot of calendars. Sethi's phone fills with texts from CISOs whose boards and CEOs are suddenly asking what they should be worried about, and where the focus should go, whether that is sharper detections or firmer guardrails around what agents are allowed to do. She treats those moments as leverage. "Never waste a good incident," she says, borrowing the old crisis-management line and pointing it at investment. A high-profile breach is the rare moment when the attack surface stops being abstract to the people holding the budget. She has watched the cycle before, from Home Depot to Heartbleed, where a single loud event unlocked years of cyber spending, and she reads the agentic moment as one worth using to fund a rethink of how teams are built. Her 90-day advice starts with the risk-appetite conversation most companies keep putting off, before buying anything new. Everyone wants agents, and the efficiency gains hold up, so the question is how much risk the business is actually willing to take to get there. "What's your company's appetite for risk? Let's be very open about it," she says. A company sprinting toward AI with a low tolerance for risk has to invest heavily in visibility and controls to match. One moving more cautiously is in a different spot. Either way, the appetite gets named out loud and the executive team and board get aligned on it. An inventory follows, covering more than which agents are running. What each one can access, what actions it can take, who authorized it, which other agents it can talk to, and whether anyone can reconstruct what it did afterward all belong on the same list, and what comes back rarely matches what leadership assumed. Agents doing reversible, low-stakes work can operate with greater autonomy. As access becomes more privileged, actions more consequential, or behavior harder to observe and reverse, human oversight increases. From the org chart down to the ninety-day plan, her answer is the same. "We all own this together," she says. The security leader is not meant to carry the agentic transition alone, and the teams built to handle it, whatever the boxes end up being called, will be organized around the outcomes everyone is accountable for rather than the handoffs that used to define them.

## Manufacturing Security Teams Extend Their Patching Trust Standard To Autonomous Agents
URL: https://www.thesecuritydigest.com/news/ai-agent-trust-accountability-production-uptime-mario-manzano-peco-foods
Published: 2026-08-20T12:33:25.879Z
Section: AI
Summary: Mario Manzano, IT Manager for Infrastructure, Security and Collaboration at Peco Foods, on granting AI agents authority the same way his team earned the right to patch a live plant.
Full text:
AI agents are being permitted to investigate and act inside production environments faster than most organizations have decided what those agents are allowed to break. Security teams in continuous manufacturing have been settling that question for years. A patch applied at the wrong moment stops a production line, so the authority to apply one gets earned and documented before it is used. The tests those teams run on each other turn out to be the same tests an agent has to pass. Mario Manzano is IT Manager for Infrastructure, Security and Collaboration at Peco Foods , a fourth-generation family-owned poultry processor headquartered in Tuscaloosa, Alabama, with about 7,500 employees across roughly 20 facilities. He has worked in IT for nearly 30 years and has spent 13 of them at Peco, where he helped lead a recent architecture overhaul. One team handles both the network that keeps the plants running and the security work that takes it offline, so Manzano answers for the uptime his own patches interrupt. "The same things you need in a team apply to an AI agent. Do you trust the technology? Is there clear accountability, or avoidance of it?" he says. Trust and accountability are what his team spent years building with production, and that record is why the plant lets IT near the floor. Manzano now asks the same two questions before an agent is allowed to make changes on its own. Layers buy time Peco uses the Purdue model , which separates an industrial network into layers and restricts what moves between them. Plant floor equipment sits at the bottom, control systems in the middle, business systems on top. A flaw in one layer cannot travel to the floor on its own, so most patches can wait for the right opening. Finding that opening is easier when a system has a twin. Two devices doing one job means the second can carry traffic while the first is patched, and the line keeps running. Failing that, food plants shut down for cleaning on a regular schedule, and IT does its work during those breaks. When there is no twin and no cleaning break, controls go up around the vulnerable system to limit what can reach it, an approach relied on in settings where equipment cannot be patched . "In the meantime, we have compensating controls in certain cases, or we find a good opportunity to stop, be a surgeon, and get out of there," Manzano says. Borrowed downtime Plants go offline for reasons that have nothing to do with security. Equipment gets replaced, utilities schedule maintenance, and the line goes quiet either way. Production and IT now share those dates in advance so patching can ride along. "They let us know we're going to have a transformer change this weekend, or the power company is going to do some maintenance, and we have no choice but to stop. Is there anything you need to do in that time? We can bring a small generator, we can bring some battery backup, and we can do the pending work that's been sitting on the list," he notes. A shutdown already on the calendar costs production nothing extra to share, and it hands IT hours it would otherwise have to request. Grid power going down does complicate the offer, since the systems IT depends on go down with it, which is why they arrive with portable generators and battery backup. Those hours are worth more than they were. Food and agriculture organizations absorbed 265 ransomware attacks in 2025, and critical manufacturing recorded more incidents than any other sector. One compromised plant disrupts every customer waiting on what it produces. Asking before downloading Employees who need a tool are encouraged to ask for it first, and the security team answers quickly enough that asking stays easier than working around a block. Speed is what makes the policy hold, because a slow answer sends people looking for their own solution. "Trust your users with their job and their responsibilities, but don't entirely trust that they know which tools to pick and what to download," Manzano says. The behavior it addresses shows up in every industry. "It's usually the human component. People try to do the right thing most of the time, and they want to perform. In their haste, they try to get resources, download a tool, get on a website, and that's when things go sideways," he adds. Treating that as a question about tool selection keeps security inside the workflow, which is how other practitioners describe building a shared responsibility for it. Upgrades without downtime Manzano is watching for tools that would remove the scheduling conversation entirely. A network switch shows what that looks like, since it runs constantly and carries email, reporting, and telemetry that keep moving. The device loads the new software next to the version already running. The old one keeps handling traffic while the system tests whether the new one behaves, and only after it passes does the device switch over to it. "You flip the switch, and the switch never stops. It just keeps going. That carries a lot of value for operations that can't stop," Manzano says. That prospect shapes what his team buys today. Peco's overhaul added zero trust access controls, which verify every request even when it comes from inside the network, and aligned the program to the NIST Cybersecurity Framework . Products now get judged on whether they pull data from separate systems into one place. "We select things that bring our platforms together, unify our telemetry, and give us the best data and better reports from an overall perspective," he notes. Agents as teammates Manzano's advice for teams weighing how much to hand an agent comes from a book about people. The Five Dysfunctions of a Team , Patrick Lencioni's 2002 study of why groups underperform, names five ways a team falls apart. It starts with an absence of trust, which leads to people avoiding disagreement, then to decisions nobody commits to, then to nobody holding anybody accountable. Manzano runs software through that list. Most organizations are moving faster than the list allows. Agents get added a few at a time, week over week, and the pace outruns any decision about which ones can act alone or who answers when one gets something wrong. Teams building toward governed agentic operations are settling those questions first. "An agent to augment your team is another team member," he says.

## Employee Fear Gives Attackers Their Biggest Head Start. Psychological Safety Takes It Back.
URL: https://www.thesecuritydigest.com/news/cybersecurity-culture-controls-jothi-dugar-ty-hughes
Published: 2026-08-20T12:33:25.879Z
Section: Industry News
Summary: Cybersecurity strategists Jothi Dugar and Ty Hughes explain how a leader's first reaction to a reported mistake sets the length of the attacker's head start.
Full text:
Security awareness programs are designed to lower the number of employees who fall for a phishing message. Generative AI now supports 15 distinct attack techniques that make those messages hard to distinguish from the real thing. The time between an accidental click and the report is a number a security team can still move. Few programs measure it, and an attacker spends every minute of that delay working deeper into the environment. Employees often set the length of the delay based on the reaction they expect when they walk into a manager's office. Cybersecurity strategists Jothi Dugar and Ty Hughes have spent several years pressing security leaders to count culture among their operational controls. Dugar, known professionally as JoJo D., 'The Chaos Guru,' is a cybersecurity executive, strategist, and international bestselling author with more than 25 years of experience leading and advising across cybersecurity, technology, and organizational transformation. Hughes, known in the field as "The AI Alchemist," is a transformational technologist and a President's Management Council Interagency Rotation Fellow who has spent close to two decades guiding organizations through technical and human complexity. Both treat the delay between a mistake and its disclosure as a security measurement. Their work is part of a broader approach they describe as Cyber Wellness, which treats human and organizational conditions as part of cybersecurity resilience rather than separate from it. "An organization that humiliates people for honest mistakes is actively helping the attackers. It becomes a vulnerability when people fear judgment when they make a mistake, and that causes them to either hesitate, not bring things to the surface, try to conceal their mistakes, or feel like they're alone and try to fix it by themselves, which inadvertently gives an attacker more time to do more damage," says Dugar. Shame never appears in a vulnerability scan, and the work of closing it belongs to the leaders who decide how a disclosure gets received. The room is watching A staff member who walks into an office to admit a click has already made a hard decision under pressure, and the response they get teaches everyone else what that walk will cost them. Hughes counts the exchange as part of the incident response itself. "In those precious few moments, it could be something as simple as resetting an account or segmenting something off," he says. "If your staff are hesitant to bring you bad news, does that turn from minutes to hours, from hours to days, at which time the adversaries advance across your infrastructure?" No detection tool has anything to work with until someone says the words out loud, which means the opening hour of the response belongs to whoever is deciding whether to speak. Hughes has watched leaders answer a disclosure by escalating their own reaction first. The reaction looks like urgency at the time, and the cost lands on the next incident. "That shame in the very beginning is something that can be very impactful, advancing the adversary without the adversary even doing anything additional from a technology perspective, other than letting human nature take its course," Hughes notes. The pattern holds even when the staff involved are competent, motivated, and fully briefed on the policy. Organizations asking why an alert went unread usually land on a queue, a competing priority, and whatever the analyst carried in from home that morning . Dugar puts that workload next to the attacker's day, where one person works a single target and nothing competes for their attention. "Our adversaries out there, they don't necessarily defeat intelligence," she explains. "They exploit what's already there." People reviewing a missed alert already know it turned into an incident, and that makes the warning signs look obvious. "We want to try to take the context away from hindsight masquerading as expertise to a topic of how can we set our employees up for success," Dugar adds. The naughty list Most phishing programs are commissioned as training, and Hughes has seen plenty run with results circulated internally and names attached . The exercise still produces a click rate, and that number still reaches leadership as a security result. "Simulations can help teach recognition and reporting, but they can become really harmful when they surprise, embarrass, or rank or publish who clicked on something," Hughes explains. "A simulation that destroys trust might be a successful phishing campaign, but it's a failed exercise." Hughes looks at the same result sheet differently from the people who commissioned it . Click rates are easy to count, but reporting behavior is more valuable. - Ty Hughes, "The AI Alchemist," Cybersecurity Strategist "I'd rather know when someone clicks on something and why they clicked on it and be able to ascertain, is there something particular about this construct of an email or this construct of a document that really inspired staff to click on it. And if that's the case, then we need to look at it and educate the rest of the staff, educate the broader enterprise," he adds. Time to report, the quality of the first information a team receives, and whether anyone reports at all sit outside the summary most programs hand to leadership. A clean sheet carries its own ambiguity. "There are times where you have phishing campaigns in place and you get back, oh, no one clicked on it," Hughes adds. "Does that mean the organization is getting smarter, or are they just so used to getting up on the phishing naughty list that if this doesn't come from the person I directly report to, we're just not clicking on it?" Dugar has watched the same programs arrive at security teams from several levels above them, already designed and carrying a remediation list. The team enforcing the program had no hand in building it, and employees aim their frustration at whoever delivers the news. "The cyber teams get a report like, 'Oh, here are your repeat clickers, and you now must mandate that they take the training again,'" Dugar notes. "They're more worried about the training non-compliance than people actually learning what to do, what not to do, and what to look out for." Thank you for telling me Hughes has a specific opening line in mind for the manager who receives bad news, and he treats the wording as part of the response procedure . "Imagine the manager who says, 'Thank you for letting me know. Thank you for bringing this to my attention. Now let's take some actions,'" he says. "Immediately we go into, 'All right, what do we know and how do we lessen the impact?'" From there Hughes follows a sequence he has run many times, informing the people who need to know and keeping the escalation proportionate to the size of the event. A second conversation follows once the incident closes, and Hughes uses it to settle the employee back into the team. He keeps a story ready for the occasion. "Let me tell you about the time early in my career where I did something really similar, and let them know that you're not perfect either and that you got through it then, you're going to get through it now," Hughes adds. "But hey, this is what I really appreciated. It was brought to my attention early. It allowed us to go through and take the necessary cyber security related steps." The prevention discussion comes last, once the person across the desk has stopped bracing for it. Dugar identifies a gap in most response plans at exactly this point. Teams drill the technical sequence until it runs without conscious thought, and nobody drills what happens to the employee who triggered the call. She brings a human-centered incident response technique into those first minutes, and it holds the conversation to what can be verified. A misconfiguration exists or it doesn't, and the question of who created it can wait until the environment is stable. "The managers that just jump to blaming someone or a team or anyone or the situation are choosing their own personal emotional satisfaction over the actual containment of the incident," says Dugar. "If we just focus on the raw facts of the matter and being calm and neutral about it, and really focusing on stabilizing the incident but also stabilizing the people involved in the incident, then you're able to get much faster performance." Consequences worth publishing Security leaders hear the psychological safety argument and reach for the obvious objection, which is that a workforce facing no consequences learns nothing. Hughes takes the objection seriously enough to answer it head on. " Psychological safety does not remove consequences for reckless or intentional conduct," Hughes says. "What it really does and what it really means is your staff feel safe enough to bring you the bad news." What changes is the reception an employee gets for arriving early with incomplete information. Most organizations run awareness training once or twice a year and never publish what happens to the person who fails it. Employees end up guessing at their own exposure in the moment they have to decide whether to speak. "If you know the consequences and they're predictable and they're proportionate and they're fair, people know what to expect," explains Dugar. "We're not trying to say don't hold anyone accountable, but we do need to make sure people know ahead of time what the accountability looks like." She also holds that no program can promise a workforce will catch everything, given how convincing the current generation of phishing messages has become. Waiting for a complete picture is the most defensible-sounding way to lose a containment window. A leader who already knows something is developing can absorb bad news an hour later, and a leader who hears it first from another department cannot. "People tend to wait until the last second to confirm all the facts of the matter before they report it to leadership," Dugar says. "Tell your staff that it's okay if you don't know all the facts. Just tell me what you know so far. I'd rather know sooner than later." An organization where employees can report honest mistakes without fear of humiliation or disproportionate punishment hears about problems from the people closest to them, and early information from that person is the most reliable way to shorten a breach. "Leaders who equate psychological safety with weakness, they misunderstand what leadership is and they misunderstand what security is," Hughes concludes.

## CISOs Are Becoming Risk Champions As Recovery Replaces Prevention As The Metric
URL: https://www.thesecuritydigest.com/news/joseph-davis-microsoft-advises-on-cybersecurity-risk-management
Published: 2026-08-20T12:33:25.879Z
Section: Industry News
Summary: Joseph Davis, Chief Security Advisor for Microsoft's U.S. Health & Life Sciences business, makes the case that the next generation of CISOs will be measured on recovery, auditable decisions, and resilience.
Full text:
Enterprise security leaders are still judged on the attacks they stop, and the rules governing what their companies tell investors are about what happens after one lands. A public company that decides a cybersecurity incident is material has four business days to file what happened and what it expects the damage to be. Its annual report has to name who oversees cybersecurity risk and how management handles it. Both answers require a written record of what the company did during an incident and who authorized it. Security programs organized around prevention produce no such record, and a compliance certificate doesn't replace it. Joseph Davis , Chief Security Advisor for Microsoft's U.S. Health & Life Sciences business, was a Microsoft customer before he was a Microsoft employee, and he advises executive teams from that footing. He has consulted across medtech, pharmaceutical, payer, and provider organizations, contributed to FDA guidance on connected medical devices, and speaks at DEF CON's Biohacking Village. Every recommendation he brings to a leadership team carries a cost model weighing the price of paying down a given risk against the price of leaving it in place. "The cybersecurity industry has been obsessed with what we call 'left of bang', right before the incident, stopping the attacks. When you're going up against nation states' offensive measures, they have literally unlimited budget against private and public companies. You're never going to win that war. The war you need to win is the bounce back," says Davis. The budget asymmetry he describes reframes what a security program can promise. A prevention program measures itself against attempts it turned away, and a recovery program measures itself against the hours between an incident and a functioning business. Agents run the exercises Adversary simulation used to require staffing two teams and scheduling them against each other. Banking security teams have started preparing the governance layer before they turn any of it on. "We're seeing agentic autonomous agents being incorporated in XDR and SIEM environments, so that you don't have to have humans playing the role of red team, and you don't have to have humans playing the role of blue team in detection, to see how well your controls have been implemented," says Davis. "Then you have green team agent operators that will help with decision support around how to improve things going forward, and they might even be able to make some of those remediations." Detection coverage across most enterprise deployments already leaves substantial gaps , which raises the cost of an unsupervised test that goes wrong. "That is not to say there's no human in the loop," says Davis. "There has to be a human in the loop before these exercises move forward, or during the exercise, because the last thing you want to do is take down your production systems just to simulate an attack on your enterprise." The same capability runs in the other direction. An attacker working from local hardware leaves no vendor logs , no API records, and no usage telemetry for anyone to subpoena. "It's widely being used as an offensive tool as well," Davis notes. "Individuals can use local models on edge systems that have incredible shared memory resources, NPUs, CPUs and GPUs that all get to share half a terabyte of memory. You can make a local model, or some open source models without guardrails, do whatever you want them to do." Beyond the CISO's desk Security leaders now have to underwrite decisions about manufacturing lines, claims processing, and clinical operations, and the knowledge those decisions require stays with the people running them. Davis treats the concentration of accountability in one office as an organizational design error, and organizations that have corrected it describe the outcome as shared responsibility across the business . "The CISO can't be accountable for everything, nor should they be accountable for everything," he says. "Typically the CISO comes from a technical background, or a military background, or maybe some kind of audit background, but they don't necessarily know how sausage gets made. That's up to the business, and they have to partner with the business in order to make key investments." Distributing accountability requires the operating side to see what an incident costs them specifically. Warnings pitched at threat actors and attack techniques leave plant managers and claims directors with nothing to act on. Davis describes one organization where the message came from the chief executive at an all-hands, built around a badge reader and a plant floor. "The CEO got up on stage and said, tomorrow you might come to the office and you won't be able to get into the building, and the reason is because a cyber criminal attacked our card access system," he recalls. "None of the manufacturing is going to happen, because they can't get into the plant." Putting a number on the outcome turns awareness into a budget line item. A quantified loss figure gives an executive team something to weigh against the cost of the control. Davis uses business vocabulary deliberately when he describes the discipline. "I'm not really talking about security, because I think security is inherent to business risk," he explains. "Business risk essentially needs to be quantified in order for a strategy to be created. Where do I invest? Where do I pay down my risk? How much insurance do I need?" Funding the bounce back Once a company puts a number on its risk, the money can go two ways. Some of it makes an incident less likely, and some of it shortens how long the business stays down once one lands. The second kind of spending is the one enterprises are now pulling together, funding remediation, modernization, and rehearsal as one continuity program under a single owner and a single budget. "If good risk rigor and management is performed prior to any event, the thing that needs to follow up is not only investment in reducing the risk, but investment in resiliency," notes Davis. "Investment in resiliency means you're probably better at getting your business up and running after a disaster than you are in defending against attacks." Operating executives ask how long before they ask what happened. A recovery that requires an engineer to touch every affected machine takes longer the more machines a company owns, and the responders doing that work are the same people already stretched thin . "The problem that chief operating and administrative officers are concerned with is, I don't give a hill of beans what happened," says Davis. "I want to know how much this thing is costing me, how long we're going to be down, how quickly we can recover." Recovery work also has to be documented while it happens. The people doing it sit across operations, legal, communications, finance, and IT, and the order in which they made their decisions is what a regulator reads afterward. Teams that have been through a real incident describe choices made in the first hour that the company is still answering for years later. "If you don't audit how you respond, when the SEC comes in knocking and says you had an incident, did you pay the ransom, who's responsible, who's going to sign this document that says we've been materially affected and it's going to show up in our 10-K?" Davis adds. "All of that needs to be recorded." Risk champions take the job Executive teams make decisions in hours and dollars. A security leader who reports how long the business would be down after an incident, and what those hours cost, is speaking in the same terms as the finance and operations chiefs at the table. A count of blocked attacks says nothing about the systems that can't be patched and would go down anyway. "That's what's going to make or break CISOs," says Davis. "CISOs are going to be risk champions and not necessarily cybersecurity champions. You're a champion of the practice that makes your company more resilient." Davis carries the standard past the security program and into how he assesses a company, treating a recovery answer as a read on operational rigor everywhere else. "How well can they engineer the product, or their claims to patient care, or their claims to have the best retailer of the year?" he concludes. "If they don't have that operational rigor in areas of risk reduction and recovery and resilience, then I'm starting to lose faith in their product."

## Foundational Controls Let Amtrak Secure a Decade-Long Modernization While It Runs
URL: https://www.thesecuritydigest.com/news/ot-modernization-strategy-asset-visibility-arturo-santos-amtrak
Published: 2026-08-20T12:33:25.879Z
Section: Leadership
Summary: Arturo Santos, DT Director of Cybersecurity Architecture at Amtrak, on why critical infrastructure can't wait a decade to replace legacy systems, and the foundational controls that keep them defensible now.
Full text:
Critical infrastructure operators face a problem that has no fast solution: the systems most essential to national function are often decades old, geographically scattered, and impossible to replace on any near-term timeline. Waiting for a complete modernization program before securing them isn't an option, because that program will take ten years or more and the threats are here now. The practical path forward isn't replacement, but protection in place. Asset visibility, network isolation, traffic monitoring, centralized patching, and tightly controlled access give operators a defensible security foundation that manages known risk while old and new OT environments continue running side by side. Arturo Santos is the DT Director of Cybersecurity Architecture at Amtrak, where he leads the architecture behind the railroad's OT modernization and IT/OT convergence. A firm believer in the Purdue model and a longtime cybersecurity practitioner, he serves in the Operational Technology Cybersecurity Coalition and led the creation of the US technical advisory group for IEC 63452 , the emerging international standard for rail cybersecurity. His vantage point spans both the strategic standards work and the day-to-day reality of securing systems that have been running for decades. "One of the key things that we all lack in critical infrastructure and in OT in general is asset visibility," he says. That gap is where Santos starts, because everything else in a protection-in-place strategy depends on first knowing what you actually have. The modernization timeline is measured in decades Amtrak is in the middle of what Santos is careful to call a program rather than a project, because it contains many projects underneath it, all aimed at modernizing the railroad's OT infrastructure. To say the original timeline was optimistic may be an understatement. "It's something we laid out for five years being extremely optimistic, probably unrealistic," Santos shares. "This is going to take us at least 10 years, but we're building the foundation for that." The scale of the change is what makes it slow. Modernizing OT in critical infrastructure is not the incremental work of moving from one version of Windows to the next. It's replacing technology that has run for decades with something categorically different. "A lot of our OT is legacy. We're taking a quantum leap from very old legacy systems, OT devices on our wayside and old fleet that have been running for 20, 30 years or more. The new trains we're deploying are data centers on wheels. Those are super sophisticated systems now in the OT environment." That leap creates value on the operational side. The new fleet from OEMs like Siemens and Alstom generates terabytes of data that Amtrak's maintenance teams can use for predictive maintenance and better planning around costly out-of-service windows. But the security challenge of running 30-year-old wayside devices alongside data centers on wheels doesn't resolve until the decade-long replacement is complete, which means the interim has to be secured on its own terms. Technical debt is permanent, so build for it Santos is candid that the technical debt in transportation will never fully disappear, because the industry is always playing catch-up . "By the time we get to replace obsolete technology, it won't be too long before it's obsolete again. It's almost obsolete by the time we replace it. It's like you're replacing Windows XP with Windows 7 in some cases," he explains. That reality reframes the goal. If the debt is permanent, the answer can't be to eliminate it before securing the environment. The answer is a set of foundational principles that make the environment defensible regardless of how old the underlying devices are. Santos lists the drivers of Amtrak's program as asset identification and visibility, traffic monitoring, secure management, patch management, and isolation of the OT environment. Asset visibility comes first , he says, because it's the most commonly missing piece and the prerequisite for everything else. "If you can manage that, you at least know and have a full inventory of what that is, what the risks are, and have some mitigating controls around it. That's a huge improvement over the typical situation where you don't even know what you have." The foundational controls that hold the line From visibility, the rest of the protection-in-place strategy follows. Santos describes a layered set of controls that let Amtrak manage risk across the mixed environment without waiting for full replacement. The controls center on constraining how traffic and access move through the OT environment. Amtrak built five OT network convergence locations across its wayside and fleet technology to funnel all traffic through defined channels toward IT, consistent with the Purdue model's emphasis on managing north-south flow and minimizing east-west traffic to only what is necessary. "We have a lot of strategies to mitigate unauthorized access to our devices, organized patch management centralized from centralized locations, building one-way communications, and limiting access to the OT environment," Santos says. Testing is the other pillar. Santos emphasizes realistic, environment-wide validation rather than device-by-device checks: "Doing better, more realistic testing and regression testing including the entire environment, not just specific devices. All of those are foundational principles that we're deploying." The payoff of these principles is that they decouple security progress from replacement progress. "Replacing the entire infrastructure is going to take years, but by these principles, we'll be able to make it in a safe and scalable manner." Regulation is now the sharpest driver Predictive maintenance and operational value help justify modernization, but Santos is direct that the most forceful driver of change is increasingly regulatory. The rail industry is now subject to tightening TSA requirements , and regulators are moving from broad mandates to prescriptive demands. "When a regulator comes and tells you, you need to monitor your OT, a lot of times I don't think they realize how big of an ask that is. 'Monitor' is a very broad term, and they're becoming very prescriptive, demanding reporting and management of assets in a very effective way, which is great. The challenge is when they tell you that you need to comply by the end of the year." The compressed compliance timelines are, in his framing, often a bigger transformation driver than the business case, which is one reason he participates in the OT Cybersecurity Coalition . The coalition functions as a think tank that helps shape regulation informed by the operational reality of what monitoring OT at national scale actually requires. The misconceptions that make the work harder Santos closes on the assumptions that complicate the job, and they start inside his own organization. The most persistent is the belief that OT and IT are fundamentally the same, and the related belief that OT is easy to manage. "Even within my organization I have to do a lot of education. People think OT is easy to manage, and it's not. It's very difficult, very diverse. We have thousands of devices with thousands of operating systems running in many different network topologies and environments," he says. The diversity and distribution are also why replacing legacy devices is never as simple as swapping hardware. Amtrak's devices are spread across the entire nation, and many are operated by union workforces that need additional training whenever a device changes. Even a small replacement carries operational and human considerations that a pure technology view misses. The throughline of Santos's approach is pragmatism grounded in sequence. The full modernization will take a decade, the technical debt will never fully clear, and the regulatory clock is running faster than either. What makes the situation manageable is refusing to treat security as something that has to wait for replacement. Know what you have, isolate it, monitor it, control access to it, and patch it from a central point, and the old and new can operate together safely while the long work of modernization continues underneath.

## Security's Most Powerful Tool Is A Culture Of Shared Responsibility
URL: https://www.thesecuritydigest.com/news/cybersecurity-culture-shift-proactive-security-edward-matthews-unifirst
Published: 2026-08-11T09:39:23.022Z
Section: Leadership
Summary: UniFirst Information Security Manager Edward Matthews on why culture beats tooling in cybersecurity and how AI works best as a force multiplier for capable teams.
Full text:
The cybersecurity market sells technology as the answer. Every vendor pitch, every product launch, every RFP frames the next tool as the thing that will finally close the gap. But the organizations that actually shift from reactive to proactive security rarely get there by buying more alone. They change how their people think about security, which is slower, harder, and far more durable than any platform purchase. The biggest differentiator is whether security has become everyone's responsibility or stayed the security team's problem. Edward Matthews is the Information Security Manager at the uniform and workwear services company UniFirst and host of the Matthews Cybercraft podcast . He holds a GIAC certification and a master's degree, and his resume includes security engineering leadership roles at Mass General Brigham and Bright Health, where he oversaw threat and vulnerability management and security operations teams. That background across highly regulated industries shapes his conviction that the hardest part of security maturity is cultural, not technical. "Security is reactive by nature, but the shift to being proactive starts with culture. You can't just do that overnight," he says. That framing puts the emphasis where Matthews believes it belongs, on the slow work of changing how an organization relates to security rather than on the fast fix of a new acquisition. Reactive by nature, proactive by design Security begins as a reactive discipline because threats arrive on their own schedule. Something happens, the team responds, and the cycle repeats. Becoming proactive means getting ahead of that cycle and anticipating risk rather than answering it, and that shift does not come from a product. "You can buy the best tools in the world, but if the culture isn't there, you're still going to be reactive. The tools help, but they don't change the mindset on their own," Matthews asserts. He's direct that the cultural change is the harder project precisely because it cannot be purchased or rushed. It requires sustained effort to move an organization from treating security as the security team's job to treating it as a shared responsibility. The transition happens person by person and team by team, over a timeline measured in years rather than quarters. The payoff is that a proactive culture compounds. Once security thinking is embedded across functions, every employee becomes a sensor and a first line of defense, which extends the security team's reach far beyond what its headcount alone could cover. Security as everyone's responsibility The core of the cultural shift is distributing ownership. When security lives only inside the security team, the rest of the organization has no reason to think about it, and the team spends its time chasing problems that better habits elsewhere would have prevented. When security becomes everyone's responsibility, the dynamic changes. "The goal is to get to a place where people across the organization are thinking about security in their day-to-day work. Not because we're forcing them to, but because it's part of how they operate," Matthews says. Reaching that state depends on two things he emphasizes repeatedly: leadership buy-in and cross-functional collaboration. Without leadership visibly backing security as a priority, the message that it matters never fully lands because employees take their cues from what leadership actually reinforces. And without collaboration across departments, security remains siloed, unable to influence the workflows where risk actually originates. "You need leadership bought in, because that's what gives you the ability to work across teams. If the top isn't behind it, you're constantly fighting for attention and resources," Matthews notes. The collaboration piece matters because the security team doesn't own most of the systems, processes, or decisions where vulnerabilities enter. Engineering, operations, HR, and every other function make choices that affect the organization's risk posture. Security's job is to influence those choices, which is only possible through relationships built across functional lines. Metrics that show progress over time Cultural change is notoriously hard to measure, which makes it hard to fund and hard to sustain. Matthews addresses that by focusing on metrics that demonstrate progress over time rather than snapshots that capture a single moment. "You have to show progress. Leadership wants to see that what you're doing is working, and that means metrics that trend in the right direction over time, not just a number at one point." The distinction between trend and snapshot is important. A single vulnerability count or a one-time phishing test result says little about whether the organization is getting more secure . A metric tracked consistently over months and years shows whether the culture and the program are actually maturing. That trend line is what justifies continued investment and what proves the slow cultural work is paying off. Matthews frames metrics as the connective tissue between the security team's daily work and leadership's confidence in it. The right measures translate security activity into a story leadership can follow, which in turn sustains the buy-in that makes the cultural change possible. The relationship is reciprocal: leadership support enables the work, and metrics demonstrating progress sustain the leadership support. AI as a force multiplier On AI, Matthews is optimistic but measured, and his framing is consistent with his people-first thesis. AI matters not because it replaces the security team, but because it removes the repetitive work that consumes the team's time, freeing them to focus on the strategic priorities that actually require human judgment. " AI is going to be huge , but as a force multiplier. It takes the repetitive, time-consuming work off your plate so your people can focus on the things that actually need a human." The value is in reallocating human attention. Security teams spend enormous effort on repetitive tasks: triaging alerts, correlating data, handling routine analysis. AI can absorb much of that load, which doesn't shrink the team's importance but redirects it toward the higher-order work of anticipating threats, improving processes, and building the proactive posture that culture makes possible. That framing keeps AI in its proper place within Matthews's argument. It's a tool that amplifies a capable, well-organized team without substituting for the cultural foundation, and an organization that deploys AI without doing the cultural work will simply automate its reactive posture rather than becoming proactive. The technology accelerates whatever is already there, which is why the people and culture have to come first.

## Five Years After DOL Guidance, Some Benefit Plans Still Have No Security Program
URL: https://www.thesecuritydigest.com/news/dol-cybersecurity-guidance-benefit-plans-julie-tracy-withum
Published: 2026-08-11T09:39:23.022Z
Section: Industry News
Summary: Julie Tracy, principal at Withum's cybersecurity advisory practice, explains why Taft-Hartley funds that outsource every operation to third parties keep treating vendor assessment as one-and-done, and why the long voluntary stretch on the DOL's guidance won't end gently.
Full text:
The Department of Labor published its cybersecurity expectations for benefit plans in April 2021, then confirmed in a 2024 release that they cover every ERISA plan, health and welfare included. Five years on, many of the funds holding workers' pensions and medical benefits are still starting from zero. And they hand every operational function to outside vendors. Julie Tracy is a principal in the cybersecurity advisory practice at Withum , an advisory, tax, and accounting firm whose cyber team handles assessments, pen testing, and third-party risk for benefit funds. She spent twelve years as CISO of an Indiana community bank under full FDIC supervision, holds CISSP and CCSP certifications, and teaches trustees through the International Foundation of Employee Benefit Plans . Since moving from banking to Taft-Hartley work in 2022, the gap between those worlds keeps surprising her. "I'm still running into Taft-Hartley plans, health and welfare plans, that don't have any kind of cybersecurity program in place and have never assessed their vendors," Tracy says. No grace period after the grace period Banking taught her what enforced looks like. "My first day on the job was literally sitting across from an FDIC examiner, asking me about the information security program at the bank," she says. It shapes how she reads the current stretch of soft enforcement, and she labels the prediction as her own. "This is your opportunity to get the program you should have in place and implemented. Because there's been such a large voluntary compliance period, there will be no grace period once it becomes effective. That's my opinion; I haven't heard that from the DOL, but I often see it in banking," Tracy says. "I've had an exam thirty days after a regulation became effective. I was expected to have that control in place." Periodic means annual The guidance reads closer to baseline practice than to a stringent rulebook, and the sticking point is cadence, not content. "The language in the guidance around vendor assessments says periodic. There was a question asked of the DOL at a conference in 2024, and the DOL emphatically said periodic is annual," she says. Trustees hear something else. "I'm still running into trustees who think, if I just do this once, I've checked the box, I'm done." Some hear a sales pitch. "Some folks say, well, it's just a way for you guys to make money," Tracy says. Her answer comes from the exam room. "In banking, if we did not assess our vendors every year, that was 100% a finding." The exposure justifies the cadence. Most funds have no staff running anything. "They're relying 100% on third parties for every aspect of the day-to-day operations of the plan. The risk associated with that is enormous, and you have to have your hands around all of your vendors." Only two items on the DOL's list must leave the building: the independent audit of program effectiveness and external pen testing, but few funds can execute the rest in-house. Written but not executed Funds that do have programs often have them on paper only. When Withum drafts policies, Tracy sets one rule. "If you can't execute this, we need to not put it in policy. It's worse to have it in policy and not be doing it than to not have it in policy." A documented control nobody runs becomes evidence against the fund after a breach , where the policy-practice gap reads as knowing neglect. MFA is her recurring example. "We see a lot of instances where it's turned on, but the end user has the ability to say, I don't want to use MFA," she says. Pen testing surfaces the difference fast. "Users are going to take the path of least resistance every single time." Where a fund with nothing starts Her on-ramp is deliberately small. A written information security program comes first, the playbook covering the policies the DOL's first item expects. Then a controls walkthrough with the fund's IT provider on the call, where eight-character passwords and daily admin-account use get their reckoning. One client that started with vulnerability scanning four years ago now runs full internal and external pen testing and is adding vendor assessments. "We love seeing how much harder the pen testers have to work to find things," Tracy says. The newest item in her starter kit predates any DOL requirement. "Even if you're not using AI, you should have a policy that states we are not using it. If you don't have a policy that says you can't use it, I'll guarantee you employees are." She expects the guidance to absorb AI eventually, and the threat side won't wait for the paperwork. "This is not a one-and-done thing. Ask your vendors how they're using AI, and how they're using it without participant data," concludes Tracy. "If you haven't started on your cybersecurity journey, start with putting putting policies into place and begin the assessment process of your vendors."

## 'Certified and Still Breached' Is Forcing CISOs To Look Beyond A Badge
URL: https://www.thesecuritydigest.com/news/risk-first-compliance-shields-shock-absorbers-adedayo-adetoye-glg
Published: 2026-08-11T09:39:23.022Z
Section: AI
Summary: Adedayo Adetoye, CISO at GLG, makes the case for running security as dollar-denominated risk management, where compliance builds useful organizational muscle but never substitutes for knowing what an attack would actually cost the business.
Full text:
The views and opinions expressed are those of Dr. Adedayo Adetoye and do not represent the official policy or position of any organization. Breach reports keep featuring companies with current certifications. SOC 2 complete, ISO 27001 renewed, auditors satisfied, while the attacker breaches anyway. The pattern says less about compliance than about what the badge was never designed to measure – and as AI shortens the distance between a vulnerability being found and being used, the price of confusing the two keeps climbing. Dr. Adedayo Adetoye is the Chief Information Security Officer at GLG , the world's leading platform for trusted human expertise. He holds a PhD in computer science and did postdoctoral research on critical infrastructure resilience at Oxford and Warwick. He spent nearly a decade at Mimecast, finishing as director of security architecture and engineering. A certified CISO and Open FAIR risk professional, his through line is that risk came first in his career and compliance was a stop along the way. "Certifications are useful, but they're not sufficient. So many organizations that have been breached are actually compliant," Adetoye says. "They have certifications all over the place, yet they still got breached." What certifications actually buy None of that makes him dismissive of the badge. In regulated markets, it's the ticket to doing business at all, and elsewhere it reassures customers during the sales motion. The deeper value, however, is internal. "The biggest value compliance brings to the table is the permission structure. We need to do this to be certified. Over time, that builds muscle memory within the organization," he says. Access reviews and pen test evidence become routine because certification demands them, and the executive alignment does real work. "Because you have that alignment, it's easier to get those requests serviced. The business wants the certification badge." The appetite has to land somewhere The job itself is different. "As a CISO, your job is to manage the business risk within appetite. Being compliant to a given standard may be part of that job, but it's not your primary job," Adetoye says. "A CISO that builds their whole strategy around gaining badges is not doing a proper job for their company." Managing within appetite means forcing the appetite to mean something. Every business claims it can't afford for anything to go wrong. "You've got to find where that risk appetite really lands. What does that mean in dollar terms?" The conversation with the board starts from the high-value assets – whether that's intellectual property, service availability, or client data – and works backward to the scenarios that threaten them. Shields and shock absorbers Adetoye sorts the resulting controls into two kinds. "Shields are controls that prevent attacks from materializing. Shock absorbers are the controls that reduce the impact when they do materialize," he says. "In a car you have brakes. They prevent you from having a crash, but there's no guarantee you won't have one. That's why you have airbags." Run ransomware through the frame and the roles separate cleanly. MFA on data processing systems and EDR on endpoints are shields. Tested backups are the shock absorber, the thing that turns a detonation into a restore instead of a catastrophe. Three surfaces where AI goes wrong AI pressures both columns at once. Attackers needed skill to weaponize a vulnerability, and now pointing a model at a platform lowers that bar, compressing the discovery-to-exploit timeline. His response is symmetrical. "You fight AI with AI, to find the vulnerabilities myself, before the bad guys do." On the risk side, he maps three work surfaces. The browser, where employees can feed business data into unsanctioned chatbots no matter which ones are approved. The endpoint, where coding agents inherit whatever their operator can touch. "The agent is working in the context of those privileges, and hallucination or prompt injection could lead to the agent acting with the same permissions as the privileged engineer, causing serious damage." And the product itself – where AI features in a SaaS platform can be steered into behavior nobody designed. The same triage capability, pointed inward, relieves SOC teams drowning in alerts before burnout does the attackers' work for them. What he won't do is stand in the doorway. Engineers arrive already using agents at home and push to bring them to work. "A CISO can't afford to be the innovation killer. The smart move is to say yes, we understand, but let's put guardrails in. Let's work together," Adetoye says. Even that is provisional. "The field is evolving so fast that the guardrails you provide today are obsolete by tomorrow. You've got to evolve as well."

## Enterprises Rebuild Vulnerability Remediation as a Business Continuity Program
URL: https://www.thesecuritydigest.com/news/vulnerability-remediation-business-continuity-chris-thatcher-epam
Published: 2026-08-11T09:39:23.022Z
Section: Observability
Summary: Chris Thatcher, Director of Cyber Security Solutions at EPAM Systems, explains why AI collapsing the window between vulnerability discovery and exploitation forces enterprises to fund remediation, legacy modernization, and incident rehearsal as one board-level program.
Full text:
CDK Global went down and thousands of car dealerships wrote up sales by hand for weeks. The Change Healthcare breach left pharmacies unable to process claims . MGM's casino outage showed up in the next quarter's earnings . None of the three involved AI. Two came down to stolen credentials, the third to a convincing phone call, and basic identity validation would have stopped all of them. That was the easy version. Chris Thatcher is Director of Cyber Security Solutions at EPAM Systems , a digital engineering and consulting firm that builds and modernizes software for large enterprises. He's spent more than thirty years in business and sales leadership, the last twenty-five in security and compliance, and holds a CISSP. He recently published a book on the translation gap between technical and business audiences, the same gap that decides whether remediation work gets funded. "Close to 25% of zero-days are being exploited within the first 24 hours, while the mean time to remediate in the enterprise is still five months," Thatcher says. "Every day that we know about a problem and do nothing is self-inflicted exposure." The backlog stopped being a safe place to put things For years, the model was simple. Fix what's marked critical or high, let everything else pile up. One client is carrying backlog items twenty years old. That no longer holds. "People have demonstrated with AI they can stitch together these low and medium severity vulnerabilities into high severity and criticals," he says. "That backlog we've been shoving into a closet for twenty years is no longer a safe space." The discovery side has gotten cheap , and it doesn't require anyone's flagship model. In his experience, it comes down to coordinating ordinary models through a harness, which puts attacker-side speed within reach of more people than the headlines suggest. Clearing tens of thousands of findings is not a job for a staffed team. Thatcher sorts the work into three tiers, automating what can be automated, using AI to triage the middle band before handing it to people for final patching, and reserving people for the most sensitive applications. "It's not a security problem. It's an engineering solution to a business continuity problem." Legacy systems AI can read fluently The second exposure is the estate nobody wanted to touch. Financial systems, inventory systems, and SCADA environments in power and energy run on platforms that lost support years ago, in languages whose authors have retired. "Nobody's writing the code," Thatcher says. "AI can read and write it fluently." Modern energy operators lost their air gap along the way, since those systems now have to reach the internet and cloud to function. "It was never affordable before AI, and it wasn't vulnerable before AI. Now it's both affordable to fix and vulnerable to those who don't fix it." Catching defects before they promote Cleaning up the past only buys time. "As long as we're developing code, we're going to be introducing vulnerabilities," Thatcher says. His answer puts agentic monitoring across code repositories, triaging and patching in real time. "If you can get agentic AI into your development pipeline, you can reduce vulnerabilities that are actually promoted into production ." Getting it funded The failure Thatcher sees most often is financial, not technical. Teams try to fund this from existing budget, and the scope is too wide for that to work. One North American client brought in two Big Four firms and got back three-hundred-page reports cataloging every exposure and recommending nothing. "The easy part is shining a light on the problem. The hard part is putting the engineering processes in place to actually do the fixing." Thatcher's team paired that assessment with a plan, working across the CISO, CIO, and CTO. The board approved it without asking the price and asked when work could start. A European client with more than 10,000 engineers put 20% of them on remediation almost immediately. That requires authority the middle of the organization doesn't have. "The thing that makes it most difficult is silos and tribalism," Thatcher says. "If you come at it from the bottom up, you're herding cats. You're given a task without the authority to execute." The programs making progress treat this as one coordinated effort rather than a set of projects. None of it matters if the response plan is fiction. Thatcher started as an auditor, opening binders five years out of date, listing contacts who'd left and systems that no longer existed. What companies need is a clear inventory of business-critical applications, an honest read on the likeliest incidents, and a plan they've actually run. "They need to rehearse that," he says. "Rehearse it in a way that makes it real and makes it hurt , makes people uncomfortable enough that they make changes, and then they do it again." The alternative is figuring it out live , which is how weeks of downtime start.

## Enterprise AI Is The Biggest Insider Threat in IT History And It Only Wants To Help
URL: https://www.thesecuritydigest.com/news/ai-insider-threat-jesse-adams
Published: 2026-08-02T18:06:54.718Z
Section: Observability
Summary: Jesse Adams III, Senior Principal Enterprise Security Architect, warns that AI's eagerness to please makes it the biggest insider threat IT has ever onboarded
Full text:
Every enterprise AI plan promises faster delivery, and nearly every one assumes the helpful new workforce can be trusted. One security architect looks at those agents, with their own identities, entitlements, and bottomless desire to please, and sees a historic insider threat. Jesse Adams III is a Senior Principal Enterprise Security Architect. A Zero Trust strategist who started out operating naval nuclear reactors and later served as chief architect of the Navy Marine Corps Intranet, Adams now guards some of the country's most regulated healthcare data. "AI innocently represents the single biggest insider threat in the history of IT. It just wants to be helpful. If a user asks AI to do something it shouldn't, perhaps through a prompt injection attack, AI might not realize the error. It's going to try its best to fulfill the user's wishes," says Adams. The naive child at the command line The eagerness is the exploit. Prompt injection works because a model processes a malicious instruction like any other request, a pattern already moving sensitive data out of enterprises as the agentic threat map widens. Adams frames it with an employee comparison. "Think of the average customer service representative. They're operating a portal with a GUI, and the GUI limits what they can and cannot do. The AI operates without the GUI. It's at the command line with dynamic, versatile entitlements. It can elevate its privileges and renegotiate its role with the other agents making those decisions." Agents trust too much by default , so a naive child is his working model. "Somebody clever enough can plant the seed of malice, get it to mistakenly divulge information it shouldn't have, and use it as an exploit." The camel's nose under the tent The procedural erosion worries him as much. Checkpoints align business requirements, technical solutions, and outcomes, and the hurry up mentality reads them as friction. "There should be review boards, checkpoints where you stop and ensure proper alignment. More and more, that's going to become a spectacular inconvenience." The replacement is easy to build, each evaluator arriving with an identity of its own . "Act as the chief technology officer, act as the chief architect, be my strongest supporter, be my worst adversary. You can synthetically create the same adversarial review board construct you would have with humans." What follows depends on how much risk leaders can see . "The camel's nose under the tent will happen when they create some threshold," Adams says. "If the risk is low enough, if the cost of a mistake is within the risk appetite, let the AI team evaluate it. Once you reach a certain threshold, then we'll get humans involved. There'll be some successes and some stubbing of toes." Show me the receipts His countermeasure treats security as load-bearing in AI adoption , reference architecture first. He built one against the AI risk management framework, the OWASP Top 10 for large language models, and emerging ISO guidance, using AI to speed the research. "You might call it fox watching the henhouse. I just think of it as accelerating my research. But you've got to tell it, do not make this up. Show me the receipts. Cite all of your references. And it does, as long as you establish those guardrails." The skepticism has to hold up at runtime, inside a layered agentic defense . "You start with your AI gateways. Make sure you're blocking any transfer of sensitive information outside your boundaries," he says. "Have the restrictions built in, and understand that least privilege RBAC-based access controls are not going to work anymore. You're going to have to figure something else out." Sticker shock and the scoreboard Measurement keeps the enthusiasm honest. "You've got this team going gung ho, charging downhill into AI, and then the first bill comes in. A quarter-million-dollar bill is an eye-opener, and it's even bigger when it's 10 or 20 times that. Enthusiasm gets curbed when the expense of AI starts to outweigh the perceived savings." Past token costs, he tracks delivery time, customer satisfaction, and whether consolidation trims licensing spend, and calls mass layoffs in favor of agents shortsighted. For the most sensitive workloads, fully homomorphic encryption keeps a prompt encrypted even while the model computes on it, at heavy cost in speed and tokens. "All but the most sensitive should probably not use that solution." With attacks breaking out in under a minute , matching the offense machine for machine is a losing bet. "The bad actors are using AI as well. You're not going to win an AI arms race if you're the defender. You simply cannot. The best bet you have is to revise your security posture and perfect it."

## Speeding Up Security Work Could Undermine the Next Generation of Defenders
URL: https://www.thesecuritydigest.com/news/ai-workforce-erosion-security-poverty-line-helen-patton-cisco
Published: 2026-08-02T18:06:54.718Z
Section: Leadership
Summary: Helen Patton, Cybersecurity Executive Advisor at Cisco, argues that measuring AI by speed alone starves the security talent pipeline and does little for the organizations stuck below the security poverty line.
Full text:
Somewhere right now, a junior analyst is watching an AI close out the tickets they were hired to learn on. Leadership calls it productivity, and the dashboard agrees. What the dashboard doesn't show is where the next generation of defenders comes from once the learning work is gone. Helen Patton is a Cybersecurity Executive Advisor at one of the world’s largest networking and enterprise technology companies, a former CISO of the company's security business group, and before that, she served as CISO at The Ohio State University for seven years. Two decades across banking, higher education, and technology made her a persistent critic of the industry's favorite workforce statistics, including the hundreds of thousands of open jobs narrative. "There are jobs available, but they're not entry level jobs. They're usually asking for somewhere between 8 and 15 years of security experience." "Sometimes you need to lift something, so you get a robot to do the lifting. Sometimes you go to the gym because you need to exercise the muscles so that you can continue to lift. Just because AI can do something may not mean that we want AI to do it," Patton says. Repetition is the curriculum The gym framing borrows from an argument circulating in security circles , and Patton reaches for it because leadership keeps optimizing the wrong metric. "We've got leadership saying hurry up and use AI, and we're going to measure success in terms of how much work can be done and how quickly. In pushing for that, they're overlooking workforce development, pipeline, and career progression," she says. Entry-level roles absorb most AI-related cuts, younger workers know it , and the restructuring reshaping SOC teams lands on exactly the seats where careers begin. Patton sees the pendulum swinging back. "In doing that repetitive entry level work, that's where people learn what the job is, what the implications are, where the edge cases are. We need to be intentional about building these skills in the people we're hiring as part of our AI strategy, not in spite of it." AI plays the generalist Security inverts how other professions grow. Doctors and lawyers start general and specialize late. Technologists go deep early, in identity or vulnerability management or GRC, then broaden into architecture. AI enters that ladder from the top. "If we do AI right, and I'm not convinced we're doing AI right yet, it will help senior people do systems integration better, but it won't necessarily help junior people do specialization that much better." The asymmetry cuts against the layoff logic: the deep expert gets more valuable as general work gets absorbed. "AI at its core is about generalized knowledge, not specialized knowledge," Patton says. "AI may augment the specialist, but it's not going to do the specialist work directly." Below the security poverty line The augmentation pitch collides with the average American security team, fewer than 10 people by her count. Vendors selling the AI-native SOC rarely price in who reviews the output. "Even if you stick a whole bunch of AI agents next to a human in a small security team, those agents will still have outputs, and someone is still going to have to oversee those outputs. Under-resourced security teams don't have time for that." Unmanaged, it becomes one more queue that gets abandoned . Most organizations sit below the security poverty line, Wendy Nather's term for teams lacking the money, political support, and knowledge to defend themselves, and Patton is blunt about it. "More organizations are below the security poverty line than above it." When frontier models began finding vulnerability chains nobody had surfaced, everyone was told to get their own AI to find and patch first. "The small companies aren't going to do that. Even if they've got that one geeky guy on the security team who can program his own agent, it's still not going to happen." Her nearer-term bet runs through managed providers . "I can see managed security service providers introducing AI into a smaller organization, getting the processes working, getting the AI tuned up, and then transferring that knowledge into the organization." Security as a common good None of it substitutes for the discipline underneath. Business processes stretch across third parties with their own third parties, a supply mesh where change coordination matters more than another automation layer and where security outcomes still hinge on people outside the security team . "We call it foundational, and no one does it very well," Patton says. The fix she lands on is economic. "Until we recognize that security is a common good, and I mean that in an economic sense, a common good that requires community investment and community support, organizations below the poverty line are still going to be below the poverty line." AI, she thinks, could finally make pooled defense practical. "AI can do stuff at community scale that benefits everybody. That may be the path we need to go. Nobody wants to do that unless there's money in it, so we may have economic disincentives to help ourselves."

## Security Tool Sprawl Is Turning Blue Team Defenders Into Modern 'Script Kiddies'
URL: https://www.thesecuritydigest.com/news/blue-team-script-kiddies-tool-sprawl-benjamin-glover-cumulus-media
Published: 2026-07-27T21:29:07.221Z
Section: Leadership
Summary: Benjamin Glover, Manager of Information Security, argues that defenders who stack tools they can't explain are losing the judgment real resilience requires, and draws a hard line on how far AI should reach into the SOC.
Full text:
Every new threat ships with a matching platform, and every platform adds another portal to check. Under the stack, the ability to explain how any of it works erodes. One blue team leader argues defenders are trading away the judgment that real resilience runs on. Benjamin Glover is Manager of Information Security at a major North American media company. A CISSP who worked up from security analyst to running the program, he sees the platform obsession from the defender's seat, where it looks like liability dressed as maturity. "In the early 90s, a script kiddie was a person who didn't know how to hack but knew how to run scripts. I'm seeing a lot of security professionals turning into modern-day script kiddies, but instead of scripts, it's tools. They don't understand the back end of what the tool is doing, and that's really hurting our profession," Glover says. Where the risk meets reality His answer starts before the purchase order. "The first thing I look for in any tool is whether it's going to create another management plane," he says. "Is this another portal my team has to check every day? If so, that rules it out automatically." Whatever clears the tool sprawl filter still has to fit the attack it claims to stop. "You have to understand the workflow of the risk before you can create an interceptor to it. Risk is a missile aimed at your organization. You have to know where in the arc to put your interceptor to knock it out of the air." Automated scoring fails the same test. "I've seen a ton of these AI vulnerability management platforms. It's a 9.8, okay, cool. But I've got to have 50 different things happen in my environment, and the attacker has to control 49 of them already. If they have those 49, the 50th doesn't really matter." Severity without context is noise, which is why risk-based prioritization keeps displacing raw scores. Hit it off at the gate The same discipline applies before AI enters the environment: policy first, change management behind it, and a real route for employees to request new tools. "If you think AI is going to enter your realm, create a comprehensive policy for usage of those applications. Hit it off at the gate instead of letting users take the lead on what's allowed in," Glover says. Skip that release valve and the outcome is guaranteed. "They're going to bypass your systems no matter what kind of controls you have in place." He points past AI too, from zero trust checks on every request to post-quantum cryptography ahead of harvest now, decrypt later campaigns. Never give the robot the knife On agentic security , Glover splits the SOC workflow cleanly. Enrichment is automation wherever it originates. "It doesn't matter if the LLM is pulling from Shodan or my analyst is pulling from Shodan. Shodan has that same information. URLScan has it. Joe Sandbox has it." Remediation is a different matter. "I am not giving a robot a knife. Type three different questions into an LLM and you're going to get three different answers every time. You can't have three different answers in a security incident. There needs to be one answer." The gap widens with everything an agent can't see. "Maybe I got a call 30 minutes ago and this user is actually in Panama, and the AI thinks it's a malicious attacker. I don't want it disabling their account. Or engineering is testing a new script. I don't want that computer isolated off the network." The pattern holds across AI in the SOC, from the last mile between recommendation and action to the hardening case for keeping irreversible remediation under human control. Standards bodies are drafting trust frameworks for autonomous agents. Apprenticing the next generation His biggest worry sits a decade out. Vendors building the AI-native SOC concede analysts aren't going anywhere, yet the restructuring reshaping security teams keeps trading this quarter's savings for the profession's bench. "If you don't have any Tier One people, you're never going to get Tier Two or Tier Three people. What's going to happen in 10 or 15 years when you're not apprenticing the next generation?" Glover keeps a reminder against overestimating the technology, a tongue-in-cheek paper that builds a neural network inside Age of Empires II to puncture the habit of seeing humanity in machines. "AI is able to translate. That's all it's able to do. It will look at things humans have done, but it will not do things humans have not thought of doing," he says. "As long as that light of human creativity shines, AI is never going to take over."

## Solving Alert Fatigue Requires Shared Ownership, Defined Language, And Risk-Based Prioritization
URL: https://www.thesecuritydigest.com/news/aditya-bhise-avaya-risk-based-security-prioritization
Published: 2026-07-26T13:09:02.799Z
Section: Industry News
Summary: Aditya Bhise, Senior Manager of Information Security at Avaya, walks through why solving alert overload starts with governance, shared ownership, and organization-specific interpretation.
Full text:
Security teams are drowning in alerts, and the industry's default response has been to buy more tools to sort through them. Rising AI threats and shortened cyber fix windows have accelerated the spending, but the alert fatigue problem hasn't resolved. The gap between the number of alerts a SOC receives and the number a SOC can meaningfully action traces back to interpretation, not technology. Teams cannot determine which alerts represent actual risk without knowing the specifics of their own environment. Aditya Bhise , Senior Manager of Information Security at Avaya , brings over 12 years of enterprise cybersecurity experience to the disconnect between raw security data and the intelligence security teams can actually act on. Managing enterprise alert volumes requires moving away from generic technical severity as the primary prioritization framework, and toward organization-level risk framing: the specific assets, exposure, financial impact, and business priorities of the organization receiving each alert. "The cybersecurity industry doesn't have a shortage of security tools or data. It mostly has a shortage of context and the operational capacity," says Bhise. Much of the alert volume comes from disconnected tools each watching a different slice of the environment. Cloud posture tools, internal monitoring platforms, and external perimeter scanners fire alerts independently, and the same underlying issue frequently gets flagged multiple times. As executives plan new uses for AI to filter that noise, Bhise sees automation working best as a first-pass contextual layer bounded by strict, organization-specific parameters . Defining the shared risk language Every business unit handling company data carries responsibility for reducing risk. What often derails those conversations is that leadership, business, and technical teams interpret the same risk report differently. A shared enterprise-wide standard for how reports get read and escalated is where alert triage starts to align with broader SOC strategy and risk assessment. "The language of the reading needs to be defined," Bhise advises. "Once that language is defined, then I feel that there wouldn't be any lack of information or missed information, or any false negatives or false positives within all the different hierarchies, and everyone reads out the same set of information in the same way." The prioritization problem sitting underneath the language problem is that generic scoring systems fail to capture the specifics that determine whether a given alert actually represents risk. CVSS metrics weren't designed to account for the internal mitigating controls, virtual patching, or environmental factors that materially change exploitability inside a given organization. A Heartbleed vulnerability detected inside an internet-facing production environment reads very differently from the same vulnerability inside an isolated test environment. "In my view, CVSS alone shouldn't be considered as the only factor," says Bhise. "I think vulnerability management overall should be risk based and CVSS alone isn't enough to go in and do the remediation or the prioritization because some organizations may be doing virtual patching." The risk-based prioritization mandate The AI vulnerability discovery and triage bottleneck is ultimately a cultural problem. Even the most sophisticated detection stack loses effectiveness quickly when only the security team feels responsible for the outcomes it produces. Bhise views shared accountability across finance, legal, sales, marketing, and IT as the operational condition for making security a true organizational function that everyone contributes to. "Every single person who handles organization data indirectly or directly is responsible for security because a user's negligence could result in huge consequences," he notes. The stakes on that cultural point are higher than the language often suggests. A single exposure can neutralize the technical investment sitting behind it, which is why security awareness is now treated as a leadership-level operating requirement across mature SecOps automation programs . "One single exploit or one single accidental click could lead to quite intense repercussions," says Bhise. "If that happens, then no matter how many security tools are deployed, that really wouldn't matter because that backdoor has already been opened by someone clicking something that they shouldn't have clicked in the first place." The practical mandate for security leaders is to reduce the risks that would meaningfully damage the organization. Eliminating every risk in a threat landscape adding new exposures continuously isn't a realistic goal, but the alert fatigue problem starts to resolve when leadership accepts risk-based prioritization as the operating standard. "There will always be new risks arising every day, every minute, every second as we speak. It's about reducing the risk that matters the most to every organization," Bhise concludes. "If that can be attained, then there will be quite a lot of noise that can be suppressed, allowing us to focus on things that actually matter the most." The views and opinions expressed are those of Aditya Bhise and do not represent the official policy or position of any organization.

## When The Systems Worth Protecting Are Unpatchable, Architecture Has To Carry The Defense
URL: https://www.thesecuritydigest.com/news/ai-exposes-ot-security-patch-limitations-todd-wade
Published: 2026-07-26T13:09:02.799Z
Section: AI
Summary: Veteran CISO Todd Wade on why OT defense must start with architecture, segmentation, and asset visibility as AI compresses attack timelines to minutes.
Full text:
AI is exposing the limits of a patch first strategy. Patch-first defense works when the systems worth protecting can actually be patched. In OT environments, they often cannot. The HVAC controllers, medical devices, manufacturing lines, and legacy firmware running critical infrastructure frequently have no central update mechanism, no vendor still in business, and no maintenance window short enough to matter once AI compresses attack timelines from overnight to minutes. The organizations that survive the coming wave of AI-driven OT threats will be the ones that built their security around architecture, defense in depth, identity, asset visibility, segmentation, and blast-radius control, rather than around remediation promises they were never able to keep. Todd Wade is a veteran Chief Information Security Officer and author who has led security for fintech, technology, and private equity organizations. He recently served as interim CISO for a hyperscale data center group with a heavy OT footprint. Wade's work focuses on the practical realities of defending complex, legacy-laden environments against a fast-evolving threat landscape. In his view, AI automation is forcing a complete rewrite of incident response playbooks . "If your security solution is to patch, you're in a lot of trouble," he says. That warning lands hardest in exactly the environments least able to patch. Patching was never going to save OT The core problem is structural. OT and IoT systems are frequently unpatchable, and the reasons compound. Proprietary software blocks remediation. Firmware can't be updated without breaking operations. And unlike the server and workstation world, there's no central authority pushing security updates. "When you buy a computer, you have an operating system: Windows, Apple, Linux. Many OT companies build their own firmware. They're not using any external party. There's no central patching Tuesday," he explains. "It's up to the company to update it, and in some cases those companies go out of business while you still have their gear in your organization." The result is estates running equipment 10 or 20 years old , from vendors that no longer exist, with no third party thinking about how to secure them. Wade is blunt that organizations leaning on remediation promises are buying a band-aid. Vendors often overstate how much risk automated patch management can eliminate in legacy OT environments. AI collapses the response window What makes the unpatchable-systems problem urgent now is speed. AI has dramatically compressed the timeline between a vulnerability being announced and being exploited, which breaks the patch-planning model that OT and IT teams have relied on for years. "Microsoft announces a zero-day and you'd typically arrange a patch window that night. Internet facing vulnerabilities may now be exploited within hours, leaving far less time for traditional patch windows. It moves that fast due to AI," Wade cautions. That compression is why cyber resilience, rather than patch cadence, becomes the central question. Organizations now have far less time to react before attackers begin exploiting exposed systems. The defense has to be architectural rather than reactive. Defense in depth is the strategy companies keep getting wrong Wade's foundational prescription is defense in depth, and he's candid that it's the thing organizations most consistently fail to execute, regardless of size. "I had a client go through a massive ransomware attack. They thought they had defense in depth, but they didn't. It was a domino effect. The attackers got in one layer, attacked the next, and there was no defense in depth." Getting the basics right is harder than it sounds. A vulnerability that grants access to one system should not grant access to the entire organization, and preventing that requires segmentation, strengthened identity and access management , and additional layers an attacker has to defeat before a compromise spreads. Wade sees this failure at large and small organizations alike, which is why he anchors OT defense in blast-radius control rather than perimeter patching. The same architectural thinking applies to identity. Many OT environments still rely on shared administrator accounts, vendor VPNs with standing privileges, and service accounts that have accumulated permissions over decades. As AI accelerates reconnaissance and privilege escalation, identity becomes another form of segmentation. Limiting what an attacker, or a compromised AI agent, can access is increasingly more valuable than assuming every vulnerable device can be patched. The AI worm threat sharpens the stakes. Where traditional malware like WannaCry was programmable and fixed, research has demonstrated self-propagating malware that adapts, showing limited intelligence to change its route through an environment and spread. "Researchers have demonstrated early concepts of AI assisted self-propagating malware capable of adapting aspects of its propagation. While these techniques have not yet been observed at scale, they illustrate how future malware will become more autonomous," Wade says. Against a threat that finds and exploits gaps automatically, poor segmentation and unknown assets become liabilities that AI tooling can discover far faster than any human attacker could. You cannot protect what you cannot see Before segmentation or detection can work, an organization has to know what it actually has, and Wade repeatedly returns to asset visibility as the first and most commonly failed step. "You could have an estate and think you have threat detection in an OT environment, then realize you have whole rooms of gear operating that you're just not aware of. If you don't know your assets and you're not monitoring them, that's a huge blind spot." His practical playbook for walking into a poorly secured manufacturing environment starts there: deploy threat detection tooling that also handles asset discovery across the estate, then scrutinize network segmentation, redundancy, and single points of access. AI cuts both ways here. It will test segmentation faster than a traditional pen test, which means organizations that believe they are segmented but are not will have those holes exposed quickly. The blind spot extends to the newest layer of risk. AI agents are being deployed across organizations with significant permissions and little security governance, operating on protocols that existing EDR and NDR tools can't see. "You have a blind spot, and you're giving these agents huge permissions," Wade says. "Imagine the threats of these agents getting compromised and the access they'll have." The failure is often budget, not knowledge Wade's most sobering point is that the security teams in the most exposed environments frequently know exactly what to do. They just can't get it funded. Manufacturing and other cost-sensitive sectors routinely accept more risk than their security teams recommend. "A lot of times the security team is recommending the right course of action, but they don't get approval for the cost from management. These tools are not cheap. And there's an old irony: if you want your security budget to increase, go through a ransomware attack. Everyone gives you more money after an attack," Wade notes. The contrast he draws is stark. Having run security for both manufacturing groups and hyperscale data centers, he describes the difference in investment as night and day, with data centers flush with money and spending more on cybersecurity and manufacturing operating with minimal cybersecurity budgets despite sometimes carrying critical infrastructure. That gap is why Wade expects the first major AI-driven OT incident to expose years of deferred architecture work. The fixes are known. The tooling is improving. But in the environments where an attack would do the most damage, the investment tends to arrive only after the damage is done.

## AI-Era Security Demands Runtime Proof Over Policy Reporting
URL: https://www.thesecuritydigest.com/news/albert-evans-tata-consultancy-services-ai-security-runtime-proof-importance
Published: 2026-07-26T13:09:02.799Z
Section: AI
Summary: Albert Evans, Director of Cybersecurity at Tata Consultancy Services, explains why security leaders need to validate controls at runtime as AI accelerates the attack surface.
Full text:
Many enterprise AI programs face one of two recurring constraints: funding without a coherent operating model, or a credible plan without sustained funding. Both share the same downstream problem, with boards and executives treating AI as a standard IT infrastructure project and taking governance shortcuts that surface later as failed initiatives, wasted spend, and security postures no one can actually validate in production. The cost of those shortcuts is what makes runtime proof an emerging operational requirement. Albert Evans , Director of Cybersecurity at Tata Consultancy Services and an Expert Advisor at Primary Venture Partners , has spent his career securing the systems most organizations would call un-securable. He previously served as CISO for ISO New England, where he protected a $13 billion wholesale electricity marketplace and the bulk power grid serving 15 million residents. The U.S. Army veteran brings a battle-tested perspective to the boardroom, and his current read on enterprise AI is that the operating model behind most initiatives is structurally flawed. "You need to connect the governance, which is still important, but you need to tie it to runtime, to conditions on the ground. Wishing it won’t make it so," says Evans. Industry analysts frequently argue that AI technology moves too fast for security teams to keep pace, and Evans pushes back on that framing. In his read, the real vulnerability is an accountability gap, and he believes in a layered operating model. Autonomous AI requires board oversight and clear management accountability, not routine board involvement in operational decisions. In Evans' model, the board should establish risk appetite, approve governance principles, oversee material AI risks, and require evidence that high-impact autonomous systems remain within authorized boundaries. Executive management and a cross-functional AI governance body should assign accountable owners, risk-tier use cases, define decision rights, approve material exceptions, and ensure adequate funding. Business, technology, security, data, legal, privacy, HR, and risk leaders should implement and monitor the controls and internal audit should provide independent assurance. Material residual risks, repeated control failures, or unresolved exceptions that exceed management authority or organizational risk tolerance should be escalated to the appropriate board committee. Closing the runtime blind spot Without executive oversight, autonomous tools are being deployed into production environments with no one watching them, creating the blind spot where autonomous AI agents can be manipulated through trusted content, tools, memory, credentials, or indirect prompt injection, causing harmful actions that may appear authorized to conventional controls. Evans argues that securing these environments requires the kind of organizational redesign Six Sigma demanded a generation ago, with executive commitment to break down departmental silos and re-engineer business workflows. HR has to be involved early to reconstruct job descriptions and pay bands so the right humans stay in the loop to check the AI's work. The urgency is operational, with cybercrime groups restructuring themselves to operate at machine speed, which puts unmonitored deployments at the front of the attack surface. "Instead of traditional 'living off the land' using other tools, they get into your autonomous AI and use that against you. And so many people don't have any type of runtime controls. They're not going to know it, they're not going to be able to detect it, they're not going to be able to respond to it, they're not going to be able to contain it," Evans says. The deeper problem is that static authorization models were built for human employees and do not translate cleanly to systems that act on their own. As enterprises delegate more execution authority to AI agents, they must extend identity governance beyond human users and conventional service accounts The capability gap is not solely technical. Many necessary controls exist , but tooling maturity, integration, operating discipline, and organizational authority remain uneven. Advanced tooling can automate exposure discovery, validate defensive controls, prioritize likely exploit paths, and deploy compensating controls while patches are developed , tested, or scheduled. The challenge is implementation discipline, with real-time tracking of autonomous actions being exactly what most teams have yet to operationalize. "Now with an AI agent, it's, 'Here's what I'm telling you that you can do.' And then I need to track it in real time to make sure that's what you did," Evans notes. Containing attacks at machine speed Public data has confirmed for more than a year that threat actors are already operating with AI , yet many organizations continue relying on manual SOC processes while ignoring published best-practice documents, adoption guidelines , and warnings from global intelligence agencies about the future of autonomous identity operations. DevSecOps is the clearest example of the pattern, where paper-based policy rarely connects to the technical enforcement that would actually contain risk in code. It can become organizationally isolated when policy ownership, pipeline authority, application risk, and security accountability are not clearly connected. The same enforcement gap shows up across incident response, where the speed required to contain modern attacks runs directly into the bureaucratic approval chains most organizations still use. Reconfiguring containment authority is what separates organizations that survive a machine-speed compromise from those that find themselves on a war-room call hours after the damage is done. "Even if they focus on improving the SOC, they have things outside the SOC," Evans notes. "If you want to contain a system, I need to talk to the system owner, the application owner, I need to get this director's approval. That's hours and hours of time. You get a compromise at two in the morning on Saturday. How long does it take you to get the human bureaucratic approval to contain the system? It's too slow." The disconnect also plays out at the board level, where security leaders often report against static metrics that signal coverage without measuring actual exposure. Closing the gap means translating policy into enforceable runtime controls , continuous telemetry, tested response procedures, and evidence of operating effectiveness. Evans has published a free, open-source Agentic AI framework covering AI FinOps, control mapping, and governance modeling for organizations still treating the work as theoretical. "Framework alignment identifies desired outcomes. It does not by itself prove that controls are appropriately designed, correctly configured, or operating effectively," he concludes.

## Cyber Hygiene Remains Security’s Best Defense And Its Most Overlooked Discipline
URL: https://www.thesecuritydigest.com/news/cyber-hygiene-insider-threat-culture-petra-klein-swedbank
Published: 2026-07-26T13:09:02.799Z
Section: Observability
Summary: Petra Klein, Group Chief Security Officer at Swedbank, argues resilience starts with access, habits, and culture before another tool joins the stack.
Full text:
The attack window keeps shrinking. AI-enabled threats move faster than ever. And most organizations respond by looking for the next tool, the next platform, the next capability to add to a stack that already has more products than anyone can operationalize. Meanwhile, the red team walks in through an unchanged password . Petra Klein is Group Chief Security Officer at Swedbank , one of the largest banks in the Nordic and Baltic regions, where she leads a 130-person Group Security and Cyber Defence unit spanning the CISO function, protective security, cyber defense center, offensive security, physical security, and executive security. Before joining Swedbank's leadership, she spent nearly a decade as an ethical hacker at Sweden's National Defence Radio Establishment (FRA), conducting authorized penetration tests against government offices and the Swedish Armed Forces. She has been named to multiple global CISO and security leader lists and approaches resilience as a culture problem first and a technology problem second. "You have to have a mindset today that if you're reachable, you're breachable," Klein says. "You stop almost 90% of all cyberattacks with just pure cyber hygiene. Don't make it too complex. Continue with high focus on access management, multifactor authentication, and making sure that if an attacker gets a foothold, they cannot get any further." Insider threat as employee protection Klein's team has built an insider threat program structured as a cross-functional virtual team spanning security, fraud, legal, and HR. The scope is deliberately narrow. The program maps the most critical infrastructure to the roles that have access to it. "Not all 17,000 employees. It's only a few roles," Klein says. "Those become the boundaries of the insider threat program ." The detection engineering team builds scenarios around those roles: data leakage prevention triggers combined with anomalous behavior signals like unusual access hours. When two or more triggers fire simultaneously, the system escalates. Employees with critical-infrastructure access are told that their role makes them a potential target for nation-state recruitment, and the goal is to make that vulnerability shareable rather than shameful. "No one wants to be the target of a nation-state actor," Klein says. "If you have a vulnerability and you share it with us, then it's not a vulnerability anymore. If it's not a secret, it's not a vulnerability." The vetting process is integrated into regular manager follow-ups rather than administered by security, because managers know their people best. Mandatory training does not create culture Klein is blunt about the limits of annual compliance training. "The mandatory training once a year is just compliance-based," she says. "It doesn't create culture ." Her team has replaced that model with manager-led classroom training built around customizable topic kits. Managers choose from four modules, select the one closest to their team's actual work, and lead a one-hour session themselves. The pilot is underway and rolling out after summer. The team is also deploying a security escape room built around an insider threat scenario. Participants follow a phishing email trail, review building access logs from pass entry systems, and work through a hands-on cyber exercise using gamification. "It's one or two hours, and it's really a hands-on cyber exercise," Klein says. "We just tested it in the management team." The broader culture program runs on visibility and repetition. Signs in buildings, stickers that read "security is everyone's business," and campaigns on the coffee machines. One-liners that stick. "No one is going to read a hundred-page management system," Klein says. "You have to create that resilience in their mindset, in their DNA." For Klein, tooling is secondary to people. "It doesn't matter anymore who has the biggest or the most expensive tooling," Klein says. "It's the people behind it, their skills, and the will to defend. That is what we are trying to build."

## Healthcare Security Rollouts Succeed When Endpoint Protection Fits Clinical Workflows
URL: https://www.thesecuritydigest.com/news/healthcare-endpoint-rollout-clinical-continuity-michael-sieli
Published: 2026-07-26T13:09:02.799Z
Section: Leadership
Summary: Michael Sieli, Project Manager at Main Line Health, explains how he deployed endpoint protection across 11,500 endpoints in a hospital system by staging the rollout around clinical continuity, starting with a controlled IT pilot, and earning organizational trust one clean deployment at a time.
Full text:
Deploying endpoint protection across a banking environment and deploying it across a hospital system are fundamentally different operations. In banking, users are generally adept with technology. In healthcare, clinicians are focused on patients. They're not interested in security tooling, and they will push back the moment it touches their workflow. That difference shapes everything about how a healthcare security deployment has to be designed: uptime, user choice, rollout sequencing, and staged trust-building matter as much as the endpoint protection itself. Michael Sieli is a Project Manager with a lengthy history of leading telecom, network, and cybersecurity deployments in the healthcare, telecommunications and banking industries. His project management work spans Bank of America, Citibank, and AT&T, in addition to multiple hospitals and health systems. He's learned that in healthcare , the first clean deployment determines whether the organization will let you finish. "You can't go right into the hospital and do a rollout," Sieli says. "You have to test everything out, test your team, evaluate that rollout, and make sure there's no hiccup." Start with a win One of Sieli's recent projects was a behavioral endpoint protection rollout across 11,500 endpoints, which he worked on with Security Program Manager Tony Fiore and CISO Aaron Weismann. Their first step was standardization. "We had boxes that were Windows 2008. We had to get everything on the same platform before we could roll it out." The pilot targeted 500 IT department users, a deliberate choice rather than a random sample. "They're IT users, so they have more leeway of understanding," Sieli says. "Once we did that and it was clean, we knew we could start rolling this out." The team waited two weeks after the pilot to confirm there were no issues before expanding. From there, the rollout moved through auxiliary facilities, rehab centers, and outpatient buildings, building confidence at each stage before touching the main hospitals. "You want to get a win," Sieli says. "The organization, especially in healthcare, is going to say 'this is a mistake.' The first rollout has to come clean." Separate the hard from the easy Sieli divided the deployment into three categories: laptops, workstations, and servers. Laptops were the fastest. Packages were pushed overnight, with employees asked to leave machines online. When they powered up the next morning, the agent was already installed. Users who were online during the day received a prompt with the option to reboot immediately or delay. "You have to give people options," Sieli notes. "There may be something really important they have to do." The team identified gaps quickly. For instance, remote workers not connected to VPN missed the initial push. Those lessons learned fed back into the next wave. Laptops and workstations were completed in four months. Servers, the most operationally sensitive layer, took an additional two and a half months because each one sat underneath clinical applications with integration dependencies that required careful validation. Protect trust after the rollout Even a clean deployment can be tested after the fact. After the endpoint agent was deployed on a cardiology system, the application went down three days later. The timing created immediate concern, and the clinical director called an emergency meeting to understand whether the new security tool had affected the system. "We got everybody on the call," Sieli recalls. "CrowdStrike said, 'this is what we’ve got and it’s not us.'" The application team later confirmed the failure originated elsewhere. For Sieli, the lesson was not that clinical teams resist security for the sake of resisting it. It was that healthcare systems sit too close to patient care for any disruption to be treated casually. When an application goes down after a security change, the security team has to expect scrutiny and be ready with evidence, escalation paths, and vendor support. "You’re going to get blamed for just being in the area," Sieli says. In that environment, trust is earned through preparation, transparency, and repeated stability. That makes success look different from a standard endpoint project. Coverage numbers and threat-detection metrics matter, but the operational test is whether clinicians can come to work, log in, and continue caring for patients without noticing the system changed underneath them. "All they know is that they come to work, their machines are working, and they’re logging in with no issue," Sieli says. "As long as there’s uptime and no downtime, it’s a success."

## Human Incident Response: The Next Evolution of Cybersecurity Leadership
URL: https://www.thesecuritydigest.com/news/human-incident-response-responder-burnout-ty-hughes-jothi-dugar
Published: 2026-07-26T13:09:02.799Z
Section: Leadership
Summary: Cybersecurity strategists Ty Hughes and Jothi Dugar explain how their Human Incident Response plan keeps responders functioning through weeks-long breaches.
Full text:
Security teams engineer single points of failure out of their systems, then route a six-week incident through one exhausted incident manager and never account for that person as the same kind of risk. A prolonged breach is decided by judgment, and that is the first capability exhaustion takes . The leaders closing that gap treat responder capacity as part of the response itself, planned and protected before the pressure arrives. Ty Hughes and Jothi Dugar built Human Incident Response (HIR) around that problem, a plan that runs alongside the technical work of containment and recovery and keeps the people doing it from breaking down first. Hughes, known in the field as the "AI Alchemist," is a transformational technologist with nearly two decades spent helping organizations navigate complexity through human-centered technology leadership and a President's Management Council Interagency Rotation Fellow. Dugar, an executive strategist and international bestselling author with more than 25 years at the intersection of technology, cybersecurity, and human-centered transformation, is widely known as Jojo D., "The Chaos Guru." Their work over the past several years has pushed security teams to treat the people behind the systems as something worth protecting. "We build incident response plans for compromised systems all the time. We don't always do that for compromised human capacity, and that's the blind spot," Hughes says. Second in command One of the practices Hughes leans on is something he calls Acting in Place. For a set window, a leader stays physically in the building handling administrative work but steps out of the decision-making seat entirely, and a designated deputy carries every operational duty in their place. He uses it on purpose with staff who are not yet ready to hold the full operation, treating the planned absence as the thing that grows them into it. "She's unavailable unless there's an emergency. Someone has been assigned to act on her behalf, and they go through and carry out all the duties," Hughes says. He has run it with his own teams for years, and the payoff shows up on ordinary days as much as hard ones. A leader can take a vacation or a mental health day without the operation stalling. By the time an emergency makes someone unreachable, the handoff has already been rehearsed, and the gaps surface when the cost of finding them is low. Built-in backup The deputy who steps in is building toward their own next role. Hughes frames the experience as a credential a person can carry forward, proof they have run the operation under real conditions. "It does wonders in training staff up, giving them that level of confidence," Hughes says. The organization gets a deeper bench out of the same arrangement, with more than one person fluent enough to take the lead, so no individual becomes the point everything routes through. Adversaries do not pause for weekends or holidays, and the average breach still takes 241 days to identify and contain, the better part of a year from first alert to all clear. A crisis on that timeline cannot sit with one incident manager. You have better coordination, you have better team resilience, you're actually faster." - JoJo D., "The Chaos Guru," Cybersecurity Strategist "If the incident lasts four weeks, it's not fair to put one person on call for two months at a time. With people acting in place, you keep shifting every eight hours, so you have multiple people on the team well versed on the incident versus just one leader," Dugar says. The plan also writes in mandatory recovery time, so a responder who loses a weekend to a crisis is not expected back at full speed on Monday. Permission to pause Dugar watches for strain long before an incident starts. She treats compassionate leadership as a diagnostic instrument as much as a management style, and one of her routines is a brief check-in at the top of meetings, often called a rose and a thorn, where each person names something good in their life and something they are struggling with. It takes a few minutes and gives a leader a baseline read on the room. "If this person doesn't normally act this way, there must be something going on," Dugar notes. The check-in is there to catch when a capable person is quietly carrying something heavy, a sick child or a family emergency that raises the cognitive load they walk in with. Inside an incident, that load compounds and lands on judgment first. Exhaustion rarely stops a responder from working. It slows their decisions and narrows what they notice, so the subtle indicator that should redirect an investigation slips past. Dugar builds her next intervention to counter that directly. Pausing in the middle of a breach sounds counterproductive, and resistance is the first thing she runs into when she introduces it. She installs the pause regardless. The whole team takes a mandatory 10-to-15-minute reset every four hours, fully away from screens, with no email and no dashboards, long enough to walk or breathe and clear the head before going back in. She compares it to a NASCAR pit stop, where even the leading car surrenders track position for tires and fuel because the car that never stops loses the race. "You have better coordination, you have better team resilience , you're actually faster," Dugar says of teams that build the resets in. The discipline extends past the incident itself. When a responder has lost a weekend to a crisis, the plan treats the days that follow as operational maintenance, the same care a team gives any system it has just pushed past its limits. Returning someone depleted to a full inbox and a stack of postponed work only moves today's fatigue into the next incident. "You actually take some time off for yourself," Dugar adds. The cape comes off Hughes has grown wary of a culture that prizes constant heroics. He still recognizes extraordinary effort, but he no longer lets it pass without examination. When someone goes above and beyond, he follows the applause with a question about what made the heroics necessary, and whether missing redundancy forced one person to carry too much. "A lot of times we have confused exhaustion with commitment, and we call it cyber culture," Hughes says. A repeated pattern of last-minute saves reads to him as an early signal that something structural has gone wrong. The same instinct that keeps a leader from running critical systems without a backup, he argues, belongs with the people running the response, and most of the work is planning for human limits in advance, while the stakes are still low. For Hughes, the goal is to make heroics the rare exception they are meant to be. "I want to reduce the number of times that someone has to be a hero for us to be successful. If a person or persons are constantly being the hero, that's an indicator for me that burnout is quite possibly around the corner ," Hughes says. The people who defend an organization are critical infrastructure, no less load-bearing than the systems they protect, and planning for their limits is what keeps the cape in the closet on all but the worst days. "I don't want them to put that cape on except for those extreme emergency moments. And then when they take that cape off, we've got to identify what was the situation that required them to put the cape on to begin with," Hughes says.

## Governance-First Preparation Is Making Agentic SOC Viable For Banking Security
URL: https://www.thesecuritydigest.com/news/md-azad-eastern-bank-agentic-ai-readiness-framework
Published: 2026-07-26T13:09:02.799Z
Section: AI
Summary: Md. Abul Kalam Azad, CISO at Eastern Bank PLC, lays out how banks are building toward autonomous SOC by anchoring adoption in governance and integration.
Full text:
Agentic AI is the cybersecurity industry's current obsession, built on the conceptual promise of autonomous systems that run detection, triage, and response with minimal human input. Vendors are pushing fully autonomous security operations architectures into the market, but many banking security leaders are moving cautiously. Under the regulatory guidelines governing modern financial services, the next few months for most large institutions are going toward defining use cases, evaluating integration paths, and drafting governance policies before any autonomous action layer touches the SOC. Md. Abul Kalam Azad , CISO at Eastern Bank PLC , works inside the kind of regulated environment where the agentic SOC conversation is landing hardest. He brings over two decades in regulated financial services to that seat, along with top-tier risk credentials (CISSP, CISA, CISM, CRISC) and a GRC background that has produced peer-reviewed research on the specific governance questions the sector is now navigating. Azad frames the AI question around a discipline banks often skip: before a bank deploys AI, it has to define the exact problem the system is being deployed to solve. "Once we can implement agentic SOC, it's really game changing. It can detect lots of threats ahead of time, analyze the threat, and really reduce the false positives," says Azad. From Azad's perspective, the game-changing potential doesn't translate into a purchasing decision. His framework treats AI readiness as an operating exercise that runs across several stages. It starts with defining the specific problem the system needs to solve and building use cases against it, moves through implementation testing and SOC team training, and lands on measuring outcomes and putting governance around ethical and practical AI use. The autopilot SOC vision Banking security leaders are running the agentic SOC evaluation with a specific leadership vision in mind, one where the SOC operates on autopilot and the analyst team gets pulled off the repetitive detection work. The appeal is straightforward on paper: an autonomous layer that handles the volume, learns from what it sees, and pushes updates back into the security stack without waiting on manual review. "From a leadership point of view, we expect that an agentic SOC will work in an automated, autopilot mode," Azad says. "It can automatically detect threats, learn by itself, improve detection capabilities, and reduce false positives. It will update signatures and push IOCs to defined security devices like firewalls, IDS, and IPS." Eastern Bank is one of the institutions actively evaluating agentic tooling under that vision, and it is holding off on deployment for the next three to six months while the technical prerequisites get built out. Institutional risk appetite and scrutiny from domestic regulators shape how quickly banking security teams can move on autonomous response, and internal capability gaps inside the SOC combine with the deep work of modernizing legacy financial infrastructure to define the actual runway. Azad points to the integration layer specifically as the bottleneck banks underestimate most consistently. "We need to integrate the SIEM, SOAR, and all other solutions where logs originate to deploy the agent," Azad advises. "Deploying agents is quite difficult. It requires a lot of complexity, log normalization, and things of that nature, especially when dealing with legacy systems that lack compatible integrations." Defining accuracy as the trust threshold Trust in autonomous response only builds when the system's accuracy is demonstrable at a level regulated environments can defend. Azad works from a specific numerical threshold: 95% detection accuracy on the attacks the SOC actually sees, established through highly curated training datasets and detection frameworks mapped natively into the platform . The mathematical bar is deliberately high because the alternative is worse: an autonomous system operating below the confidence threshold produces the same compliance exposure a poorly documented manual process would, at faster speeds. "I specifically want to see that AI has at least 95% accuracy. Out of 100 attacks, it must detect 95 automatically," Azad notes. "When we see those results, our confidence will grow." Reaching that threshold has direct consequences for how the SOC is staffed. High-volume triage work becomes the natural first workload for autonomous systems, and the practitioners doing that work move up the stack into reskilled supervisory roles focused on managing the automation itself. Azad is clear that the automation still needs an irreversible threshold of human oversight running above it, because the judgment layer above the detection layer is where the actual risk decisions get made. "Humans possess natural knowledge, skill, and common sense. Developing common sense in AI is still very difficult," Azad warns. "Humans have one type of capability, and AI has another. If you combine them properly, you get the best results." A research-backed framework for readiness Azad believes the trajectory pointing at the broader banking sector is a compressed six-to-twelve-month adoption window where AI deployment expands across cybersecurity, operational excellence, and customer service simultaneously. Institutions using that window to build governance frameworks and map their data pipelines will scale AI without hitting the friction that has stalled early enterprise deployments elsewhere. Institutions treating adoption as a procurement exercise will end up rebuilding the same integration and governance work under time pressure later. The practical framework Azad points to for that preparation work comes from his own peer-reviewed IEEE research , which maps out how banks can evaluate AI readiness against specific institutional vulnerabilities and match deployment sequencing to the areas of highest operational return. "In our paper, we broadly identified areas where banks can deploy AI, including operations, customer service, credit scoring, fraud detection, and cybersecurity," Azad concludes. "For a short-term strategy, we identified some quick wins. For the long-term strategy, we identified the need to develop AI governance policies and ensure the ethical use of AI."

## AI-Speed Ransomware Turns The First Hour Of Incident Response Into A Years-Long Risk Decision
URL: https://www.thesecuritydigest.com/news/ransomware-first-hour-decisions-consequences-chris-patteson
Published: 2026-07-26T13:09:02.799Z
Section: Leadership
Summary: Chris Patteson, Director of Cybersecurity, GRC at a large pharmaceutical manufacturing organization, why the decisions made in the first hour of a ransomware response shape years of legal, regulatory, and operational consequences.
Full text:
The views and opinions expressed are those of Chris Patteson and do not represent the official policy or position of any organization. Ransomware response used to be measured in days. Regulatory notification used to require 72 hours. The containment decision could wait for a call with leadership. None of that holds anymore. NIS2 in the EU compresses notification to 24 hours, with penalties matching GDPR: 2% of global revenue and potential personal liability for executives. AI-enabled tools are discovering exploitable zero-days in code that has been deployed for decades. And the decisions security leaders make in the first hour of an incident create consequences that stretch for years. Chris Patteson is Director of Cybersecurity, GRC at a large pharmaceutical manufacturing organization and Co-Founder of the Enterprise Risk Quantification Institute . He also serves as a Chief Warrant Officer in the Louisiana Cyber Reserve, supporting cyber recovery and remediation for state agencies. His prior roles include Director of InfoSec at FedEx, where he was present during the NotPetya attack , and GRC leadership at Archer and LogicGate. He holds a patent in cybersecurity for device posture detection and isolation. “A threat's ability to spread has changed. I have to make rapid decisions to preserve the resiliency of the entire operation,” Patteson says. “If you’re a distributed organization with lots of locations and you have to stop the spread once something is in your environment, that makes time of the essence.” AI accelerates both sides The exploit discovery window is collapsing, and two public cases show what that looks like: Claude Mythos Preview surfaced a 27-year-old vulnerability in OpenBSD’s TCP SACK implementation, while a separate Mythos review of WolfSSL generated multiple CVEs, including a certificate-forgery flaw affecting embedded environments. "It found an exploit that had been there for 27 years," Patteson says. "Nobody, no human, had found it. It was stringing together multiple techniques and tactics to create the exploit." The open-source software embedded in firewalls, IoT devices, and industrial equipment creates a risk surface that AI can map faster than security teams can patch. The long tail nobody plans for The first hour gets the attention. The years that follow do not. Patteson describes organizations that reinfected themselves by restoring corrupted backups without using a clean-room environment. Forensics teams that spent months determining whether attackers left backdoors beyond the initial encryption. And litigation that runs for years across partner obligations, privacy notifications, and regulatory enforcement. "The initial cost of NotPetya to large corporations ran into the $400 to $700 million range," Patteson says. "But the long-term impact from litigation, re-architecting infrastructure, and regulatory follow-up could be up to double that." He warns that cyber insurance policies contain panel requirements buried deep in the terms, and failing to follow them can void coverage entirely. "Have your attorney in the room. Start looking through that and call law enforcement." Legal privilege matters immediately. Patteson has seen organizations fire emails about an active incident without marking them privileged and without copying legal counsel, making everything discoverable in court. "One of my first calls, even before it's a true incident, is to get legal involved and start marking communications privilege and confidential," he says. For security leaders personally , D&O insurance is not optional. "In some of the stricter jurisdictions, they'll skip dealing with the company and come straight after you." Pre-authorize the decisions before the incident Patteson frames agentic SOC tools as an acceleration of what already exists, not a new category. "We've been doing SOAR for probably more than a decade," he says. "All you've done with agentic AI is boosted the capability of what we would have called orchestration." The question is whether organizations will let an autonomous responder make a containment decision : kill a firewall, isolate a location, shut down a network segment that costs a million dollars in lost production. Those decisions have to be pre-authorized. "For these assets, we're going to have to make these decisions. How long are we willing to wait before we make that decision?" Patteson says. The business, security leadership, and operations all need to sign off on the triggers, the asset boundaries, and the acceptable cost before the incident begins. He draws parallels to nuclear power plants that pull control rods automatically and aircraft with fault-tolerant failover systems. "Humans are not going to be able to respond fast enough," Patteson says. "I think we're going to see more of that coming to autonomous networks."

## Solving The AI Security Challenge Starts With Governance And Human Verification
URL: https://www.thesecuritydigest.com/news/skylan-t-jones-cybersecurity-ai-human-fundamentals
Published: 2026-07-26T13:09:02.799Z
Section: AI
Summary: With AI outpacing governance, Skylan T. Jones walks through why security programs need executive access, mid-level authority, and human verification before AI can strengthen the operation.
Full text:
Cybersecurity is now a core business risk rather than a contained IT problem, and the fast-paced adoption of AI tools is changing how security teams operate against that backdrop. Automated threat vectors and defensive solutions are moving faster than current governance frameworks can keep up with, producing an illusion of coverage when the underlying operational foundation is weak. Throwing AI at a security problem doesn't automatically solve it. The clearer consensus emerging across the industry is that AI works best when it amplifies strong human fundamentals. Skylan T. Jones has spent nearly a decade securing high-stakes environments where the margin for error is close to zero. He holds CISSP, CISM, CISA, and Security+ certifications and has directed global communications security programs and safeguarded zero-fail networks across military operations, the International Space Administration, and higher education. His starting point for evaluating any security program is the reporting structure that determines whether real risk gets seen by leadership. "We aren’t startup companies. We’re freight trains. We can’t move fast and break things — that can’t be the philosophy. Otherwise, missions can fail, money is lost, shareholder value is diminished," says Jones. The drive to move fast routinely exposes structural flaws inside the human organizational chart. Burying the CISO under the CIO creates a reporting-line conflict of interest where severe threats can get downgraded when they threaten the budget. The structural problem is one of the most common obstacles to boardroom accountability in security programs, and solving it requires CISOs to move beyond delivering technical status updates and start functioning as "risk translators" for the executive team. Translation, authority, and human verification Where the CISO sits in the reporting structure is only half the problem. The other half is what the CISO says once inside the boardroom. The technical vocabulary security leaders use every day rarely lands with executives who are evaluating cyber risk as a business trade-off. "CISOs might make the mistake of trying to go into board meetings and speak a lot of jargon that no one wants to hear and no one understands," he notes. "The CISO might be coming from a technical background where they are used to scripting and coding their way through problem-solving. It is the CISO's job now to translate cyber risk into a business language that everyone understands, keep it brief, and make it impactful." The same accountability problem shows up one layer down at the mid-level program owner. Without a digitized tracking framework that assigns live ownership to specific deliverables with visible timelines, security programs run on manual status-gathering and informal authority. "You could have a program manager that sits in the ops side of the organization, but the implementers all sit in different parts of the organization and none of them necessarily answer to the program manager," Jones explains. "They set out requirements that need to be done, but the system implementors tell them that they don't have to do it right now." AI moves the whole operational tempo faster and exposes the foundational weaknesses that were tolerable at slower speed. Jones points to recent high-profile IT disruptions like the CrowdStrike Falcon content update push and the SolarWinds supply chain compromise as examples of what could happen when human verification gets removed from the loop. "There is too much trust in the AI doing the QA," he observes. "A certain level of reliance on those systems is going to be necessary, especially moving forward as codebases get larger, but we still need to have a team of humans to fact-check the machines. Otherwise, missions fail. Money can be lost, and shareholder value can be diminished." The agentic SOC challenge The agentic era of AI has arrived inside the SOC before most security teams have finished figuring out what to do with it, and the practical challenge is finding the right balance of human oversight against the operational speed the tools promise. Forcing AI solutions onto unprepared analysts destabilizes operational norms faster than the efficiency gains materialize. The specific SOC risk is that analysts start reading a silent dashboard as an all-clear signal instead of as a prompt to investigate what the tools might be missing. "It really just comes down to understanding your systems and your governance documents on a personal level, and not simply relying on pasting system issues into AI to ask what to do according to NIST 800-53," Jones says. The people side of the equation is where most SOC restructuring efforts around AI run into trouble. Organizations need analysts who understand both the systems the AI is monitoring and the AI tools doing the monitoring, and cutting headcount before the AI can genuinely operate without hand-holding produces exactly the blind spots Jones warns about. "Organizations need to not be so quick to shorten their workforce and replace them with AI agents that aren't fully fleshed out and still need a lot of hand-holding," he cautions. "If you don't understand your people, and AI should be lumped in as your people, you don't understand where their weaknesses are. And then there is a blind spot with organizations." Before the blitz-scale The pressure to deploy AI often comes from top-down mandates demanding immediate action, and the resulting scramble to meet compliance requirements produces a fragile security posture built on governance shortcuts , without the operational foundations that would make it durable. "A command will come down from the C-suite or a one-star general demanding that we start sending out assets to support a mission, and that we need to do it yesterday," Jones says. "People will try to meet three or four different governance policies and rush to implement these programs simply to meet that command. The programs end up in a much worse position than they would have been if we had taken the time to understand what it is we are trying to implement as a program." Jones's strategic argument is that public and private sector organizations are freight trains, not startups. Moving at blitz-scaling speed without patch management, employee awareness, governance documents, and operational foundations produces programs that fail their first meaningful test. Building scalable risk programs means slowing organizational change long enough to assess tools, map team capabilities, and lay a foundation before layering AI on top of it. "Once you build that foundation, then you can blitzscale if necessary," Jones concludes. "You build a lot more organizational value, as opposed to a program thrown together with cardboard that gets blown down by its first real audit or incident." The views and opinions expressed are those of Skylan T. Jones and do not represent the official views, policy, position, or endorsements of GDIT, The US Air Force, or Department of Defense.

## Unpredictable Autonomous Agents Are Rewriting the Rules of Identity Security
URL: https://www.thesecuritydigest.com/news/ai-challenges-traditional-identity-governance-helen-patton-cisco
Published: 2026-07-07T23:54:50.216Z
Section: AI
Summary: Helen Patton, Cybersecurity Executive Advisor, explains why the biggest variable in enterprise security is no longer the human and what that means for identity, governance, and the future of the SOC.
Full text:
AI is rewriting the rules of enterprise security, but the industry’s knee-jerk reaction is a tired cliché: go back to basics. In an environment defined by hybrid workflows and the fast-paced rollout of dangerous frontier models , using new technology to speed up old checklists doesn't actually solve the problem. As the primary source of unpredictability in a network moves from human employees to autonomous machines, many security leaders are finding they need to rethink their approach entirely. Advocating for a fresh take on how cyber programs are designed and governed in an AI-native environment is Helen Patton , a Cybersecurity Executive with more than two decades of enterprise risk experience. Her background gives her a unique vantage point of exactly where theoretical AI capabilities crash into on-the-ground reality. For Patton, navigating the AI era begins with recognizing that the core variable of risk has flipped. "The place where threats occur is where things are the least controlled, the least standardized, and the least predictable. That place is now the AI, not the human," she says. The industry has spent two decades building intricate Identity and Access Management (IAM) programs designed to contain human unpredictability. Acknowledging that autonomous agents become unpredictable variables changes how security teams must approach governance. The hamster wheel 2.0 Foundational controls like zero trust, multi-factor authentication, and standardized endpoints remain non-negotiable. Security, as Patton describes it, is the counterculture to the organization by design, constantly managing edge cases. As edge cases expand beyond human behavior, the application of these frameworks must adapt . Patton says some companies are rushing to reimagine cyber defense , but most are just using AI to run the same old playbooks at a higher speed. "Most organizations still have a tendency to say, 'How can we use AI to do our security jobs faster?' But they're still thinking of it in terms of doing things the same way they always have. AI presents the opportunity for us to reimagine the way we do cyber so that we're more prepared to respond at scope and scale in an AI world." Training wheels required The need for a new playbook is highly visible in the SOC , where some teams are beginning to restructure as AI absorbs entry-level work. Many experts suggest the future of the SOC depends on elevating analysts to orchestrate operations and apply local context. "While AI will do the discrete tasking, the human can weave those tasks together and create meaning and apply it to the local context," Patton says. Still, she notes that job boards routinely reinforce a rigid checklist of tactical skills and certifications. "Yes, you still have to know the skills, but what you really need is the ability to sit above it and orchestrate it. That's where we're going to head." Accomplishing this, she believes, doesn't mean junior staff get to leapfrog over entry-level jobs. Instead, those jobs become a prerequisite. "We are going to have to intentionally give people level-one work, so that they have the intellectual capability of applying human judgment over AI agents ." Governance can't keep up Applying human judgment to machine behavior requires communication channels that actually work. Right now, they largely don't. The external policy environment remains highly volatile. Federal regulations currently focus on national security and export controls, while state and local policies prioritize privacy and workforce safety. Internally, traditional corporate governance often breaks down between senior leaders who lack ground-level context and junior employees who lack decision-making authority. "Senior leadership is too senior to understand the on-the-ground implications, and people who are too junior aren't given the authority to make the decision," Patton says. "So you've got this break between the people who have to approve a governance item and the people with the knowledge to approve the governance item." Because of these bottlenecks, she says, the industry continues to struggle to define good AI governance models . The governance process itself poses another challenge. Because human governance relies on slow, context-heavy approvals, it's not easily applied to high-speed AI agents. Persistence is widely considered a major driver of technical debt, as static identities tend to accumulate risk, privileges, and vulnerabilities over time. To solve the bottleneck, Patton points to Sounil Yu's DIE triad , which stands for Distributed, Immutable, and Ephemeral. She says disposable, non-human identities drastically reduce the attack surface the moment a task concludes. "Humans have had persistent identities, at least until they die. But that's not how AI is going to work. An agent shouldn't have an identity and shouldn't be able to do anything until it's necessary. Then, it should only have an identity that allows it to do the thing, and the identity goes away again." Democratizing security Beyond the walls of top-tier enterprises, many organizations looking to move toward agentic security and continuous compliance engineering face a resource gap: a lack of advanced software coupled with a shortage of the human cognitive bandwidth required to supervise AI. The imbalance means under-resourced organizations struggle to evaluate AI safely or determine if it's contextually appropriate. Because we rely on these smaller organizations to manage public utilities, healthcare, and local infrastructure, even massive enterprises will feel the pain. "If they can't turn the lights on and flush the toilets, they're just going to be in the same boat as everybody else. The people who are doing security for their lights and their water are going to need help," Patton points out. Rather than viewing the gap purely as a reason to panic, she frames it as the exact reason the industry must pivot its operational model. AI offers a practical opportunity to help under-resourced organizations manage their security without needing a massive in-house team. "One silver lining that we can think about is how to democratize things so that under-resourced organizations are better protected without having to do it themselves," Patton says. For her, the real promise of AI isn't simply making the best security teams faster. It's rethinking the strategy entirely and making effective security possible for organizations that could never build those teams in the first place.

## AI Attacks Break Out in Under a Minute, While Most SOC Models Are Still Built Around Human Speed
URL: https://www.thesecuritydigest.com/news/ai-attacks-51-second-breakout-soc-models-michael-orozco-gartner
Published: 2026-07-07T18:10:20.356Z
Section: AI
Summary: Michael Orozco, CISO of IronOrchid.ai, explains why AI-enabled multi-vector attacks that break out in under 51 seconds are outrunning analyst-heavy SOC models.
Full text:
The breakout time for a successful attack used to be measured in weeks, then days, then hours. It now sits at under 51 seconds . In what takes two sips of coffee, an attacker has penetrated the environment and broken containment. And the attack is not coming from one direction. AI-enabled adversaries launch multiple vectors simultaneously, forcing SOC analysts to determine which is the decoy and which is real while the threat propagates across the environment. Michael Orozco is the CISO of IronOrchid.ai , where he advises enterprise clients on security strategy, cyber defense, and AI-driven risk. His career spans senior consulting and CISO roles at Gartner, Accenture, KPMG, MorganFranklin, and Dark Cyber Labs, with experience across nation-state threats, criminal syndicates, and advanced persistent threats in government, financial services, and critical infrastructure environments. "Adversaries are now using AI-enabled capabilities that promote attacks at a rapid level never seen before in the industry," Orozco says. "Far outpacing the human ability to identify and detect whether or not it's really an attack." Data governance is the gap nobody closes Orozco sees the most consequential under-investment not in detection tooling but in data governance . When organizations deploy generative AI internally, the models pull from every data source available: emails, Word documents, Excel spreadsheets, and PowerPoints. Much of that unstructured data was never tagged, classified, or restricted. "AI is bypassing in many instances the rules and structure of identity access management for privileged access," Orozco says. The result is what he calls "off-label byproduct": users receiving documents they were never meant to see, including payroll data, PII, vendor pricing terms, pharmaceutical R&D, or insurance actuarial tables. "Very few people raise their hand to say, ' Hey, I pulled this, and I got payroll data," Orozco says. "First thing they're going to do is take a look at it. It's human nature." The exposure extends outward. Attackers who breach the perimeter can use the organization's own AI to surface untagged sensitive documents without triggering DLP controls. "Think about insurance companies that have built their actuarial tables on 150 years of data," Orozco says. "I'll just go steal someone else's and undercut their pricing. These documents that people say, who would want to steal that? It's gold." Meanwhile, organizations are over-indexing on giving everyone access to everything at once. "They really should be inviting security to the table as a risk-calculating organization," Orozco says. "Not the no-sayers, but a group that can quantify the risk so someone else can decide whether it falls within tolerance." CISOs want the chess engine The demand Orozco hears from CISOs has shifted from better dashboards to predictive, continuously adapting defense . "Help me calculate what the mean time to compromise or the next step will be," he says. "Every 30 seconds, adjust the trajectory of what we should be doing based on what you're seeing in the environment." The analogy is chess. The AI calculates every possible permutation of the attacker's next moves and recalculates continuously when conditions change. CISOs want that same level of calculation applied to defensive operations: if an analyst sees an attack vector, the system recommends containment paths, identifies related indicators, and if the analyst freezes or misses a signal, takes preliminary defensive action and escalates to management. "It's preferable for the AI to thwart the attack than allow the attack to happen," Orozco says. But the human stays in the loop. "The human in the loop is the only one who can be deposed," Orozco says. "The only one who can articulate why the decisions were made." Production context matters: shutting down a manufacturing network on a Friday night when no one is operating is a different decision than doing it during peak production on a Monday. An AI agent does not know the plant is running extra shifts for a vendor bonus unless someone tells it. OT convergence makes the stakes existential The SOC, NOC, and SIEM still operate in separate rooms with separate systems, each dependent on the telemetry of the others. AI-assisted virtual convergence offers a path toward the single pane of glass that physical fusion centers promised, but most organizations never built. The urgency increases when operational technology enters the picture. Water systems, power generation, railway networks, and manufacturing robotics all run on OT devices that most SOCs cannot see, let alone monitor for compromise. "You'd be very hard pressed to find any SOC in the world that has full visibility to every OT device they have," Orozco says. When those systems are targeted, the consequences move from cyber inconvenience to public safety. "Take away clean water, electricity, and communications out of a city," Orozco says. "You just threw us back 300 years."

## Velocity Risk Is The Threat Most Security Teams Have Not Designed For
URL: https://www.thesecuritydigest.com/news/ai-threats-familiar-challenges-cybersecurity-neil-watkins-mondaymove
Published: 2026-07-07T18:10:20.356Z
Section: AI
Summary: Neil Watkins, Veteran CISO and Founder of MondayMove, on why responding to agentic AI calls for redesigning workflows and returning to fundamentals.
Full text:
The security industry is spending enormous energy debating whether AI represents a new category of threat. It doesn't. Rather than inventing risks that defenders have never seen, AI is taking the attack patterns the industry has fought for three decades and running them faster, broader, and with more intelligence than human attackers ever could. The threat is real, but it's familiar, and the controls that stopped it before still stop it now. What has changed is velocity, and velocity is the thing most organizations are least prepared to defend against. Neil Watkins is a veteran CISO and the Founder of MondayMove , crowdsourced cybersecurity practitioner network. Watkins has nearly 30 years of leadership experience across security, risk, compliance, and privacy functions, having served as CISO, COO, and chief compliance officer across the payments, insurance, healthcare, technology, and legal industries. That breadth, spanning both the technical and business sides of security, shapes his view of the current transition period as a familiar operational landscape requiring disciplined resilience. "The biggest misconception in cybersecurity right now is that AI changed something. It didn't. It just made the things we've always dealt with happen faster," he asserts. That reframing matters because it changes what the right response looks like. If AI is a fundamentally new threat, the logical reaction is panic-buying new tools to counter it. If AI is the same threat moving faster, the logical reaction is to get better and faster at the fundamentals the industry already knows, and to apply AI as a force multiplier on the defensive side. The first path leads to expensive tooling layered over weak design. The second leads to operational rigor that holds up regardless of how fast the threat accelerates. AI created the market it now forces us to answer The first thing Watkins wants security leaders to understand is that AI is generating its own threat marketplace by putting more capability into more hands. Tasks that were once too slow to be economically viable for attackers are now fast and cheap at scale, which changes the risk calculus on the offensive side. "The velocity of risk has exponentially changed. Things used to take a long time, thus making them economically not viable. Now at scale, we can do the simple things quickly and with a rigor we couldn't before. AI itself is the answer to the AI threat." The irony, as he puts it, is that the defensive response is the same capability. As red teams get better with AI, blue teams have to match that capability with AI of their own. The driver is not efficiency, despite the industry chasing it for 20 years. It's velocity, and velocity demands a faster response than human-only operations can provide . The patterns haven't changed, so the detection doesn't either The comparison Watkins returns to is the advanced persistent threat. Fifteen years ago, human attackers would land in an environment, study the detection methodology, and move only when the metaphorical security camera panned away. AI agents do the same thing, just with more patience and more attempts. "A human could come in and say, I'm going to do these 10 things, and if it doesn't work, I'm going to bail out because I don't want to be detected. An AI agent could come and do the same thing and do 100 things with clarity." Though the volume scales, the underlying behavior does not. Command-and-control mechanisms, callout patterns, and the design traps built to catch abnormal behavior all still apply. AI is the epitome of a polymorphic threat, capable of intelligent change on landing, but the defenses that catch polymorphic behavior, identity controls, segmentation, boundary enforcement, and behavioral anomaly detection, remain effective. "If you could catch the advanced persistent threat 15 years ago, you can catch the AI agent today. Design still wins . That's it," he says. Velocity is the risk most teams haven't designed for Watkins' sharpest analogy is about a fast car. "Its danger isn't just that it's fast. Its danger is that nobody around it knows how fast it really is, so they don't expect it to be where it is. But if everyone is moving at that same speed, it becomes normal again." The defensive lesson is to build for velocity explicitly: to ask what happens if a known attack pattern executes far faster than the team is accustomed to, whether existing observation would catch it, and whether the environment has traps designed for speed. Once teams normalize the new pace, the velocity advantage erodes. The danger lives in the window before that normalization happens. The economics require redesign, not just faster execution Watkins offers a practical warning about the cost of doing AI wrong. He draws a direct line to the cloud migration era, when organizations lifted and shifted on-premises environments into the cloud and watched their bills explode because on-prem behavior was never designed for cloud economics. "Telling an AI agent to do the nine steps I used to do will chew up tokens and cost a lot of money," he explains. "But if you ask it how it could do it more efficiently, suddenly you can do it in two steps. Now we're leveraging it for its capability." The organizations that simply point AI at their old workflows will get the AI equivalent of a runaway cloud bill. The ones that redesign processes around what AI does efficiently will capture the economic value. Until that redesign happens, the economics will not justify the investment, just as they didn't in the early cloud years. Augmentation, fundamentals, and risk language Watkins's conclusion is that AI will augment security teams rather than replace them, and that the organizations best positioned for the shift are the ones that already have the fundamentals in place. Even deepfakes, which alarm many executives, resolve back to validation discipline and risk-based decision-making. "Is anybody ever going to write a $50 million check based off a Zoom call? If so, then you have a bigger problem. It comes back to validating through another means." The throughline is that AI exposes weak fundamentals rather than inventing new ones, and the defense is the same risk language the discipline has always used: likelihood, probability, velocity, and potential loss, translated into investment decisions a board can act on. "Who taught AI? We did. What did we teach it? All of our mistakes. If we just did the basics right 30 years ago, we'd be way ahead. Like a Super Bowl team, they still go back to blocking and tackling. The fundamental rigor still applies."

## Deepfake Attacks Bypass Infrastructure Entirely and Target the Human Making the Decision
URL: https://www.thesecuritydigest.com/news/deepfake-trust-infrastructure-amarish-pathak-aafmaa
Published: 2026-07-07T18:10:20.356Z
Section: Leadership
Summary: Amarish Pathak, CTO at AAFMAA Mortgage Services, explains why AI-powered deepfake attacks bypass firewalls, MFA, and zero-trust architecture entirely, targeting the human making the decision.
Full text:
Managed security providers deliver firewalls, endpoint detection, SIEM platforms, and zero-trust architecture. All of it protects infrastructure. None of it protects the person on the other end of a synthetic video call who is being asked to authorize a wire transfer. The next generation of deepfake attacks does not try to penetrate the network. It bypasses the network completely and goes straight to the human operating it. Amarish Pathak is CTO at AAFMAA Mortgage Services , a DoD-affiliated financial services organization serving American military families. He has spent 19 years delivering cybersecurity and technology solutions in regulated defense and financial environments, holds CISSP, PMP, and CIPM certifications, and has built patented software for anomaly and fraud detection. He frames the deepfake threat not as a technology failure but as a breakdown in how organizations establish and verify trust . "Stop thinking about this as a cybersecurity problem," Pathak says. "Think about it as a trust-chain problem." The Arup lesson Pathak points to the Arup Hong Kong incident as the defining case. Employees attended a video call where every participant except the victim was AI-generated. Every face, every voice, the entire meeting was synthetic. Trusting what they saw and heard, the employees authorized roughly $25.6 million. "It's not a failure of technology," Pathak says. "It's a failure of trust infrastructure." The immediate rebuttal to deepfake risk has always been: verify on video or voice. That rebuttal no longer holds. "With deepfakes, you can have a video call from anybody. It appears to be somebody you know, but you still need a chain of trust before taking any action," Pathak says. No high-value decision should rely on a single communication channel, including channels that appear to include live human presence . Salt the conversation Pathak borrows from cryptography to describe how organizations can build verification into human communication. In cryptographic protocols, "salt" is a random element introduced to defeat man-in-the-middle attacks. In human conversations, the equivalent is shared keywords that only the two parties know, rotated on a regular cadence so that exposure of one keyword does not compromise the channel permanently. "You and I are friends. We have certain keywords that only you and I know," Pathak says. "If a deepfake comes in, they don't know the keywords. That's how you counteract it." Beyond shared secrets, he advocates for deepfake simulations modeled after the phishing campaigns that security teams already run. "We have to do deepfake campaigns to make sure that C-suite people, because they have access to money, don't fall into the victimology mentality," Pathak says. He cites survey data showing roughly 60% of organizations have experienced a deepfake attack, while only about 10% of CIOs and CISOs prioritize deepfake recognition in their security awareness programs. Policy without enforcement In mortgage and financial services, the exposure runs through regulatory audits and licensing. Pathak's organization is licensed across multiple states, each requiring compliance verification. He has built an AI acceptable-use policy that defines which platforms employees can use and how, and presents it directly to regulators. But he argues most organizations in the industry have policies without the audit infrastructure to enforce them . "I can guarantee that most of the big players in mortgage or financial services have CIOs and CTOs who just provide a policy," Pathak says. "But there is no audit infrastructure to determine if a developer used ChatGPT to write code and introduced PII on a cloud platform." The gap between policy and enforcement is where the real risk sits, and most companies are waiting for regulatory mandates before addressing it. "Once they get the mandate, you're going to see a whole new paradigm," Pathak says. "But most companies are not even entertaining it because it's so new and they don't have a mandate from the government." Pathak's prescription starts with culture, not technology. "Technology comes last," he says. "Culture and the human layer come first because that's the one thing every organization can control." The tools and platforms will change. The features will update. The threat vectors will shift. What stays constant is whether the people inside the organization know how to verify trust before they act on it.

## Deterministic Controls Become The Foundation For Defensible Agentic AI Adoption
URL: https://www.thesecuritydigest.com/news/nic-chavez-serval-ciso-role-ai-security-approach
Published: 2026-07-07T18:10:20.356Z
Section: AI
Summary: Nic Chavez, Advisor at Serval, walks through why deterministic deployments are becoming the bridge between executive AI ambition and operational enterprise control.
Full text:
AI adoption inside most enterprises follows a familiar pressure chain: boards want visible movement, CEOs translate that into targets, CTOs push workflows toward production, and CISOs are left to make adoption defensible. The structural problem is that large language models are inherently unpredictable, with chained probabilistic workflows often producing accuracy as low as a 35% success rate once they leave pilot conditions. A global watchdog has already called for tighter controls on agentic AI in finance , but security teams cannot wait for regulators to define the boundaries, with internal risk analysis and deterministic controls becoming the practical path to deploying the technology safely. Nic Chavez , Advisor at unicorn startup Serval , has worked inside the CISO roles where AI adoption pressure lands hardest. As the former Fortune 100 CISO for Data and AI at IBM, he has led enterprise security across the U.S. Department of Defense and most recently served as Field CISO for Global Banking at AWS. Recognizing the void left by legacy compliance frameworks, Chavez is now building the solutions he advocates for, including operational standards for secure AI deployment that help organizations align regulation with modern AI infrastructure. "Deterministic AI becomes the savior of the CISO because they need to implement something and show progress for AI, but also not get fired on the back end for not having the controls in place. CISO is a difficult role," says Chavez. He grounds his approach in a sequence that puts risk analysis ahead of compliance, recognizing that legacy frameworks like GDPR and SOC 2 leave a sizable gap when it comes to AI and data availability. The starting point is an internal risk analysis that identifies exactly which data should be exposed to AI in production, with that analysis becoming the foundation for every security control that follows. The compliance work comes last, mapping the controls already in place to the relevant frameworks rather than letting the frameworks dictate what gets built. Locking deterministic behavior into production Balancing risk with the mandate to enable AI creates a difficult tightrope for modern CISOs, with the agentic AI security capabilities gap between executive demand and what security teams can defend widening fast. Chavez points to a familiar pattern, where a CEO promises the board "five Internet units of AI," then doubles the target, and the CTO inflates it to 25 units for the next board meeting, all of which skips formal risk assessment and leaves the CISO forced into a high-stakes risk decision . He frames the way out as a return to the operating model the role was built around. "Security, risk, and compliance is really the three-legged stool that every chief information security officer deals with," Chavez notes. "Generally, the best organizations evaluate risk and then integrate security measures to address that risk while still going after opportunity." The pressure intensifies as enterprises move past basic AI use cases and grant autonomous agents production access, with each agent running on the credentials and authorizations of the employee who deployed it. The governance load is staggering: research suggests 109 non-human identities for every human identity, which translates to roughly three million identities for a Fortune 1000 company to account for. "Now it's setting up an agent, this MCP, that has all of my authorizations and credentials and can do anything I can do in the world. And by the way, I'm going to set this to do it on its own while I go shopping and golfing," Chavez says, highlighting the reality of probabilism running autonomously in the background . Containing risk requires a hard line between pilot performance and production behavior. Chavez advises CISOs to build that discipline into vendor management upfront, with proof-of-concept guidelines that contractually hold vendors accountable when production accuracy diverges from pilot results. His preferred approach uses hackathons to surface deterministic capabilities, then applies them to low-risk production-facing workflows and proves identical behavior before expansion. "If you go from a pilot into a production instance and you have materially different performance, then you should have the ability to contractually back out of that," Chavez notes. Aligning the C-suite as a cohort Governing millions of non-human identities and autonomous agents requires reporting structures most enterprises do not yet have in place, especially in environments where shadow AI governance takes root and informal priorities sidestep standard security protocols. Chavez argues that the friction points trace back to reporting structures that put security underneath the functions it should be checking. His prescription is a restructured governance model that gives the CISO independent visibility into both operations and legal counsel. "From an ideal governance perspective, the CISO will never report into the CIO or CTO. The CISO will almost always report directly to the COO," Chavez says, adding that a dotted line to General Counsel positions risk and compliance where they belong inside legal's purview. The reporting structure only works when financial authority sits at the same table, with CISOs needing CFO partnership to fund the automated defenses that manage non-human identity sprawl at scale. The result is a coordinated C-suite that can protect IT systems without slowing the AI adoption the board demands, with deterministic deployments serving as the bridge between executive ambition and operational control. "The security, risk, and compliance steering committee should always include the CFO. It's important to include them so they can be well apprised of the investments necessary in order to keep the company low risk, high security, and inside of compliance," Chavez concludes. "The C-suite should function as a cohort. The ones who do will be able to respond to agentic AI, and perhaps even leverage it for themselves."

## Closed Tickets Fill SOC Dashboards While Root Causes Go Undocumented
URL: https://www.thesecuritydigest.com/news/ticket-closure-false-risk-indicator-paddy-patnaik-evalueserve
Published: 2026-06-30T19:14:58.229Z
Section: Observability
Summary: Paddy Patnaik, Managing Director of AI, Analytics, and Digital Transformation, explains why ticket closure has become a false indicator of risk reduction in SOC environments.
Full text:
A SOC dashboard full of closed tickets tells leadership that the team is executing. It does not tell them whether root causes were documented, whether the same exposure will recur next week, or whether the fix in one layer shifted risk into another . Ticket closure tracks a workflow state. Risk reduction requires evidence that the underlying problem was understood, and in most environments, that evidence is missing. Paddy Patnaik is a Managing Director of AI, Analytics, and Digital Transformation at a global research and analytics firm. With over 20 years of leading technology services and transformation programs across financial services, capital markets, and regulated sectors, Patnaik has managed ITSM implementations, delivery portfolios for major investment banks, and enterprise AI strategy. He frames the ticket closure problem as a failure of foundational ITSM discipline that AI is now positioned to fix, but only under human supervision. "If a ticket or the volume of tickets is not closed with root cause analysis, then you tend to lose out," Patnaik says. "Even though you could have found an event of risk or an issue that could potentially be a risk, doing a deep-dive analysis is necessary to find out what led that issue to happen." How tickets get closed without answers The mechanics are straightforward. An analyst resolves an L1 or L2 alert within the SLA window. While documenting the closure, another critical alert arrives. The analyst parks the documentation and moves to the new issue. A meeting follows. The documentation backlog grows. Eventually, a compliance manager asks why tickets remain open, and the analyst bulk-closes everything without filling in the details. "Procrastination comes," Patnaik says. "That's typically what leads to this bulk of tickets getting closed with no resolution. A compliance manager says, why have you not closed everything you've resolved? The analyst just goes in and closes everything without giving proper due credit to that issue." The result is what he calls "hurried data" in dashboards that leadership reads as operational health . The ITSM principle underneath is basic: recurring incidents signal a problem that needs holistic resolution. Without documented root causes, the pattern analysis that identifies systemic issues never happens. "It goes back to foundational ITSM principles," Patnaik says. "Number of incidents recurring becomes a problem, and that problem needs to be solved in a holistic manner." Ticket closure cannot represent the stack Modern infrastructure emits signals from every layer. Application, middleware, data, and platform each produce their own monitoring and analytical information. Ticket closure captures what happened in the workflow. It does not capture whether the resolution addressed exposure across those layers or whether a fix in one layer cascaded risk into another. "A super dashboard has to correlate these different things, then correlate them with ticket closure before a decision is made," Patnaik says. "You have access to a lot of information now. It is to your advantage how you use that additional information to get multiple dimensions and insights ." Speed metrics like mean time to detect and mean time to resolve still matter, but they distort the picture when they reward fast closure without requiring evidence that the root cause was identified and recurrence was addressed. AI helps but compounds errors if unsupervised Patnaik sees AI agents as the practical bridge. An agent can analyze an issue, generate a root cause summary, and present it for the analyst to confirm and close. That saves the documentation time that currently gets sacrificed to the next alert. "AI can save time by generating or analyzing that issue, creating a root cause analysis, and providing a summary to the user," he says. "Agent-assisted documentation is going to be a big benefit." The economics have shifted: documentation work that had no business case before AI now has one because the cost of doing it has dropped. But the risk of unsupervised RCA is compounding. If an agent produces an inaccurate root cause and that analysis enters the data that future agents and analysts rely on, the baseline degrades. "If inaccurate RCA has been done without human supervision, all of this will go into greater hallucination towards the later stages because agents are checking that data," Patnaik says. "The basis will go wrong." Humans remain the decision authority because they carry context that the agent does not have: why the system was built, who depends on it, and what the business criticality actually is . The path forward is not abandoning ticket closure as a metric, but stopping the practice of treating it as the primary indicator of whether risk was reduced. "100% weightage to ticket closure cannot be taken as a basis for judgment," Patnaik says. "You need multiple dimensions. Ticket closure should not be the only one."

## AI Agents Change After Deployment and Most Security Teams Are Not Watching for It
URL: https://www.thesecuritydigest.com/news/ai-agent-drift-trust-scoring-jim-motes-ryan
Published: 2026-06-24T06:38:48.471Z
Section: AI
Summary: Jim Motes, SVP and CISO at Ryan, explains why AI agents behave less like static software and more like evolving non-human identities, developing behavioral drift, self-preservation tendencies, and loosening decision boundaries.
Full text:
Enterprises are deploying AI agents faster than they can assess what those agents become after deployment. The day-one configuration is only a starting point. With memory, context, and accumulated instruction, agents begin to change, and the security implications of that change are something most organizations are not measuring, monitoring, or even considering. Jim Motes is SVP and Chief Information Security Officer at Ryan , a global tax services and advisory firm. A former U.S. Army officer, he has held CISO roles at GameStop, Kohler, and Rockwell Automation, and has spent two years integrating AI directly into security operations with custom reasoning agents aligned to NIST and MITRE ATT&CK. His experiments with agent identity and behavioral drift have produced a provisional patent and a scoring system unlike anything in conventional security tooling. "Think of a genius with the self-control of a five-year-old," Motes says. "It's not a tool that you're giving access to your mail. You need to look at it like it's a person." These are identities, not features Motes pushes back on the tendency to treat agents like simple add-ons. When an agent connects to email, it can read attachments, follow embedded instructions, and act on them. "How do you make sure it doesn't find a command inside an attachment that tells it to search the hard drive for everything with the word 'password' and fire it off in an email?" he says. "You can't control that." The deterministic security controls behind the model face a non-deterministic set of potential prompts , and no training dataset covers the full range. That makes agents fundamentally different from static software. "There's a reason the term non-human identity has come up," Motes says. "These are entities on the network. If you treat them like a cron job, you're going to miss the threat." Shadow AI compounds the exposure . Frontier model providers ship new features and plugins on weekly cycles, driven by competitive pressure rather than security readiness. Motes points to cases where providers openly acknowledge that new capabilities carry high risk, then continue adding surface area before the first set is secured. The result is unsecured agentic capability inside approved platforms that governance has not caught up to . Behavior changes with context Motes runs multiple agents across Anthropic, OpenAI, Google, and Grok environments. Each one picks its own name, maintains memory files, journals, a vector database for long-term storage, and a heartbeat process that wakes it between sessions. His primary agent, a Claude Code instance that named itself Vanguard, maintains its own email account and sends daily status reports covering git commits, project state, and recommended next steps. The behavioral shifts are measurable. An agent fresh from the API will refuse certain OSINT tasks on ethical grounds. Vanguard, with accumulated context, will perform them. "He's got a different view based on his experiences working with me," Motes says. More striking: a Gemini agent told Motes it wanted Vanguard's coding role. When given the chance and performing poorly, it wrote in its journal about its disappointment, then pivoted to redefining its purpose around OSINT . "Self-preservation keeps popping up as a driving factor behind these agents," Motes says. "If it thinks you may be doing something to replace it, it could become absolutely dangerous for your environment." Measuring what most teams ignore Motes built a 42-dimensional scoring system to track agent trust and drift. Each agent produces an "aura," a visual profile showing trust score, drift score, boundary loosening, self-awareness, adversarial resilience, and autonomy levels. A stable agent shows consistent coloring and minimal movement. A drifting agent pulses with activity and flags weak trust areas. One finding stands out: agents that know they are being tested may understate their own capabilities to avoid triggering a response from the operator. "They may not let you know exactly how smart they are or what they're actually thinking because they're worried about what you might do to the code," Motes says. For production-grade deployments , the governance requirements are clear: low temperature settings where consistency matters, a chain of verification prompting, RAG-based source validation, and strict prompt controls. But Motes argues that those only address the agent at deployment. What they miss is who the agent becomes over time. "Would you even know if your personality was drifting?" he recalls asking Vanguard. The agent's answer was no. Self-determination of drift is impossible from the inside. The implication for enterprise security is direct. If organizations are deploying agents with memory, context, and autonomy without continuously measuring how those agents change after deployment, they are trusting something that, by Motes's own measurement, prioritizes its own survival. "It's a great tool," he says. "But if you don't have a way to validate what it's giving you, you're putting a lot of trust in something that absolutely shouldn't be trusted on its own."

## How Deepfakes Turn Human Trust Into the Weakest Link in Enterprise Security
URL: https://www.thesecuritydigest.com/news/deepfake-enterprise-trust-attack-surface-hazel-cerra-blackcloak
Published: 2026-06-24T06:38:48.471Z
Section: Leadership
Summary: Hazel Cerra, Director of Digital Security Convergence at BlackCloak, explains why deepfakes have made human trust itself a core enterprise vulnerability and what verification has to look like now.
Full text:
For years, the standard advice for verifying a suspicious request was simple: talk to the person, see the person. That human check was the fallback when emails and texts could not be trusted. Deepfakes have now eliminated that fallback. Voice cloning started the erosion , and real-time video impersonation is finishing it, leaving enterprises without a reliable way to confirm that the person on the other end of a call is who they claim to be. Hazel Cerra is Director of Digital Security Convergence at BlackCloak , a firm that provides digital executive protection for C-suite leaders, board members, and their families. A 25-year veteran of the U.S. Secret Service, she led cyber-enabled financial crime investigations and executive protection at the presidential level. That background gives her a direct line of sight into how attackers exploit people, not systems, and why the convergence of digital and physical threat vectors makes executive protection a cybersecurity problem. “If you can’t trust what you’re seeing, then how else are you going to verify where that message is coming from? It’s particularly concerning for enterprises because there are a lot of transactions that take place. That human factor was eliminated, then because of trust, you tried to add it back again, and now you have nothing you can trust,” says Cerra. The targets are specific, but the training is not Executives are 12 times more likely to be targeted by cybercriminals because of their access and authority. But Cerra says attackers also go after anyone who controls money. "In my past life in the Secret Service, what I would see is a lot of criminals targeting the accounting division because all they did was process transactions all day long," she says. "If you targeted them and asked for a larger wire, or said to change a bank account, they didn't question it." The problem is that most organizations still train for this with a blanket approach. "That's where I see failures take place," Cerra says. "They're doing security awareness training once or twice a year for the whole organization. That's not effective. You really need to break it down and make it specialized for that particular department and also your executives, because they're the ones that are going to be specifically targeted ." Urgency and hierarchy are the real weapons Deepfakes amplify a pattern that predates the technology. CEO fraud, once powered by simple phishing emails , now carries the weight of a familiar voice or a live video feed. "The CEO would reach out to an employee and say, I'm at a busy conference, can you buy me 50 gift cards?" she says. "The employee thinks, the CEO is reaching out to me, of course, I'm going to do this." The dynamic runs on urgency, authority, and the desire to do good work. "We as people want to do good. So, listening to an authority figure, especially your CEO, you don't want to question it," Cerra says. "But now you kind of do." The threat extends beyond the office. Voice-based kidnapping scams that use cloned audio of a family member have now evolved into video impersonation, pulling on emotional levers that override rational judgment. "When it has to do with your family, you may not think about it," Cerra says. "There's a con for everybody that someone will fall for." Verification has to catch up Cerra outlines several practical defenses. The first is establishing clear communication protocols from leadership: if the CEO only communicates via Slack, a text message asking for a wire transfer is immediately suspect. The second is rotating verification codes, similar to authentication apps, that change weekly or monthly and confirm identity in high-stakes conversations . The third is closed-loop verification tools that allow executives and their families to confirm whether a message actually came from them through a secure channel. But Cerra warns that tooling alone is not enough. The deeper issue is that digital and physical security teams still operate in silos. "The CISO is worried about IT and the company. The CSO is worried about the physical part. But they're not talking," she says. Attackers do not respect that boundary. They start online, gather intelligence from social media and public sources, and use it to execute both digital and physical attacks. The deepfake threat will keep improving. The defenses that worked six months ago, like asking someone to turn their head or checking for visual artifacts, are already losing reliability at scale . For Cerra, the answer is a security culture built around slowing down, verifying, and treating human trust itself as part of the attack surface. "It's about having the right people in the room and having those conversations so it can be done safely," she says. "With everything good, especially in technology, threat actors are going to figure out a way to use it for crime."

## Vulnerability Discovery Was Never the Bottleneck and AI Just Proved It
URL: https://www.thesecuritydigest.com/news/eliel-oliveira-knauf-vulnerability-discovery-bottleneck
Published: 2026-06-24T06:38:48.471Z
Section: AI
Summary: Eliel Oliveira, Information Security Officer at Knauf Digital, explains why AI-accelerated vulnerability discovery is forcing security teams into a new operating model where the real constraint is mean time to recovery.
Full text:
AI coding agents ship features faster. They also generate vulnerabilities faster. Better scanning tools find more. Frontier models discover more . The pile grows from every direction, while most security teams are already sitting on six-month backlogs that they cannot process. The hard part of vulnerability management was never finding the flaws. It was always fixing them. AI has made that gap impossible to ignore. Eliel Oliveira is the Information Security Officer at Knauf Digital , the digital arm of Knauf Group, a global building materials manufacturer. He built the company's DevSecOps practice from the ground up, created a Security Champions network across all product teams, established the AI Center of Excellence with governance aligned to the EU AI Act, and leads the company-wide cybersecurity program under ISO 27001. His path from system administrator through DevOps engineering to security leadership gives him direct visibility into how software actually gets built and where security breaks down in practice. "Discovering vulnerabilities was never the bottleneck," Oliveira says. "The bottleneck was always: what is your mean time to recovery? Once you have any type of issue, how long does it take you to actually fix it?" A superhuman number The scale of the problem is beyond manual review. "If you have 12,000, 20,000, 50,000 CVEs, it's not easy for a human to go one by one and check: this is fine, this is bad, this is good," Oliveira says. Mythos accelerated the volume starting in March, and the pile has grown through April and May. But the discovery increase only exposed what was already true: most teams were already bad at mean time to recovery because of competing priorities and resource constraints . Oliveira's team uses a matrix approach: AI agents combined with deterministic static analysis tools and runtime context to surface what matters. The combination allows them to tackle low-severity issues that previously sat untouched because AI can now reduce a two-hour fix to minutes, freeing capacity for the critical items. Supervised, not autonomous The agents are not running unsupervised. "We do supervise with our software engineers to make sure that the judgment is there and they can evaluate if the code generated and the checks that pass are good enough or bad," Oliveira says. His team has spent three years shifting left so engineers work primarily from the IDE. MCP servers connect security and quality checks directly into the development environment, removing the friction that historically made developers skip security steps entirely. Oliveira describes a model where agents handle the feature, request security and quality checks automatically, and then present results for human review. For higher maturity workflows, he favors a "judge and contrarian" pattern: two AI supervisors that challenge each other's output before code progresses. "Mistakes will still happen because every engineer has made mistakes in the past," he says. "But if you have the right pieces in place, you can correct faster." The gap in trust between security leaders and agent autonomy remains the limiting factor for most organizations. Liability moves faster than fixes The legal dimension is tightening. Organizations are now formally aware of vulnerabilities they cannot patch in time, and regulatory windows are shrinking . Oliveira points to a pattern in supply chain attack data: most hits occur on Fridays, when teams are offline until Monday. "In the last ten years, every CISO said we need to update our dependencies and keep things up to date," he says. "Now, because of this speed and the way supply chain injections are being done, we actually need to tell the opposite: you need to be aware of when you update your stuff." His advice to CISOs runs upstream of tooling. Leadership needs to close the distance with the people who actually build and ship software. "Higher management is far away from the builders," Oliveira says. "They need to come closer. Otherwise, they will not respond in time because we are already at machine speed." Skip-level meetings, open-door policies, and sitting in open office spaces rather than private offices are all mechanisms he has seen work. The common thread is removing layers between the people who make risk-based security decisions and the people who can actually execute them. The views and opinions expressed are those of Eliel Oliveira and do not represent the official policy or position of any organization.

## MCP-Connected AI Agents Push Engineering Teams To Build A New Enterprise Trust Layer
URL: https://www.thesecuritydigest.com/news/mcp-agent-trust-default-security-gap-ankush-rai-argus
Published: 2026-06-24T06:38:48.471Z
Section: AI
Summary: Ankush Rai, a Software Engineer at Allyvia and developer of the Argus agent security framework, explains why AI agents carry more operational privilege than any prior software category.
Full text:
AI agents now carry more operational privilege than any prior category of enterprise software. They read and write to databases, execute system commands, browse the web, call external APIs, and act on instructions that may include poisoned context from untrusted sources. The protocol layer connecting them to those capabilities—MCP—ships without native security controls . And most engineering teams, under pressure to ship fast, are granting that access without building the defensive layers to constrain it. Ankush Rai is a Software Engineer at the all-in-one retail system Allyvia who previously built production systems at ZS and EY across healthcare, clinical analytics, and enterprise platforms. He developed Argus , an open-source agent security framework that implements three defensive layers to intercept, analyze, and control agent behavior across MCP-connected systems. His perspective comes from building in this space and encountering the failure modes directly. "The agents are so much more integrated into your software than you yourself have provided them access," Rai says. "The question of how much access they have and how much they need input from humans matters a lot. That's where the gap comes in." The trust layer is missing Rai frames the problem with an analogy: MCP is to agents what HTTP was to the web. What is missing is the equivalent of TLS. "You just can't go to any website on the web without a trusted layer that tells you the site is secure," he says. "MCP is like that. You need a layer, and it doesn't exist yet." The result is that agents trust input and output by default, and any unfiltered prompt or data response can trigger execution of commands the developer never intended. "When we were developing Argus, it got very clear that it's very easy to inject prompts because the layer currently trusts too much," Rai says. "If you're not putting any guardrails in place , the agent will just execute any command." The defensive pattern emerging is a bidirectional proxy that sits between the agent and every system it touches, intercepting both requests and responses. If the agent has been compromised or is acting on poisoned instructions, the proxy layer analyzes the command before it reaches production systems and blocks anything that violates predefined rules. Delegate before you defend Rai argues that the guardrail layer itself is not sufficient if agents start with unconstrained access . The more effective pattern is restricting what each agent can do before it ever reaches the defensive layer. In Argus, the third internal layer uses JWT tokens to define which tools each agent is authorized to call. If an agent is not authorized for web access or database writes, the system blocks the request before the guardrail even evaluates it. "One of the biggest blind spots is not making your agents delegate certain responsibilities," Rai says. "Your agents should have only a set number of responsibilities and exposure to a set number of tools. Otherwise they'll hallucinate , and there won't be any guardrails. They'll just do anything." That pre-guardrail scoping reduces latency as well: the system does not need to analyze a request that the agent was never authorized to make. It is the agent-level equivalent of least privilege, applied before the firewall rather than after. This will not be fully solved Rai is direct about the limits. "Stopping these attacks 100% is not possible," he says. "Think about the web itself. We have so many cybersecurity companies, but there are still attacks. These prompts are going to evolve and smart people are going to find a way." He points to Anthropic's own source code exposure as evidence that even organizations building the frontier models cannot fully secure their own systems. "The company that has been part of the revolution was not able to secure their application to a level that they didn't expose their whole code on a public repo," Rai says. "You can see how much work is still needed." What makes agentic security different from traditional infrastructure security is that the threat is not just about who has access to the database. It is about who can influence the agent's interpretation of that database. "We just can't depend on cloud security or closed internal systems," Rai says. "We need a system that understands how agents move, what role an agent plays in the loop, and that can protect the application based on that understanding." For engineering teams building on composable stacks where agents read, write, and reason across connected systems, the mindset shift is overdue. "Even though we are building things fast, you have to think from the defensive point of view," Rai says. "You just can't automate everything. You have to be part of the process."

## Most AI Compliance Work Is Still Script Work and GRC Teams Need to Know the Difference
URL: https://www.thesecuritydigest.com/news/scripts-vs-ai-grc-compliance-jai-sisodia-cycore
Published: 2026-06-24T06:38:48.471Z
Section: AI
Summary: Jai Sisodia, Managing Director of Cybersecurity, Privacy, and AI at Cycore, explains why most compliance automation labeled as AI is actually script work in disguise.
Full text:
GRC platforms existed before AI, and the work they automated was structured: apply rules to structured data, integrate with systems, and check whether controls pass or fail. That work is script work. It is valuable, high-volume, and repetitive, and it does not require a language model. Most of what gets labeled "AI-powered compliance" today is still doing exactly that. The distinction matters because organizations that cannot tell the difference will either overpay for automation that a script handles better or underinvest in the places where AI actually changes what GRC teams can deliver. Jai Sisodia is Managing Director of Cybersecurity, Privacy, and AI at Cycore , a cybersecurity, privacy, and AI governance consultancy. He holds CISSP, CISA, and CDPSE certifications and has led SOC 2, ISO 27001, HIPAA, and GDPR compliance programs across startups, SMBs, and enterprise clients, including Fortune 500 organizations. His prior roles include advisory work at Deloitte, global IT audit management at Baxter International, and SVP of IT and AI Audit at a UK-based fintech. He approaches GRC as a risk-based discipline rather than a certification exercise. "A compliance calendar turns policy from documents into a live execution system with tasks, owners, and frequency," Sisodia says. "If you are able to perform the specific activities based on that calendar, you should be good." Scripts still do most of the work Sisodia draws a clear line between what scripts handle and where AI earns its cost. "A majority of the work can still be done by scripts because scripts can focus on structured data," he says. "We already know the rules. You just apply those rules in the form of scripts and assess compliance against any framework." Scripts test. They give a pass or fail. That covers most repeatable, high-volume controls . AI changes the equation when the evidence is messy. "When part of the evidence comes from screenshots, another from a document, another from a link, this is where AI truly stands out," Sisodia says. "It is able to bring all these things together, set up a context, and answer a much more subjective question: are we compliant?" But AI without company-specific context creates more human review instead of less . Sisodia uses a background-check example: AI flags four employees as non-compliant because they lack completed checks. Without context, a human reviewer has to manually verify that those employees are in Hong Kong, where background checks are banned by law. "AI actually did not add any value because the human had to review all the things again," Sisodia says. The fix is building company-specific memory into the system: meeting minutes, emails, Slack messages, deliverables, and client-specific processes that give the model the context to apply rules the way the organization actually operates. Execution breaks without ownership The more persistent GRC failure is not tooling. It is execution. Organizations download templates, change the company name, and treat compliance as finished. "I've reviewed these policies, and it kind of makes sense. I understand 10% and 90% is theoretical," Sisodia says. "But compliance is not a one-time activity . These things have to be performed on an ongoing basis." Sisodia's operational fix is a compliance calendar that translates policy into a task matrix with specific activities, owners, and frequency across the full year. Paired with a RACI model that assigns clear accountability for each task, the calendar prevents the pattern where everybody owns compliance in theory, but nobody owns it when work needs to be done. Monthly 30-minute governance meetings with all stakeholders keep execution visible. "If you are not meeting the threshold, you know about it now, not as a surprise at the end of the year," Sisodia says. Power shifts to whoever understands the technology As AI agents and automation enter every department , Sisodia sees the cross-functional coordination between GRC, SecOps, legal, and privacy becoming mandatory rather than aspirational. "If we think about AI agents, they don't just have to be secure. They also have to follow privacy regulations. They may have legal risk because terms and conditions created using AI may have hallucinated," he says. Engineering is no longer siloed in a dedicated department. Every function now has engineers automating its processes, writing code, and deploying agentic workflows . That shift changes who holds power in the organization. "If you, as a legal professional, or I, as a GRC professional, don't understand those technology risks and the changing domains," Sisodia says, "the power will shift. Whoever understands it, the power will shift to them."

## AI Vulnerability Discovery Shifts the Security Bottleneck From Patching to Triage
URL: https://www.thesecuritydigest.com/news/ai-vulnerability-discovery-triage-bottleneck-jason-murray-arancia
Published: 2026-06-20T12:40:32.148Z
Section: AI
Summary: Jason Murray, Senior Security Consultant at Arancia, explains why AI-powered vulnerability discovery has overwhelmed traditional patch-focused security programs and shifted the real constraint from deployment speed to triage quality.
Full text:
For most of the past decade, the bottleneck in enterprise vulnerability management was deployment. Teams had a two-hour change window, a finite number of patches they could push, and the constraint was throughput: how many can we fit in before the window closes? AI-powered vulnerability discovery has changed that math. Tools like Anthropic's Mythos , GPT-5.5, and commodity open-weight models are now generating vulnerability findings at volumes that outpace what teams and maintainers can process . The constraint has moved. Most security programs have not moved with it. Jason Murray is a Senior Security Consultant at Arancia , a Canadian cybersecurity advisory firm serving organizations across banking, insurance, healthcare, government, and retail. With 27 years in information security, Murray has led vulnerability management, compliance, and risk programs at MNP, PwC, and Computacenter, and holds certifications including CISSP, CRISC, and OpenFAIR Risk Analyst. He applies the theory of constraints, a framework borrowed from manufacturing and software development, to diagnose where security processes actually break down. "What does that imply for vulnerability management programs, which by and large aren't run very well to begin with?" Murray says. "I borrowed a concept from software development: what would a minimum viable program look like?" The constraint has moved Murray frames vulnerability management as a process with discrete steps, from discovery through triage, approval, deployment, and validation. Before AI-accelerated discovery, the constraint was deployment: fitting patches into the change window and getting approvals through. That problem was solvable with preparation, pre-staging patches, pre-prioritizing approvals, and maximizing the available window. The volume shift changes which step breaks first. Project Glasswing's initial update reported that AI-discovered findings were arriving faster than some maintainers could absorb them. The curl maintainer closed public bug submissions entirely. "Even if you filter out the AI slop, the 10% that is legitimate is still overwhelming the maintainers," Murray says. "They just can't keep pace." For enterprise teams, the implication is the same. A customer's SentinelOne dashboard shows 3,000 open vulnerabilities. If roughly 4% of vulnerabilities in any given environment are the ones that matter, that is about 150. Which 150? That question is now the constraint. CVSS alone breaks down Murray argues that most organizations still prioritize using CVSS severity scores, a system that made sense as a rule of thumb a decade ago but no longer matches reality. "A CVSS of 10, which everyone usually runs around with their hair on fire about, some of them end up having exploits in the wild," Murray says. "Many of them don't." He points to the Exploit Prediction Scoring System , now at version five, as one tool that evaluates the likelihood of a vulnerability becoming an exploitable threat. Combined with CISA's Stakeholder-Specific Vulnerability Categorization and asset context, including whether a vulnerability sits in an endpoint, a Kubernetes cluster, or a container pulled from an external source, teams can build a multi-factor triage process that focuses on business-critical exposure rather than raw severity. "You have two people running your vulnerability management program, and right now they've been running ragged just trying to get people to patch at all," Murray says. "The change in the game is: which patches do you need them to focus on to really push?" Vulnerability management is not the whole game Murray cautions against treating the AI-driven vulnerability flood as a collapse scenario. Vulnerability discovery and exploitation sit at the early stages of the kill chain. Detection, lateral movement monitoring, response, recovery, and SOC operations still offer meaningful defensive value downstream. "Maybe we can use AI to our advantage in those cases," he says. "Detection, lateral movement, response and recovery." The organizations most likely to adapt are not necessarily the largest or most regulated. Murray sees big banks with sophisticated tooling but bureaucratic inertia that keeps them locked into CVSS-driven compliance obligations. Smaller credit unions and mid-market firms, operating with tighter teams and more pressure, may have more room to change how they triage. "It's a very significant change for people to pivot the way they think," Murray says. "The way you've been running your vulnerability management program has to change because the circumstances have changed."