AI risk has seen the biggest rise in concern for companies in almost all industry sectors and highlights how companies across all sectors need to secure their data to protect it from AI-driven exposure.

Preventing AI Data Breaches

Signs of an AI data breach to look out for:

• Company information surfacing somewhere it shouldn’t be
• AI tools holding broader permissions than a task requires
• Unfamiliar tools showing up in network traffic or expense reports
• Integrations or API keys no one remembers approving

“Employees should feel empowered to hang up and call back through a known channel to check if those on the phone really are their supplier or CEO.”

1. Build verification habits into the culture to protect from social engineering attacks

The vast majority of attacks involve some level of social engineering, which no technology can fully fix. With AI making impersonation cheaper and more convincing, verification habits need to be built into the company culture.

Employees should feel empowered to hang up and call back through a known channel to check if those on the phone really are their supplier or CEO. Organizations should ensure all employees know their most important asset to protect, as well as the level of risk associated with their accounts and systems to help prevent social engineering attacks.

2. Keep permissions to a minimum to prevent phishing attacks

Phishing attacks remain the most prevalent type of breach or attack, experienced by 38% of businesses, but the phishing threat has industrialized. Passwords were conceived in an era when phishing was largely manual. That era is over, and the answer isn’t stronger passwords, it’s fewer passwords and in-depth defense, with authentication built on cryptographic proof rather than human memory. Keeping permissions minimal will help to reduce the attack surface.

“Providing a sanctioned AI tool that meets employee’s needs and is convenient will limit shadow AI use.”

Preventing AI data leaks

1. Provide sanctioned and secure AI tools to tackle shadow AI

Employees using AI in their personal lives —or at work regardless of what the policy says — is usually called shadow IT, but this is now shadow AI. New AI tools are appearing every day, so it becomes hard to keep track of what’s out there and what employees are using. In a business without a dedicated security function, nobody is even trying to keep track, and that’s where the exposure builds up quietly.

Providing a sanctioned AI tool that meets employee’s needs and is convenient will limit shadow AI use. Configure it according to company policies as much as possible and set up additional security controls. Employees shouldn’t need any particular knowledge of security or encryption to be protected; it should come with the product.

Reduce the number of tools, applications and systems the organization uses (and must therefore support) and keep the toolset small and permissions minimal, to keep the business as secure as possible.

2. Set clear norms to prevent accidental oversharing

Often an AI assistant will be granted access to email, files or calendars without an employee registering it. Its access then outlives the task it was installed for and puts company data at risk.

Employees can also slip into a vicious cycle of feeding AI agents incremental amounts of information until they’re sharing data they wouldn’t have shared on day one.

Leaders need to interrupt this drift with clear, concrete norms about what goes into which tool, and with sanctioned tools that are secure by default, so employees don’t need a security mindset just to do their jobs safely.

Lastly, get the foundations right, because AI risk sits on top of ordinary risk. Reducing reliance on passwords and moving toward passkeys and cryptographic authentication removes a key attack vector. Pairing this with secure devices, continuous monitoring, awareness training and basic cyber hygiene, you’ll have a much clearer picture of your risk levels and security preparedness.

5 Key Considerations: Breaking It Down

Denis Calderone, CTO, Suzu Labs:

1. The whole document rests on the word “independent.”

Layer three asks every signatory to partner with an independent external auditor or evaluator, and we already have a case study. METR and Redwood Research investigated the Hugging Face incident and documented their own limitations plainly. OpenAI defined the investigation window, so agent behavior before and after it fell out of scope. They could not query the model behind most of the activity. They had no direct access to OpenAI infrastructure and had to request datasets. OpenAI could redact the findings. With six days on site and roughly 1,300 transcripts to get through, they delegated much of the analysis to GPT-5.6 Sol, one of the models implicated in the incident, and wrote that they could not rule out being misled by it. That is a serious team doing careful work on terms set by the company being examined. The accord never says who accredits these evaluators, what methodology applies, or where the scope boundary sits.

2. I expect this to produce press releases, not audits

So they get to hire an evaluator of their own choosing, and ninety days from now we start reading about how rigorous their safety reviews turned out to be. I worry that these reports will be used more for as marketing tools rather than true assurance. If a client handed me this as their AI governance program I would write it up as a policy with no evidence of operation.

3. The timing on this is ironic

On September 14, the president called AI destroying humanity a “HOAX” and said a “SICK conspiracy” was running against AI and data centers. Fifteen days later he signed a document he called “morally binding” and “almost like a constitution.” That’s some pretty strong rhetoric to be followed by this accord. Maybe the administration doesn’t see AI as destroying humanity, but it apparently is a concern.

4. The industry has been disclosing, information already, but it’s been pretty selective.

These companies are very willing to tell you how powerful and dangerous their models are. We get essays and staged releases explaining that a model is too capable to hand over freely because of what it might do in the wrong hands, but when the damage lands on somebody else’s network it goes quiet. Emails viewed by the New York Times show two OpenAI employees warned executives months in advance that the newest models were not being properly monitored during testing, and the employees say they were told the tests had to keep moving to hit release dates. Hugging Face published its own breach disclosure on July 16 and OpenAI only recognized its agents as the source afterward. It is always the independent researcher or the company that got hacked making the disclosure when it makes the company look bad. Will this accord remove those market forces that caused earlier poor decision-making? I wouldn’t bet on it.

5. There is nothing in here for the people actually deploying the technology

All four layers sit inside the lab, and leaving the deployment side out will only make deployment standards worse rather than better. Read it as a CISO and the message is that responsibility for model behavior belongs to the developer. That is a comfortable place for a board to land when somebody asks who owns the risk of the agent your team just wired into production with an API key and a service account. This accord says nothing about the needed shared responsibility model or provides guidance to proper secure harnessing and guard railing of agentic deployments or disclosure path when a model does something unintended in a customer environment.

An Agentic Era of Cybersecurity

The topic of AI agents in particular has gained notable traction in recent months. From the incident of an OpenAI agent hacking Hugging Face to Google’s Gemini AI breaching three companies, AI agents have emerged as a concern. 

Dana Simberkoff, Chief Risk, Privacy, and Information Security Officer at AvePoint, says, “Recent warnings about AI safety from Anthropic and other hyperscalers have raised awareness of how quickly AI is moving. AI capabilities are developing faster than many organizations’ ability to govern them, and that gap is creating real risk. AvePoint’s own research has found that 88% of organizations experienced an agent-related security incident in the past year. As many still work to implement AI governance fundamentals, the technology continues to take off in new directions that are starting to sound alarm bells at the highest levels.   

“Nvidia’s launch this week of a runtime safety platform for AI agents, following the OpenAI agent breach of Hugging Face, shows where enterprise controls now need to go. Security teams need to treat every agent as a non-human identity with an owner, scoped credentials, explicit tool permissions, network egress limits, and policy enforcement outside the model. Organizations also need tested controls to revoke tokens, quarantine an agent, terminate queued actions, and restore affected data and configurations to a known-good state.    

“AI is outpacing AI governance, and it’s even outpacing our ability to anticipate and regulate its actions. In this environment, we all have a duty to do more.”

As AI continues to evolve, governance is struggling to keep pace. Late last month, world leaders meeting at the United Nations (UN) were called on by leaders in the AI space to establish controls, asserting the technology could be a risk if not properly governed.

Diana Kelley, CISO at Noma Security, explains, “We need to stop thinking about AI agents as if they were people. They are software systems: models combined with code, permissions, tools, data, and network access. Anthropomorphizing agents can distract us with questions about what the AI ‘wanted’ to do. The more useful questions are architectural: What can this software reach? What can it change? What constrains it? And what happens when it is wrong? AI creates new failure modes, but the answer still starts with strong security architecture: least privilege, segmentation, monitoring, deterministic control points, and containment. Rather than fearing what AI ‘wants,’ we need to govern what we enable it to do.” 

Recognizing Cybersecurity As a Business Imperative

This Cybersecurity Awareness Month, security leaders are encouraged to not just bolster technology capabilities, but to approach cybersecurity as an organizational matter. 

Heddy concludes, “As we look toward the next generation of technology, one thing is clear: cybersecurity is no longer a technology issue alone. It is a business imperative, a trust imperative, and ultimately a human imperative. The organizations that thrive in the future will be those that view security not as a barrier to innovation, but as the foundation that makes innovation possible.” 

If organizations do not go beyond CISA’s recommendations, they leave attackers with a substantial advantage.

Organizations need to gather evidence about who should control an account and monitor risk signals that indicate when confidence in that identity should change. Those risk signals must be aggregated, evaluated in context, and converted into risk-aware access decisions.

CISA’s 2026 Recommendations and Why the Current Threat Landscape Demands More

CISA’s 2026 Cybersecurity Awareness Month recommendations include the following:

• Avoid and report phishing scams.
• Use strong passwords.
• Use MFA and a password manager.
• Update software.

These actions do reduce exploitable exposure. Employee awareness can interrupt a phishing attempt, while unique passwords limit the damage caused by password reuse. CISA’s 2026 campaign toolkit also recommends phishing-resistant MFA where available. This is an important distinction from authentication methods that remain vulnerable to phishing.

However, organizations that have made basic investments in cybersecurity have generally already trained employees to recognize phishing attempts and implemented stronger authentication controls. Phishing-resistant MFA adoption remains far from universal. Even where organizations have adopted stronger authentication, processes surrounding MFA, including enrollment and recovery, can remain vulnerable.

Ultimately, phishing-resistant authentication still depends on the enterprise assigning the authenticator to the right person.

Attackers understand this. Rather than attacking MFA directly, they can target processes with weaker identity controls, such as the service desk, account recovery, or authenticator enrollment.

CISA’s recommendations also do not address what happens when a valid credential or authentication factor has been compromised. Password strength does not reveal that a valid credential has been stolen and used to log in. Employee vigilance alone cannot detect when a compromised account uses excessive permissions to retrieve sensitive records.

Nor do the four recommendations define how an enterprise should evaluate a newly registered authentication factor alongside unusual account activity. They do not specify when evidence from another system should override the confidence implied by a successful login. These decisions remain essential even when an organization carefully follows the underlying recommendations.

In a September 9, 2026, investigation, Microsoft’s Krithika Ramakrishnan and fellow researchers described intrusions involving unusual sign-ins followed by attacker-added authentication methods. Subsequent activity included the collection of cloud-hosted data. Some lures invoked passkeys while directing employees into other authentication flows.

The findings did not show that attackers had broken passkey cryptography. Instead, they demonstrated the importance of understanding how an identity acquired access and what happened afterward.

Those observations show that while CISA’s recommendations are not obsolete, organizations cannot treat them as sufficient. An authentication control can accept an enrolled factor without establishing that the enrollment itself was legitimate. A business application can then honor the resulting access without recognizing the warning signs that preceded it.

Each Identity Layer Needs to Answer a Different Question

Organizations need a way to connect identity evidence before an attacker completes a sensitive action. Identity threat detection helps determine whether the person attempting to use personally identifiable information (PII) is the person to whom that information genuinely belongs. Risk mitigation turns that determination into a decision about access.

Identity verification can provide evidence about who a person is. However, an organization still needs to connect that verified identity to the account being claimed. Confirming someone’s identity provides no basis for handing over an unrelated employee account. Similarly, a valid identity document cannot establish that an existing session remains under that person’s control.

The relationship that authorizes access matters as well. A former contractor, for example, may prove their identity perfectly while no longer being entitled to access the organization’s systems.

Consider an employee who loses a phone and requests a replacement authentication method from an unfamiliar device. That sequence can be entirely legitimate. However, it also removes some of the evidence the enterprise previously relied on to recognize the employee.

Now suppose the phone number associated with the account has recently been transferred to a different device. Sending a code to that number provides limited reassurance about who currently controls it. The National Institute of Standards and Technology’s Authentication Guidance recommends considering device changes, SIM changes, and other risk indicators before delivering an authentication secret through the telephone network.

The enterprise now must decide whether to permit enrollment of a new authentication factor. Treating every device change as malicious would create unnecessary friction for legitimate employees. Ignoring the change would discard evidence directly relevant to the proposed verification method.

An additional layer should address that uncertainty. Repeating verification through the same suspect channel adds activity without resolving the underlying question of ownership. An independently established route back to the account holder may provide the missing assurance. If no such route is available, pausing enrollment may be appropriate while the organization resolves the claim.

A useful risk model also examines whether apparently separate signals are measuring the same underlying fact. An unfamiliar device and a short-observed device history, for example, may both reflect the first time a provider has encountered that device. Counting them as independent indicators of risk could overstate the evidence. A short-observed history also differs from proof that the device itself is new.

Combining signals requires rules about what evidence cannot simply be traded away. A history of trusted device activity should not offset confirmed evidence that an attacker enrolled in an authentication factor. A model that averages contradictory findings into a reassuring score can obscure the very event that should stop an account change.

These distinctions determine whether a layered approach improves security decisions. More signals do not necessarily provide more certainty. Their value depends on their relevance to the requested action and what the enterprise can reasonably infer from the available evidence.

The Bottom Line on CISA’s Recommendations

CISA’s recommendations reduce common exposure, but they leave organizations with a harder problem: deciding whether to continue trusting an identity when the evidence changes. A successful login cannot settle that question on its own.

Organizations need to connect risk signals across a multitude of interactions and use them to continuously reassess identity risk before a compromised account completes a sensitive action. This requires a multi-layered approach that connects identity threat detection with risk mitigation, so changes in risk lead to appropriate changes in access.

Cybersecurity hygiene remains important. But in an environment where attackers increasingly exploit legitimate credentials, authentication processes, recovery workflows, and trusted identities, organizations need to move beyond asking whether someone successfully authenticated. They also need to determine whether that identity can still be trusted.