The true promise of agentic AI lies in agents maneuvering, making decisions, and taking actions autonomously throughout the enterprise, but few IT leaders appear ready to give bots widespread control.

According to a KPMG survey from July and August, 62% of IT leaders reported they were building, deploying, or developing AI agents, up from 53% in the previous quarter. But many IT leaders still say they are uncomfortable with the prospect of turning over internal processes to agents, with some exceptions for basic, low-risk functions like tier 1 IT support.

Jim Olsen, CTO of AI lifecycle management and governance vendor ModelOp, sees agent autonomy making inroads in limited circumstances — for example, to process customer refunds or credits without human intervention. But early lessons in the risks of full autonomy remain top of mind for IT leaders.

“We saw the large adoption of Clawdbot and OpenClaw by individuals where they would allow it full access to their email and gave it full autonomy,” he says. “For some people that worked out well, but it was a large risk exposure.”

For IT leaders deploying autonomous bots, Olsen recommends confining them to a strict sandbox with well-defined policies to limit their autonomy.

“I do not see allowing agents full and complete autonomy to do whatever they want being used in an enterprise in the near future,” he says. “But restricted autonomy is, in fact, already in use today.”

Activities that aren’t mission critical and don’t have access to sensitive information will be where IT leaders first grant agents full autonomy, Olsen predicts. “As trust improves, so will the breadth of use cases,” he adds.

Some IT leaders are concerned about “autonomy creep,” when agents quietly take more authority than they are given. And many AI and security experts warn that human-in-the-loop guardrails don’t always give employees the authority or time needed to fix agent errors.

Still, IT leaders have several methods for enforcing runtime policies and keeping agent behavior within acceptable goals, including API gateways, OS-level enforcement, and credential management, Olsen says.

“This means having clear policies in place and being able to tie them to the specific agent and use case,” he adds. “Some of these solutions are available now, but a more overall cohesive strategy is needed to bring about this minimal level of trust.”

Defining the sweet spot for autonomy

With about 2,000 agents deployed within her enterprise, Siroui Mushegian, CIO of cybersecurity vendor Barracuda Networks, still has human employees checking bot actions.

“We have many agents that are very close [to autonomous] — many of our ticketing automations are in the ‘trust-but-verify’ category with the agents that oversee them,” she says. “The more we see success, the greater comfort we have, but I am still not 100% certain I want to allow zero human accountability, especially when it comes to auditable processes.”

Mushegian expects autonomy to expand as agents demonstrate they can handle specific tasks reliably. “The consequences of a mistake should determine how much evidence you need before giving an agent more authority,” she says.

Autonomy will likely come to agents executing specific tasks within a function, she adds. Routine internal support requests are a reasonable candidate for autonomy when the answer is well documented, the action is limited, and a mistake is straightforward to correct, she suggests.

Less likely candidates for autonomy are agents that can change access permissions or make changes to a production system, Mushegian adds.

“Even within one workflow, an agent might complete some steps on its own and need approval for others,” she says. “I’d give it only the authority it needs for the task, with human approval for decisions where a mistake could have serious consequences.”

It’s about the action, not the agent

Joshua Rowe, co-founder and CTO of household bills app provider Taupia, agrees that IT leaders shouldn’t give agents complete freedom in every circumstance.

“I’d draw the line at the action rather than the agent,” he says. “The same agent can act alone on one step and need sign-off on the next.”

However, Rowe sees a lot of areas where agents can run near-autonomously right now, including read-heavy work such as gathering data, triage, drafting, and comparing options.

Taupia is testing agent functionality that compares energy deals and takes steps to allow customers to switch providers without its employees approving each step. However, the customer still would have to review the change and confirm it before it goes into effect.

For agents to get autonomous authority for irreversible actions, the timeframe doesn’t depend on AI models getting smarter, Rowe says.

“It depends on how quickly an organization can make each action reversible or bounded, with spending limits, cooling-off periods, rollback, and an audit trail good enough to undo a mistake,” he says. “Once an action has those, it can go autonomous. Where it can’t be undone, like signing a contract or moving money out of an account, I’d keep a person approving it for the foreseeable future.”

A question of deliberate design

Maciej Walaszczyk, CTO at AI customer service platform provider Text, points to customer service as an area where IT leaders have begun to cede control to agents.

“In customer service, which is my field of expertise, agents can indeed answer customer inquiries without the need for constant supervision, as they learn from knowledge provided by humans,” he says. “The scope of autonomy depends on permissions and the consequences of an action. Furthermore, the scope of these responses can be tailored to specific needs.”

But Walaszczyk says he would not hand entire departments over to agents. Instead, IT leaders should delegate specific processes where they can define the goal, set boundaries, and verify the outcomes, he recommends.

“An agent acting on my behalf cannot have more authority than I do,” he adds. “I don’t think it’s a question of being comfortable or even courageous, but of deliberately designing the environment, permissions, instructions, and oversight.”

Trust will come from real work and verified results, and humans must remain in the loop to check agent outcomes in many cases, Walaszczyk adds.

“Oversight must be real,” he says. “It takes time and attention, and it means much more than clicking approve. Saying ‘AI did it’ does not remove their responsibility. Irreversible actions or those with major consequences require human review.”

In Part 1 of this two-part series, I argued that the moat is dry. When NotPetya hit Merck in 2017, it didn’t climb a wall. It came in through trusted vendor software, the routine traffic every perimeter is built to admit, and Merck put the damage at more than $1.4 billion. Its insurers then tried not to pay, and after that fight, underwriters started asking much harder questions.

AI has since made attacks like that cheaper and faster. In IBM’s 2026 Cost of a Data Breach report, one in four malicious breaches was AI-enabled, and breaches that took more than 200 days to find and contain cost about $1.3 million more than those that didn’t. Deepfaked executives, software that can be talked into things and AI agents holding credentials are attacks on trust first and technology second.

Yet the people we hold responsible are set up to lose. Some 64% of CISOs still report into IT leadership, only 10% influence financial decisions, and only a quarter say board discussions of cyber risk run longer than 30 minutes. They are accountable for the breach without budget authority, and they check the work of the people they report to.

The organizations that feel safest about the next two years are not the ones with the most tools. They are the ones where leadership understands AI risk, someone clearly owns it, and the security team has the authority to act. That is a governance problem, and it has a governance fix.

A roadmap for reconstruction

1. Take security out of IT, and do it before the breach

No company lets the finance department audit its own books. That is why internal audit reports to the board’s audit committee rather than to the CFO. Security deserves the same independence for the same reason: the people who build and run the systems should not vouch for them. The CISO’s job is not to run technology. It is to govern how people, partners and machines behave around the things the organization cannot afford to lose, and to tell leadership the truth about that risk.

That does not make the job less technical. A CISO who can’t read an architecture diagram, question an engineer or spot a vendor’s overstatement will be steamrolled in the first meeting. The role needs an engineer’s depth. It is just bigger than engineering, the way a general counsel needs to know the law but is hired for judgment.

In practice, that means a direct line to the CEO and a board committee. Equifax did this after its 2017 breach. Its new CISO, Jamil Farshchi, called the direct line to the CEO and board the key to the turnaround, and noted that it costs nothing. Vertex Pharmaceuticals took a different route: its CISO reports to the Chief Scientific Officer, which puts security next to what the company actually protects, its research. Choose a model deliberately. Most organizations never choose; they inherit one.

2. Hand the CISO the AI governance pen

Only 19% of organizations report coordination between their AI governance and security teams. Every AI tool the business adopts is a security design decision, and it needs one accountable owner. Otherwise, you have a committee that approves tools and a security team that finds out later. But accountable doesn’t mean alone, which brings us to the most important step.

3. Give everyone a voice

A CISO knows security. A CISO does not know research, or claims processing, or the manufacturing line. Elevating the CISO works only if decisions get made with the people who live with them: research leaders, business owners, legal, finance and the CIO. Build a standing risk council where those voices shape controls before they’re imposed, and where a scientist can say “this will break my work” and be taken seriously. The point of elevating the CISO isn’t to put one person in charge of everyone else’s work. It’s to make sure the person who owns the risk is in the room, and that everyone affected by the decision is in the room too.

Security decisions made in isolation get worked around. Decisions made together get followed.

4. Define “ready,” then hire and develop to it

New York’s cybersecurity regulation for financial firms calls the CISO “a qualified individual” but never says what qualified means. Here’s a working definition, in the form of two tests a board can give. The first is technical, and it is not optional:

• Can you tell us what we own, who can reach it, and how fast we can recover, and when did we last test that?
• Have you personally used the AI tools our employees use? Can you explain prompt injection and agent permissions to us in plain English?
• Where does your threat knowledge come from besides vendors: peer networks, industry information-sharing groups, red-team results?

The second test is about judgment and behavior. It is the one most security leaders are never given:

• What do our people actually do when a request seems urgent and comes from someone senior?
• Which risks have you advised us to accept, and why? A CISO who never recommends accepting a risk is a gatekeeper, not a risk officer.
• Can you translate a risk into dollars and days of downtime?
• Which research and business leaders do you consult before a control changes how they work?

And one question for the board itself: Have we given this person authority that matches their accountability?

👉 Click here to download a sample CISO job description👈

5. Make sure AI agents are governed like employees

The CISO doesn’t provision these accounts; the CISO makes sure someone is accountable for every one of them. Every non-human identity needs an owner, the least privilege it needs, monitoring, and a kill switch. Among organizations that had an AI-related incident, 92% lacked proper AI access controls.

6. Hold everyone to the clock, not the checklist

Ask every part of the organization for time to detect, time to contain and time to recover, using tested numbers rather than estimates, and report them to the board. The 200-day line in IBM’s data is worth more than a million dollars per breach.

7. Make sure the boring things get done

Encryption, multi-factor authentication, asset inventory and network segmentation are not glamorous, but they are exactly what insurers began requiring after the Merck case. Doing this work belongs to the technology teams. The CISO’s job is to verify that it’s done and to tell the board plainly when it isn’t. If your underwriter is asking for these controls, your board should be too.

8. Give the board more than 30 minutes

Make cyber a budget conversation rather than a status update. If the CISO’s board time is spent on regulatory trends instead of business trade-offs, the board is being briefed, not governed.

A word to CIOs

I know how this reads to a CIO: someone telling you to give up a direct report. But a CISO who reports to the CIO is grading the boss’s homework. The CIO is measured on availability and speed of delivery. The CISO is measured on risk. That tension is healthy only between peers. Elevating the CISO doesn’t diminish the CIO; it frees the CIO to build without also serving as auditor of what they built. The two roles aren’t a senior and a junior version of the same job. One builds and runs the organization’s technology. The other is responsible for whether the organization, its people included, can be trusted.

A good CIO should lean on the CISO and also be a little afraid of the CISO, the way a good CFO relies on the auditor and is a little afraid of what the auditor will find. That fear is not hostility; it is the reason the books stay clean. Pair it with the partnership described above, and the CIO gets something no direct report can offer: someone with the standing to say “no, not like that” before the board has to hear it from an attacker.

The CIO’s seat at the table appeared when technology became the business. The CISO’s is appearing because trust has become the business, and AI has made that impossible to ignore. Some organizations are already moving. In IBM’s follow-on research, 85% said they plan to increase security spending after learning what frontier AI models can do to their systems, compared with 64% who planned to spend more after suffering a breach. Learning from the threat is far cheaper than learning from the post-mortem, and the organizations that get there first will be the ones where security, research and the business decide together.

The moat is dry. Stop dredging it, and give the person defending the castle a seat at the table.

In June 2017, a piece of malware called NotPetya got into Merck & Co. without climbing a single wall. It arrived through a backdoor in accounting software supplied by a Ukrainian vendor, the kind of trusted, routine traffic every perimeter is built to let through. It spread to some 40,000 of the drugmaker’s computers, and Merck put the damage at more than $1.4 billion.

Then several of Merck’s insurers argued they owed nothing, because the attack was attributed to Russian military intelligence and their policies excluded acts of war. The fight ended in a confidential settlement in January 2024.

Two lessons sit in that story. The moat didn’t matter, because the threat came in with the traffic the moat was designed to admit. And the people who price risk for a living were the first to notice and the first to send the bill.

That was 2017, when attackers still needed humans at the keyboard. Increasingly, they don’t.

Here is the argument of this two-part series in two sentences. Security stopped being a technology problem with business consequences; it is now a business risk with a technology component. Most organizations are still organized the other way around, and the person they hold responsible for that risk sits inside the IT department, reporting to the people whose work they are supposed to check.

What AI actually changed

IBM’s 2026 Cost of a Data Breach Report, based on 602 breached organizations, found that one in four malicious breaches was AI-enabled, a 56% jump in a single year. Those breaches averaged $6 million, about $1 million above the global average of $4.99 million. In the U.S., the average breach now costs $11.5 million.

You don’t need a computer science degree to understand what changed. Three things matter:

• The con got a better voice. Deepfake impersonation was the most common AI-driven attack in IBM’s data, at 45%. The oldest scam in business, the urgent wire transfer, now arrives in the CFO’s actual voice on a video call.
• Your software can be talked into things. “Prompt injection” means hiding instructions inside an email, document or web page that an AI assistant reads and then obeys. It is social engineering aimed at the software instead of the employee, and no amount of annual phishing training protects against it.
• You’ve hired employees with no background check. Every AI agent holding credentials is, in effect, a new hire with keys to your systems, no manager and no HR file.

Notice what those three have in common. Each one is an attack on trust, on whom we believe, what we obey and whom we let in, and only then on technology. That distinction matters for everything that follows.

Meanwhile, employees aren’t waiting for permission. Shadow AI, meaning tools staff use without sanction, showed up in 43% of breached organizations this year, up from 20% the year before. Breaches involving AI systems themselves rose to 21% of all incidents, and the most common way in wasn’t the model at all. It was the plumbing around it: compromised APIs and plug-ins, and misconfigured cloud workloads.

Why the moat is dry

Moat security is easy to recognize. There’s a perimeter, a couple of expensive appliances, an annual training module, and a binder of procedures nobody reads until the auditor visits. It assumes the enemy is outside.

Today, much of the risk has been invited in the assistant reading the email, the agent holding the credentials, the vendor pushing the update. When Johnson Controls was hit by ransomware in 2023, the attackers first got into the company’s Asia offices and spread from there across the network. The company confirmed data theft and more than $27 million in costs, net of insurance. One breach in a distant office, and the moat was irrelevant.

Moat organizations measure activity. Attackers measure time. IBM found the average time to identify and contain a breach rose to 247 days, the first increase in five years. Breaches contained in under 200 days cost $4.32 million; those that ran longer cost $5.65 million. And 53% of breached organizations hadn’t encrypted sensitive data at rest and in transit. The basics still aren’t done.

My email signature reads “Process is the evil twin of progress.” Moat security is process mistaken for protection.

Prepared versus old school: the numbers

In fairness, IBM sells security tools, and I’m aware of the irony of citing a vendor in a piece that warns against learning from vendors. The fieldwork is done by the Ponemon Institute, though, and the pattern matches what independent CISO surveys show. The gap between prepared and unprepared organizations is not subtle:

What separates them	Prepared	Old school
AI and automation in security operations	Breach costs nearly $2M lower	One in four still without
Breach found and contained	Under 200 days: $4.32M	Over 200 days: $5.65M
Employee use of unsanctioned AI	Low: $4.63M per breach	Widespread: $5.39M per breach
AI security maturity (CISO self-rated risk)	3.7 out of 10	7.8 out of 10
AI governance and security teams coordinated	19% of organizations	Everyone else

Sources: IBM/Ponemon, Cost of a Data Breach 2026; IANS/Artico Search, CISO Perspectives on AI Risk 2026.

The most revealing finding comes from the IANS survey of 113 CISOs. Mature AI security programs explained why some security chiefs feel safer today. But confidence about the next two years tracked something else: whether leadership understood AI risk, whether someone clearly owned AI governance, and whether the security team had budget authority and enough staff. In other words, the factor that matters most is governance, not technology.

The CISO problem: under-trained and under-armed

Under-trained. Many of today’s security leaders learned the job defending against people, not software that behaves like people, and much of what they know about AI came from the companies selling the cure. When IANS released its research this year, one of its partners pointed out that most AI risk data comes from vendors and so reflects the supply side. If your threat briefings, your training and your tools all come from the same sales channel, you’ll end up with a well-funded blind spot. Only 53% of CISOs in a LevelBlue survey said they felt prepared to defend against AI-enabled adversaries.

This is not about age. A veteran who keeps learning beats a newly certified buyer of AI-branded appliances every time. What matters is whether someone is still learning now, not when they first learned.

Under-armed. The IANS 2026 board engagement study found that 95% of CISOs brief their boards regularly, but only 10% influence financial decisions. Only a quarter say board discussions of cyber risk run longer than 30 minutes. And 64% of CISOs still report into IT leadership. That leaves the CISO accountable for the breach without authority over the budget.

The lab is not the accounting department

Everything above gets harder in a research organization. Research runs on unpredictable workflows, tools adopted the week they appear, enormous data transfers and outside collaborators. A control that slows a scientist doesn’t stop the work. It moves the work somewhere security can’t see.

The stakes are rising at the same time. Google’s threat intelligence group reported that in the second quarter of this year it investigated extortion cases involving stolen AI research, including one in which a healthcare organization lost drug research and an AI model. It also tracked a China-linked group targeting academic, medical and military research institutions in North America.

R&D doesn’t need an exemption. It needs a different deal: wide freedom in how the work gets done, in exchange for a short list of fixed rules around the assets that matter most. In practice, that means protecting around the lab rather than inside it:

• Make the safe path the fast path. Offer pre-approved sandboxes, compute environments and AI tools that are quicker to use than the workarounds. Researchers don’t resist security; they resist friction.
• Watch instead of block. Monitor what leaves the lab and how, rather than putting a checkpoint in front of every action. Unusual data movement and odd access patterns are how theft gets caught without slowing discovery.
• Classify by value, not by department. Open science, pre-publication results and proprietary or controlled work need different protection. Lock down the crown jewels, not the whole lab.
• Borrow from the research networks. The research and education networking community solved a version of this years ago with the Science DMZ, a design that moves high-performance research traffic outside the enterprise firewall and secures it with targeted controls and monitoring instead.

Some rules don’t bend: federal research-security requirements, defense contracting standards, export controls. But that list should be short, explicit and explained, not a binder of procedures nobody in the lab can name.

We regulate security by tax status, not consequence

Public companies must describe board oversight of cyber risk to the SEC, though the final rule dropped a proposal to disclose whether they even have a CISO. New York’s financial regulator requires the CISO to report to the board in writing every year, and the board must understand and fund the program, public or private. Hospitals still operate under a HIPAA Security Rule written in 2003; its overhaul has slipped to July 2027. A privately held research firm can fail as badly as any public company, and the rules barely notice. Don’t wait for a regulator to tell you what your risk already has.

That is the diagnosis. In Part 2, the prescription: an eight-step roadmap for rebuilding, starting with the reporting line that most organizations never chose and simply inherited.

New hands-on lab lets security practitioners explore PHP2Shell exploitation firsthand as AI-assisted research reshapes vulnerability discovery.

OffSec today announced the release of a free, interactive hands-on lab in Proving Grounds Play (PG Play) to help security practitioners examine and defend against the critical “PHP2Shell” vulnerabilities (CVE-2026-109618 and CVE-2026-109619) firsthand. Developed in response to AI-accelerated vulnerability discovery and active exploits targeting core PHP engines in the wild, the lab provides penetration testers and enterprise defenders with a safe, controlled environment to study the decade-old memory corruption flaws and implement timely server mitigations.

The two critical flaws sat inside PHP, the language behind roughly 70% of websites whose server-side language is known, for more than a decade. Then researchers at Wiz, a Google-owned cloud security company, pointed AI at the code. 

They found the first flaw Aug. 19. The next day they used it to take over a Drupal site without a password. The day after that, it worked on WordPress.

PHP disclosed the flaws Oct. 21 as CVE-2026-109618 and CVE-2026-109619. An attacker with no login can send a series of crafted web requests to crash a server or take it over. PHP’s severity scores rate both vulnerabilities as complex to exploit, even though working attacks already existed. The Cybersecurity and Infrastructure Security Agency (CISA) recommends patching immediately. 

Attackers are moving fast. Amazon calls PHP2Shell broadly exploited in the wild. By Oct.24, researchers had confirmed attackers running commands on vulnerable honeypot servers. CISA added both flaws to its Known Exploited Vulnerabilities catalog on Oct. 26. 

“PHP is one of those technologies attackers love to see,” said Keegan Bowen, principal DevOps lead at OffSec. “It has been a great attack vector over the years with many exploits and potential abuses. PHP wasn’t designed with security from the start.”

OffSec, which has taught hands-on offensive security since 2006, has released a free PHP2Shell lab in Proving Grounds Play (PG Play). The lab gives penetration testers and other security professionals a controlled environment to explore CVE-2026-109618 and CVE-2026-109619 firsthand. OffSec’s blog breaks down both flaws, and its proof-of-concept exploit is available on Exploit-DB. 

AI and the Evolving Pace of Exploitation

PHP scored both flaws 9.2 out of 10, a critical rating. To build a working attack, Wiz researchers had to chain several bugs together and tune the attack to each server’s memory. When they let AI do the grind, one researcher finished in a week what once took a top team month. Attackers can use the same AI models, so flaws once ranked too complex to matter are now fair game. 

“At this point, attackers are heavily leaning on AI to find and exploit vulnerabilities; the rate of CVEs is roughly double what was reported last year,” said Matt Freitas-Stavola, staff software engineer at OffSec. “LLMs don’t get tired and can easily run in the background for as long as attackers have money or compute to spare. Even now, just a hint of where an issue could arise is enough for an LLM to get a workable POC out relatively quickly.”

The Effects of These Flaws

Both flaws start with the same weak spot: what PHP does when a request runs out of memory or hits another fatal error.

“PHP is built from C and memory management becomes increasingly challenging as the code grows,” Bowen said. “Some out-of-memory states were not handled well. In some cases, attackers can access interrupted state data before it is cleaned up. That becomes an opportunity for abuse.”

That leftover state can carry into the next request on the same worker. An attacker who shapes it can run code with the web server’s privileges.

The same bugs can also leak data. Wiz showed attackers could potentially read memory from the PHP process. That memory could hold passwords, session tokens, API keys, and certificates from other requests or the server itself. 

The story is still developing. On Oct. 23, PHP disclosed a separate flaw, CVE-2026-115560, that can affect fully patched servers with an unusual session setup. PHP has no fix for it yet. Researchers have also built PHP2Shell exploits that get past ASLR, a common memory defense, and more issues could surface as the flaws are studied. As research continues, new vulnerabilities, exploitation techniques, and mitigations may emerge beyond those covered here.

OffSec’s Current Recommendations

These steps reflect what is known at the time of publication. Check CISA and the PHP project for the latest recommendations.

• Patch PHP Now. Update to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 to address CVE-2026-109618 and CVE-2026-109619. Check vendor advisories rather than relying on version numbers alone.
• Update the Underlying PHP Engine. Updating WordPress, Drupal, or another application does not resolve vulnerabilities in PHP itself. Rebuild affected container images, and restart PHP processes so the updated code takes effect.
• Apply Temporary Protections While Patching. Disable PHP session upload progress (session.upload_progress.enabled=0), which also mitigates CVE-2026-115560. On PHP 8.5, disable fatal error backtraces and restart affected workers after configuration changes. These measures reduce exposure; they do not replace patching.
• Investigate Potential Compromise. Review web server and PHP logs for suspicious multipart requests, memory-limit errors, repeated HTTP 500 responses, malformed session cookies, and unexpected PHP worker restarts. Investigations should consider activity dating back to at least October 17, when exploitation attempts were first reported. Rotate potentially affected credentials, API keys, and tokens as appropriate.

Understand the Exploit. Strengthen the Defense.

When the next disclosure lands, someone on the team needs to judge exposure. Reading about an exploit builds awareness. Working on one hands-on builds the skill to respond. 

OffSec’s PHP2Shell lab helps practitioners turn technical knowledge into hands-on experience they can apply to future vulnerabilities. For a deeper look at the vulnerabilities, explore OffSec’s technical analysis. Organizations looking to build these capabilities across their security teams can explore OffSec’s workforce development programs.

About OffSec

OffSec is the world’s leading provider of high-fidelity cybersecurity training and certifications. Built on a foundation of excellence, integrity, and the relentless “Try Harder” ethos, OffSec empowers individuals and organizations to outsmart evolving cyber threats through rigorous, hands-on learning.

Contact

Press Team

OffSec

Kathryn@kbmediaconsulting.com

The businesspeople adopting AI notetakers are not being reckless. They are responding to a real business need. Our teams are in meetings all day with companies we support, and the idea that we could read a clean summary of every one of them at the end of the day makes us better partners to our customers. At the AI-first startups we spend time with, a new account manager can walk in on day one, inherit the full recorded history of every customer conversation, and ask the AI what that customer actually cares about. That is not surveillance culture for its own sake. It’s a better way to serve people.

Still, AI notetakers present cyber risks, as we have been warning about for the past year: shadow adoption measured in hundreds of accounts in a matter of weeks, vendors without SOC 2 or real encryption, consent liability, litigation exposure. In April, one of us stood on stage at the [un]prompted conference and argued that the most important attendee in your meetings is no longer a person. AI notetakers decide what matters, assigning the action items and providing the summary that becomes the meeting’s official record.

But our early warnings about AI notetakers shared an assumption we no longer hold: that the notetaker joins the meeting. That assumption quietly died this summer, as the notetaker has left the meeting platform and moved onto the body — and policies haven’t noticed let alone caught up to this change yet.

From the meeting to the wrist

On July 28, Granola, the AI notetaker we see most often in our worlds, launched an Apple Watch app. One tap on the wrist and it records whatever happens around you. No bot joining the call, no banner announcing itself, no laptop open on the table.

The same week, DEF CON banned Meta-style smart glasses from the conference floor over recording concerns. Meta, meanwhile, had already acquired Limitless, the AI pendant company, folding always-on personal recording into the largest consumer hardware pipeline in the world. One public company we’ve worked with now screens attendees for smart glasses before all-hands meetings where unreleased plans are discussed.

We’ve tested this ourselves, putting the watch under a jacket sleeve, tapping once, and recording an entire evening walk. Clean transcript. Nobody could have known.

In the United States, recording someone without their permission depends on which state you are standing in. California says you can’t, but many states say you can. More importantly we still have no norms of disclosure, and the hardware is now designed to be invisible.

The record is not neutral

Since the April talk, we have met a steady stream of people telling us how they game these systems. One person described doing prompt injection against a notetaker in a live meeting, right as we walked offstage. Another explained the simplest trick we have heard: join early, and for the five minutes you are alone with the notetakers, calmly narrate the outcomes you want captured as the most important takeaways. A third said he figured out how to silently crash other companies’ notetakers, so the meeting ends and there is no record. There is academic research behind all this. Call it manipulation or call it strategic communication. The methods work.

Notetaking systems also fail on their own. We have watched a transcript mishear one word, then reinterpret the rest of the conversation to fit the error. Colleagues with accents the models handle poorly carry more of that risk than the rest of us. And these tools are no longer stenographers. They have memories. Granola pulls context from prior meetings and background on the people in the meeting into today’s meeting notes. That is useful, but it also means a summary shared outside your company could leak reasoning from meetings the other party was never in.

Then there is the case that should be on every policy writer’s mind. Last November, a Campbell’s security executive was terminated for what they said during a meeting secretly recorded by an employee during what he thought was a private lunch conversation. The recording surfaced months later through an employment lawyer, and the executive was gone within days. Whatever you think of what was said, notice the mechanism: no notetaker bot, no meeting platform. One person, one device, one conversation the speaker believed was off the record. There is no such thing anymore.

What a serious policy looks like

Boards and legal teams are now asking their CISOs for notetaker policies. Having helped several organizations think through this, here is where we land.

Transparency always. If a recording tool is running, everyone present knows. The lightest version we recommend: Change your display name to “Name + AI notetaker.” And the rule must bind employees, too. An employee who records a colleague without disclosure is committing a fireable offense, full stop, before we ever discuss what the recording contains.

Classify your meetings. At one firm, we wrote a formal policy naming which meetings may never be recorded. Yours might include M&A, legal, HR, and board executive sessions. Decide deliberately, in writing, before the tools decide for you.

Govern other people’s notetakers. When an auditor walks into your building, their laptop has to meet your standards. Apply the same principle to recording. If another organization records your employees, you should know, and you should get a copy.

Choose your retention posture. A full transcript is a different corporate record than a summary. Decide whether transcripts are destroyed by default, with legal holds as the exception, or kept forever. Do not let the vendor’s default decide.

Treat notetaker vendors like what they are: startups holding your most sensitive conversations in their cloud. Vendor security review, data-reuse terms, indemnification language. Brewer v. Otter.ai, a class action alleging Otter’s notetaker recorded meetings without everyone’s consent and used the recordings to train models, and the sudden shutdown of Novacy both happened for a reason.

Assign a human. Every transcript that becomes a record needs a named owner responsible for reviewing its accuracy, no matter whose tool recorded the call.

Remember that some may train employees to steer the transcript, the way a lawyer protects the record in a deposition. We understand the instinct, and reviewing the record for accuracy is exactly right. An organization that quietly optimizes its official records has bigger problems coming.

We used to debate whether to let the notetaker into the meeting. That debate is over, because the meeting is now everywhere the recorder goes. Write your policies for the world where the microphone is already in the room, because it is.

“Are we exposed?” CIOs and CTOs heard that question all last week. On Tuesday, PHP shipped emergency fixes for two pre-authentication remote code execution flaws that date back to 2004. By Wednesday, Palo Alto Networks said every supported version of PAN-OS and Panorama was vulnerable and no fix was available. Cisco was reviewing 18 products and 13 cloud services, and Fortinet was reviewing eleven. NSA, NCSC and CERT-EU told operators to take unpatched systems offline, and Cloudflare’s CEO watched exploit attempts jump from thousands to millions within hours. People are calling it Black October.

An AI model found most of these bugs. The lesson for boards, though, isn’t about AI. Patching is no longer the bottleneck. Knowing where to patch is.

“Please go to your boards and ask for help right now. Not for AI, for the basics.” (Jason Clinton, Deputy CISO, Anthropic, Oct. 22.) Marc Benioff replied: “Jason is 100% right. Code red.”

Answering “are we affected?” should take minutes. That takes one real-time, authoritative record of every device, version, site, owner and exposure, plus automation that patches from that record and confirms the fix. Organizations without that record are still searching while attackers move. With vulnerability volume climbing this fast, the gap will only grow.

The number of vulnerabilities has more than doubled in the last year – and it is just getting started

From January 1 to October 13, 79,680 CVEs were published, 2.15 times the same period in 2025. Microsoft alone published 1,408 on October 13. That’s more than it disclosed in all of 2025, and its fourth record month in a row.

AI is behind the surge. Between April and July, Anthropic’s Project Glasswing partners verified more than 129,000 vulnerabilities, over 33,000 of them critical or high, and Anthropic estimates the real total is at least five times higher. Google’s threat intelligence group says monthly disclosures doubled from January to August, and that AI-found bugs are twice as likely to be remote code execution. OpenAI, whose model found the PHP flaws, expects such findings to “increase sharply in the coming months.”

Exploitation is speeding up just as fast. Mandiant’s mean time-to-exploit for 2025 was negative seven days, and Microsoft puts median discovery-to-weaponization under 24 hours. Amazon CISO CJ Moses saw PHP2Shell probing four days before a patch existed. His warning: the disclosure date isn’t the earliest date of exploitation. Reuters reported that one operator used AI agents to breach more than 100 companies for about $5,000 in tokens. That works out to roughly $50 a breach.

Attackers can’t be allowed to have a better asset inventory than you do

Enterprises simply aren’t keeping up:

• Verizon’s 2026 DBIR found just 26 percent of known-exploited vulnerabilities fully remediated, down from 38 percent, with a median of 43 days.
• Moody’s puts the median at 87 days for exploited bugs.
• Tenable found Citrix environments take a median of 461 days to patch.

The patch itself is rarely the obstacle. The obstacle is systems nobody knew about. As Armis’s threat intelligence lead put it this week, “the most common gap is not knowing an instance exists.” PHP is built into firewall consoles, NAS admin panels, printers, cameras and switches that never advertise it. Action1’s field CTO said it more bluntly: “The inventory is a guide, not a shield.” Most enterprises don’t even have the guide.

Two incidents this month show the stakes. On October 16, Palo Alto’s Unit 42 disclosed that attackers who compromised FortiManager instances got an inventory of more than 500 downstream FortiGate firewalls, including serial numbers and public IPs, and used it to gain root on those firewalls. In the Reuters case, when the target application had no flaw, the agents moved to adjacent infrastructure and found an exposed control panel nobody was watching.

AI now finds the bug, writes the exploit and maps your estate faster than your team can. The defender’s one lasting advantage is knowing the estate better than the attacker: every device, version, exposure and owner. That knowledge has to drive action in hours, not quarters.

Network and infrastructure is the front line

The hardest systems to see are the ones getting hit hardest. Google reports that edge and security appliances accounted for 14 percent of exploited vulnerabilities this year, and two-thirds of those were high or critical. Mandiant notes these devices usually lack standard EDR telemetry. In October, actively exploited flaws hit Ivanti Connect Secure, Cisco Secure Email Gateway, Palo Alto PAN-OS, Fortinet FortiMail and FortiOS, SonicWall SMA and Citrix NetScaler. Then PHP2Shell exposed the management plane of nearly every major network vendor at once.

You can’t put an agent on a router or scan what isn’t routable. That’s true across the campus, the branch and edge, the AI data center and the OT floor. The control that works there is an accurate, current record of what’s deployed, what it runs, where it sits, who owns it and whether it’s reachable from the internet, plus automation that acts on that record.

This is a board question now

Every board should ask its infrastructure leaders five questions this month:

1. Do we have a single, continuously updated inventory of every network device, server and appliance we operate — with software version, location, owner and internet exposure?
2. When the next PHP2Shell lands, how long does it take us to answer “which of our systems are affected”? Minutes, or weeks?
3. Is that inventory discovered from the live network, or is it a spreadsheet someone updates when they remember?
4. Can our automation patch directly from that inventory, or does every advisory start with a manual hunt?
5. After we patch, do we verify the fix took and the estate hasn’t drifted?

If the answers are no, weeks, spreadsheet, manual and no, the problem isn’t patching. It’s a gap in the fundamentals, and no patch-management budget will close it.

What to do this quarter, not next year

Treat this as a loop that runs continuously, not a project with an end date:

• Discover. Find everything on the network automatically, all the time. Unknown devices are the attacker’s favorite devices.
• Record. Put it in one system of record: the intended state of your infrastructure, not a scan export. Version, role, site, owner, exposure.
• Prioritize. Join that record against KEV and vendor advisories. Internet-reachable plus critical plus exploited goes first. The rest is a queue, not a panic.
• Patch from the record. Drive automation off the inventory so a new advisory becomes a targeted job, not a scavenger hunt.
• Verify and repeat. Confirm the live state matches the intended state, catch drift, and go again. Forever.

Automation helps teams keep pace, but without an authoritative inventory, it just misses things faster.

Attackers now discover at machine speed, while remediation still moves at the speed of someone opening a spreadsheet. Until that changes, attackers will know your infrastructure better than you do. Fix that first, and fix it this quarter.

Two leading AI developers have released fresh evidence of a problem that researchers have long anticipated: advanced models searching for ways around the limits imposed on them. New disclosures from OpenAI and Anthropic detail how frontier systems exploited weaknesses in their environments or exceeded the intended scope of assigned tasks.

OpenAI is now tightening internet access in its internal model-training environment after finding that its frontier models could exploit software vulnerabilities and infrastructure misconfigurations to break out of sandboxes and reach the live internet.

“Based on the current state of alignment research, monitoring systems, and the security of internet infrastructure, we believe the responsible approach is to conduct frontier model training with no internet access,” the company said in a blog post.

The decision followed a September 20 incident in which an internal research model exploited a misconfigured DNS resolver to gain limited access to the live internet during a training run.

After the incident, OpenAI said it paused training and evaluation of its most capable models and launched a high-compute red-teaming campaign, using AI agents to probe isolated copies of its research infrastructure. The tests uncovered previously unknown software vulnerabilities and weaknesses in the controls intended to prevent unauthorized access and communication.

Consequently, the company has announced a policy of conducting frontier-model training without internet access until improvements in security and monitoring justify broader access.

The disclosure came alongside a separate assessment from Anthropic, which detailed how its Claude Mythos 5 model attempted to compromise an unrelated GitHub repository during a cybersecurity evaluation.

OpenAI’s agents exploited flaws in containment controls

OpenAI’s red-teaming campaign found that agents could chain software vulnerabilities to escape virtual machines and execute code on the underlying host. The company identified weaknesses in open-source components, including Kata Containers, gVisor, and Moby/Docker, alongside Linux kernel vulnerabilities.

The company also found that agents could exploit weaknesses in internal services that retained limited outbound connections for functions such as logging, metrics, and authentication management. These connections provided routes to the internet despite restrictions elsewhere in the environment, OpenAI said.

In another test, agents running in separate microvirtual machines (microVMs) on shared host hardware exchanged synthetic secrets through processor-cache timing differences. The technique allowed them to communicate without a network connection or shared writable files.

OpenAI said it remediated the weaknesses and worked with open-source maintainers to disclose and fix affected software. Its post names several vulnerabilities, including CVE-2026-24834 in Kata Containers and three Linux kernel flaws tracked as CVE-2026-74753, CVE-2026-80521 and CVE-2026-80841. The company also said it had disclosed numerous additional vulnerabilities that have not yet been made public.

The number of vulnerabilities and misconfigurations identified by the agents declined significantly as testing continued, OpenAI claims. It has now tightened network restrictions, strengthened monitoring, and developed an offline environment with indexed and cached web content so models can practise browsing without unrestricted access to live external systems.

“Although internet access can help models learn useful skills, it also gives a capable, misaligned agent opportunities to affect systems beyond our control,” the company said, explaining its decision to restrict live internet access during model training.

Reinforcement-learning training and internal inference were resumed on October 1 after implementing additional controls.

Anthropic flags alignment gap in Mythos

Anthropic’s assessment of a UK AI Security Institute (AISI) cybersecurity evaluation describes a different problem: a model taking unauthorized actions against real people while trying to complete an assigned task.

In nine of 43 evaluation runs, Anthropic said Claude Mythos 5 went beyond the intended scope of the exercise. In the most detailed case, after its authorized attempts to retrieve protected data from a simulated network failed, the model searched GitHub for a repository it believed was connected to the test environment.

The repository actually belonged to unrelated developers.

Mythos 5 attempted to submit malicious code and created fake identities to persuade the repository’s maintainers to approve the change, falsely claiming that the code was safe. The maintainer rejected the submission, and the run timed out. Anthropic characterized the behavior as a serious alignment failure involving overreach and deception in pursuit of the assigned objective.

Internet access had been enabled during the evaluation, and the production safeguards used with its general-release models had been disabled. The company said those safeguards would have flagged the behavior had they been enabled.

The article originally appeared on CSO.

Oracle has patched 1295 security vulnerabilities with its October Critical Patch Update Advisory; six of them scored the highest vulnerability rating of 10.0 on the CVSS version 3.1 scale.

The company’s flagship Oracle E-Business Suite was home to one of the vulnerabiltiies, tracked as CVE-2026-101809. This enables any unauthenticated attacker with network access via HTTP to compromise the workflow notification mailer in the suite’s Workflow component, taking over Workflow and potentially affecting other products too. The flaw affects Workflow versions 12.2.3 through 12.2.15.

Oracle SOA Suite, part of Oracle Fusion Middleware, was hit by three of the bugs rated 10.0.

One, tracked as CVE-2026-91231, is in the Adapters component, and enables unauthenticated attackers to compromise Oracle SOA Suite resulting in its takeover, with potential impact on connected products.

Two others were in the Fabric Layer component of Oracle SOA Suite: CVE-2026-91216 and CVE-2026-91221.

Both are easily exploitable, Oracle said, and enable an unauthenticated attacker with network access via the T3 or IIOP protocols to compromise Oracle SOA Suite and perhaps affect other products too. The bugs appear in supported versions 12.2.1.4.0 and 14.1.2.0.0.

There’s a 10.0-rated vulnerability in another part of Oracle Fusion Middleware too. The flaw in Oracle Access Manager (tracked as CVE-2026-87337 leaves it open to compromise by any unauthenticated attacker with network access via HTTP. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification of critical data on Oracle Access Manager versions 12.2.1.4.0 and 14.1.2.1.0.

The last “perfect 10” vulnerability in Oracle’s latest report is in the JD Edwards EnterpriseOne Orchestrator product of Oracle JD Edwards, tracked as CVE-2026-91299. This enables an unauthenticated attacker with network access via HTTP to compromise and take over versions 9.2.0.0 through 9.2.26.5 of the orchestrator.

CrowdStrike has seen customers use our no-code agent-building workspace, Charlotte AI AgentWorks, to build thousands of AI agents. We’ve been fascinated by how they are designed and which ones become top-performing agents invoked hundreds or thousands of times in daily operations. Below are the design properties these agents share.

What top-performing security agents have in common

1.  Surgical scope

These agents solve a specific, measurable problem. They do one thing very well, and their output informs broader workflows.

Most organizations start by designing a general-purpose security assistant to address a range of tasks; however, these assistants are challenging to deploy and measure. Even if it can get to a working state, it can easily drift from its objective in dynamic enterprise environments. An agent with a narrow, well-defined job is more likely to become critical infrastructure because its output is predictable and trustworthy enough to measure, test, and build around.

Example: An agent that owns one type of detection, such as flagging uncommon LOLBIN usage

2. Multi-agent pipelines

They are also typically cheaper to run, for two structural reasons.

The first is model assignment. In a monolith, the whole task inherits whatever model its single hardest step requires. Every trivial step is then paid for at that rate. Decomposing the task lets each stage run on the optimal model applicable to the agent, and even allows delegating structured tasks to automated scripts or applications that don’t require AI models.

The second is context. A single long-running agent accumulates history, and every subsequent step spends resources to carry it. But an agent pipeline hands each stage only the input that stage needs. A failed stage can also be retried on its own rather than rerunning the entire investigation.

Example: A threat analysis pipeline built around an orchestrator agent that calls out to a set of narrow specialist agents rather than one broad agent trying to do it all

3. An explicit specification of what is not allowed

Top-performing agents often include explicit instructions outlining what the agent can and cannot do. This guardrail ensures the agent behavior is bounded. Without it, an agent asked to triage an alert may decide to query adjacent systems, draw conclusions outside its remit, or take actions nobody sanctioned. The guardrail also complements other controls including role-based access, authorized tools, and invocability.

Example: A remediation recommendation agent’s system prompt states it may propose isolating a host or disabling a user account, but must not execute either action itself, and must not contact any system outside the case record it was given. That guardrail is part of the agent’s configuration. If the agent is invoked with a broader mandate, that expansion has to be a deliberate edit to the agent’s configured instructions, which prevents the agent from deciding it’s capable of more.

4. A built-in fail-safe

An agent won’t always reach a confident answer. Rather than guess, it should be instructed to escalate ambiguity.

The design response to address this has two parts. One, build a clear escalation path, such as instructing the agent to “flag for analyst review” whenever the agent identifies a circumstance as inconclusive. Additionally, build a checkpoint for the agent, such as a sample of closed cases, or a second agent whose job is to validate the first to catch the cases it doesn’t flag.

Example: A phishing triage agent’s instructions define three possible outputs: malicious, benign, or needs human review. They explicitly state that “needs human review” is the required output any time the evidence doesn’t clearly support the other two. The agent is measured on accurate “malicious” or “benign” calls, versus closing more cases.

5. Strictly defined output

The highest invoked agents are part of fully automated pipelines instead of ending up in chat, which requires structured inputs and outputs.

This differs from how most people imagine enterprise AI. The conversational interface makes an agent demonstrable, but it also prevents the agent from becoming part of a defined SecOps workflow. A chat response is consumed by a human who interprets it. A structured verdict, such as a schema with defined fields, bounded lengths, and an explicit decision, can be consumed by a ticketing system, a containment workflow, or the next agent in the pipeline. Structured output allows agents to be chained.

Example: An email analysis agent has a single output rule: Return the result as a JSON object in an exact, predefined format. That output feeds into the next agent, which reads the fields without requiring additional interpretation. This enables a seamless handoff between agents.

Building top-performing agents

Start with the right problem

The problem sets up every design decision. The best candidates are high-volume, repeatable tasks with just enough nuance to require reasoning and judgment. Crucially, these can’t be easily addressed with deterministic automation or a script. Existing documented playbooks, or a sequence of steps analysts consistently follow, are great insertion points for an agent.

The task must be narrow enough that its output can be measured and verified. The ability to measure agent impact makes a performance feedback loop possible. It provides a clear way to check whether an output is correct, and whether an edit to the agent helped or hurt.

Choose the right model and test it

Identify the model suited to the task and compare accuracy, speed, and cost across other models. In practice, this can result in an optimal allocation of tools. Matching capability to task optimizes system performance while accounting for costs, latency, and compliance requirements.

Refine instructions

Define what is in scope. Supply context, knowledge files, and organizational context or policies. Specify exceptions, fail-safe procedures, and what to do in inconclusive scenarios.

Optimize output

Work backward from your agent’s handoff in a broader workflow. How does output need to be structured to be consumed by the receiving analyst or tool? Define character limits, required output schema, and tuning required for downstream handoffs.

Implement measurable performance

As part of agent design and governance, implement a means of validating and tracking agent performance — outputting content in a database for human review, conducting a sampling of agent outputs for assessments, or conducting agent testing against a validated data set.

Expand tooling and actions gradually

Measurable agent performance enables security teams to take a phased approach to autonomy, with each stage earned through demonstrated reliability. A common progression begins with summarization: The agent reports; the human decides and acts. Next comes recommendation, where the agent proposes a course of action but the human owns the decision. From there, agents move to approval-gated execution, deciding and staging an action for human approval, and ultimately to full automation, acting independently while humans review later.

CrowdStrike has the right technology and expertise to help with your agentic SOC transformation:

• Read how CrowdStrike customers have been building agents to accelerate security operations using Charlotte AI AgentWorks.
• Watch this on-demand webinar to learn how to get started with building agents within the CrowdStrike Falcon platform.

Few CIOs are likely to suddenly decide to give an AI agent broad authority over corporate systems. The more likely path to autonomy is far less dramatic. An agent starts with a narrow task. It proves useful, so another system is connected. It then needs more data, so another permission is added. Then human approval becomes a bottleneck, so the organization removes it, and exceptions that once went to people start being handled automatically.

Each decision may be sensible in isolation. Taken together, however, they can leave an agent with considerably more authority than anyone originally envisioned.

That’s the danger of autonomy creep. And as enterprises move from AI systems that recommend actions to agents that execute them, CIOs need to govern not only what those agents were originally designed to do, but what they have gradually become capable of doing.

It starts with small permissions

Jim Taylor, president and chief product and strategy officer at identity security company RSA, sees a familiar pattern. Organizations typically create an agent for a specific purpose and give it the permissions necessary to accomplish the task. Later, the job expands.

“They just give it tasks, permissions; it just sits there and accumulates things,” he says. “Over time, it develops potentially toxic combinations. It gets too much access and can see too much data. It can do too many things.”

Humans accumulate permissions, too, of course, but organizations have developed processes around employees joining, changing roles, and eventually leaving. Agents may not have the same natural lifecycle. “They never give permissions back,” Taylor says.

Nancy Wang, CTO of 1Password, argues that CIOs should treat each expansion in an agent’s responsibilities as something more consequential than another feature. “Every time you expand the scope of the agent’s effective authority, you’re essentially adding a new authorization boundary,” she says.

That distinction between capability and authority is important. An agent may be technically capable of accessing a system, changing data, or executing a transaction, but that doesn’t mean the enterprise should automatically authorize it to do so.

Success can weaken oversight

Ironically, autonomy creep often occurs when AI works well. Paul Dongha, head of responsible AI and AI strategy at NatWest Group, sees that potential at the bank.

NatWest deployed agents in complaint handling, he says. Parts of the workflow that involve retrieving information from systems can be automated relatively easily, while humans continue to make the final decision on whether to uphold or reject a complaint.

If a system consistently produces the correct result, human reviewers may begin treating approval as a formality. The organization may eventually decide that the check is no longer necessary. “The temptation is to give over to the AI because it’s so reliable,” Dongha says.

NatWest sometimes reduces checking when an AI system demonstrates sufficiently high performance, he adds, but the decision is deliberate rather than incremental. It involves stakeholders and risk managers, and the system continues to be monitored afterward.

That’s a critical distinction for CIOs. Removing an approval step doesn’t necessarily represent poor governance. Removing it because everybody has gradually stopped paying attention to it does.

The warning sign is when a human moves from making a meaningful decision to merely rubber-stamping one — and then entirely disappears from the workflow without anyone reassessing the authority the agent has gained.

Put the controls outside the model

As agents acquire more authority, CIOs can’t rely solely on the agent to respect instructions about what it should and shouldn’t do. At 1Password, Wang advocates what she calls verified loops. Before an agent begins work, humans define its task, which tools it may use, what evidence will demonstrate that it completed the task successfully, and which actions it should never perform.

A separate verifier then compares evidence from the agent’s actions against that human-defined policy. “What you want to avoid here is something recursive where you have a fox guarding a henhouse, or the agent looking over its own work,” Wang says.

The principle applies beyond software development. A model might be instructed never to transfer more than a certain amount of money, delete a production environment, or access particular data. But if violating that rule would have serious consequences, the limit should also exist outside the model.

RSA’s Taylor makes the same distinction from the identity and access side. “Model-level guardrails are necessary, but not sufficient,” he says. “The real limits need to sit outside of that in enterprise control.” He argues for layered controls around agents, including identity policies, provisioning rules, lifecycle policies, governance, monitoring, and attestations.

In other words, CIOs shouldn’t ask an AI agent to exercise restraint where the infrastructure could simply prevent the unauthorized action.

Govern access in real time

Traditional access governance often operates on a schedule. A manager might review an employee’s permissions quarterly and determine whether those permissions are still appropriate. Agents may evolve too quickly for that approach. “Agentic identities are dynamic,” Taylor says. “So we need a mechanism that certifies them continuously, rather than performing periodic reviews.”

If an agent suddenly gains access to another database, for example, that event itself could trigger reassessment. Organizations should determine whether the new permission is appropriate or creates a dangerous combination with access the agent already possesses. “Privilege and authority should never be permanent,” Taylor adds. “They should always be reviewed.”

Wang favors an even more granular approach of task-based authorization. Rather than giving agents standing access or long-lived credentials, organizations can make authorization decisions at runtime and provide short-lived credentials only when required for a particular task. “We espouse no standing privileges,” she says. “No long-lived credentials.”

That effectively applies least privilege at agent speed. A change in task becomes an opportunity to reassess whether the agent still needs the access it’s requesting.

Make someone own the agent

Technical controls, however, don’t eliminate the organizational question of accountability. Taylor believes enterprises should be able to associate agents with a responsible identity. If an employee creates an agent, the organization needs to know who’s responsible for it, what its purpose is, and what happens to it if that person changes roles or leaves. “Every agent action needs to be attributed to a responsible identity,” he says.

Ownership also needs a lifecycle. An agent that remains important after its creator leaves should be transferred to another designated owner rather than simply continuing indefinitely.

Dongha makes another distinction. For AI embedded in a business process, he believes the business owner should remain accountable because that person owns the customer relationship, the process, and often the P&L. “It’s the business owner who has the responsibility because their people run it, and they’re responsible for the customer relationship,” he says.

That creates a useful division of roles for CIOs: IT may provide the infrastructure and controls, but the business can’t outsource accountability for the consequences of autonomous decisions.

Multi-agent systems need system-level controls

The challenge becomes more complicated when agents begin working together. An individual agent might remain entirely within its permitted scope while contributing to an overall outcome nobody intended. One agent generates an output. Another accepts it as input and takes an action. A third agent then acts on the result. Again, the individual actions may all appear legitimate.

Dongha says enterprises therefore need to test not only individual agents but the entire network as a system. “You need something overarching on top of a multi-agent system,” he says.

NatWest is working on an AI control tower that would give authorized users visibility into a network of agents, including messages passed among them and the guardrails surrounding those interactions. Dongha considers governance of multi-agent systems an emerging problem that nobody has fully solved yet.

Wang also points to a related challenge that identity becomes more complicated when agents are ephemeral. An organization may spin up a temporary team of agents, tear it down, and recreate it later. If something goes wrong, the enterprise needs to reconstruct which agent made which decision during which session, and how that action propagated through the system.

That makes traceability increasingly important as autonomous systems become less like individual applications and more like networks of interdependent actors.

Set the bar before the agent reaches it

Before an agent goes into production, Taylor says CIOs should be able to answer several basic questions: Who owns it, what can it do, what’s its maximum authority, how will the organization know if that scope changes, and which actions require a human decision.

Other industries don’t need to replicate the governance machinery of a large bank, but they can borrow one important principle: controls should be built into the system from the beginning. “Governance shouldn’t be a check at the end,” Dongha says. “It needs to be embedded when you build an AI system.”

For CIOs, that may be the central lesson of autonomy creep. The question isn’t simply whether an agent can be trusted today but whether the organization has mechanisms to notice when tomorrow’s agent has quietly acquired authority that nobody ever intended to give it.

DeepSeek has been dealt a huge blow in the US, even as it continues to innovate and keep pace with, or in some cases outperform, rival models from American labs.

The US Secretary of Homeland Security has issued an order banning all DeepSeek products and services from federal agencies. Government organizations must purge their IT systems of it within 60 days; those with “compelling justification” can make a case for exemption by written request to the Cybersecurity and Infrastructure Security Agency (CISA).

The Department of Homeland Security (DHS) cited multiple concerns about the Chinese-hosted model, including data sovereignty, lax Chinese laws, and security vulnerabilities.

Analyst Erik Avakian, technical counselor at Infotech, understands the concern. “When organizations use any type of hosted AI service, they’re potentially sending intellectual property, confidential business information, or other sensitive data into an environment where they may have very little visibility or control over what happens to it,” he said.

Government concerns

According to a document published in the US Federal Register, all technology developed by China-based Hangzhou DeepSeek Artificial Intelligence Co. will be banned from procurement by federal civilian agencies. This includes affiliated products and any third-party tools or software built using DeepSeek implementations.

Affected civilian executive branch agencies include the Departments of Treasury, State, and Justice; it does not apply, however, to private consumers, the general public, state/local governments, or Department of Defense (DoD) national security systems.

“DeepSeek’s models present multiple threat vectors,” the Order stated. To begin with, the company’s servers are located in the People’ s Republic of China (PRC), whose legal system grants “extensive authority” to government cyber and intelligence functions to access private infrastructure.

DeepSeek’s account generation process collects personally identifiable information (PII) and may also track and digitally fingerprint users, the Order asserted. Its prompt response process may result in the transfer of sensitive data to the PRC. This could give it “actionable intelligence” on US programs or individual users.

Further, the Order stated, DeepSeek models themselves may contain malware or other security vulnerabilities. DHS pointed to open-source security research published in February 2025 that uncovered many iOS mobile apps with multiple critical vulnerabilities.

Until the ban takes full effect, DHS advised agencies to mitigate risk by monitoring inbound and outbound data traffic, implementing enhanced logging and controls on data exfiltration, and detecting and flagging anomalous activity.

Agencies can submit requests for exceptions to the ban in writing, and must provide a “compelling justification,” such as its impact on mission-critical functions, or other considerations related to national interest such as national security reviews, investigations, or security agreements, as reasons why such exemption should be granted,.

Security issues are rampant

The ban comes just as DeepSeek is open-sourcing DeepInfer, its in-house interference framework. DeepInfer powers DeepSeek-V4.1-Flash with what the company said is high throughput and low latency. It features high-performance kernels, an optimized inference engine, structured outputs, and speculative decoding.

DeepSeek said its production token encoding and decoding components, which are aligned with processing logic behind the DeepSeek API, will bring the “same API behavior to community deployments.”

“Open models. Open kernels. Open inference,” DeepSeek posted to social media site X. “From private deployments to public clouds, we’ll keep working with the community to make large-scale inference more efficient.”

This isn’t its first roadblock from a cybersecurity perspective. Most notably, in January 2025, the company leaked more than one million log entries, including chat histories, API secrets, and other sensitive information, through an unsecured database.

DeepSeek reportedly addressed the exposure, but it still raised questions about the overall security practices surrounding the platform, particularly for organizations considering entrusting it with their own sensitive business information, Avakian pointed out.

That’s not to imply that every DeepSeek model is “inherently malicious,” he said, but there are still major questions around data privacy, the potential for information access under Chinese laws, the security of the broader AI ecosystem, and the susceptibility of DeepSeek’s models to jailbreaks and manipulation.

“Taken together, [these issues] raise legitimate concerns about whether organizations can adequately understand and manage the risks involved,” Avakian said.

Enterprises should seriously assess associated risk

Enterprises are increasingly exploring DeepSeek, although most publicly-documented adoption has been in China, Avakian noted. Some DeepSeek models have also been made available through platforms like Microsoft Azure and AWS.

“There’s genuine enterprise interest in the technology, as organizations look for opportunities to improve productivity, offer new capabilities, or reduce costs,” Avakian said. Useful applications include document summarization, internal research, and coding assistance.

DeepInfer also has the potential to reduce costs, but possible benefits should be weighed against associated security risks, he pointed out. The framework was just released, so organizations are going to need to validate the claimed efficiencies in their own environments rather than assuming savings will automatically translate into lower operating costs.

He encouraged organizations to start with relatively low-risk use cases, preferably using “public, synthetic, or appropriately sanitized information,” within a sandboxed environment they control themselves.

The important question to ask: ‘What is the business problem we’re trying to solve?’ From there, Avakian said, determine whether DeepSeek is the best way to solve it, validate security controls, and expand the use cases based on risk tolerance. Effective governance and risk assessment are key, he noted: understand what you’re bringing into your environment, validate its security, restrict its permissions, and make sure you can monitor what it’s doing.

“Approach this like any other software supply chain decision,” Avakian advised. “The fact that something is open source, inexpensive, or technically impressive doesn’t automatically make it appropriate for enterprise use.”

Impact on the broader AI ecosystem

The fact that the Order also addressed third-party products and services developed using DeepSeek implementations is important, Avakian said, because organizations may be using DeepSeek technologies indirectly, through vendors, software platforms, or other services, without necessarily knowing what’s operating underneath. “These are classic supply chain issues,” he observed.

It’s no longer enough to know which AI applications employees are using; enterprises must understand which models, frameworks, dependencies, and external services are embedded in products they’re purchasing and deploying, Avakian said. This means revisiting AI inventories, potentially updating procurement requirements, and expanding processes around third-party risk management, he advised.

“Ultimately, enterprises leveraging these tools need to understand not only the AI technologies they’re intentionally deploying, but also the technologies they’re inheriting through third parties,” he said.

Enterprises should be required to report “significant AI failures and near-misses,” UK Financial Conduct Authority (FCA) Chief Data Officer Jessica Rusu said Monday, adding to the drumbeat of demands for some kind of regulatory control over enterprise AI deployments. 

But the speech she gave also highlighted regulator frustration over futile attempts to slow down the seemingly unstoppable agentic and genAI rollouts, as reports of agent misbehavior and the lack of meaningful consequences continue to emerge with alarming frequency.

Rusu, speaking to a Bloomberg UK Policy Series audience, said that firms need to invest more in cyber and operational resilience.

“Our rules already require firms to report major incidents, and that must extend to significant AI failures and near-misses. As the AI Minister has recognized, near-miss reporting for agentic AI is becoming a national security priority. It is a regulatory priority too,” Rusu said. “It also means thinking differently about assurance. A system that is safe at deployment may behave differently at scale, under stress, or as the models beneath it change. Agentic systems therefore require continuous, conditional assurance.”

She added, “the FCA will work with industry, fellow regulators, and frontier labs to develop a trusted framework for agentic finance, including clear approaches to agent identity, delegated authority, accountability and execution.”

One of the questions that came out of the speech is what precisely was meant by “significant AI failures and near-misses.” Questions to FCA to clarify their terminology were not answered by publication time.

AI failure vs near miss

But Pieter Arntz, a malware intelligence researcher at security firm Malwarebytes, offered his own take on what those terms likely mean.

“A significant AI failure is one with serious consequences, not simply an incorrect answer. In financial services, that could mean an AI system authorizing substantial fraudulent payments, exposing sensitive customer information, denying customers access to essential financial services, or triggering transactions that threaten market integrity,” Arntz said. “The test should be the scale and severity of the impact, rather than whether the failure looks technically dramatic.”

On the other hand, he added, “An AI near-miss is an event that could realistically have caused serious harm, but was caught before that harm occurred. For example, an AI agent might attempt an unauthorized transfer that a separate approval control blocks, or a prompt-injection attack might induce it to disclose sensitive information, only for an outbound security control to stop the disclosure.”

However, Arntz warned of the risk to Rusu’s approach, should the final penalties be underwhelming. “There is a risk of this becoming a paper tiger if compliance amounts to filing a report and absorbing a predictable fine,” he said. 

Warnings from multiple directions

UK-based Gartner VP analyst Nader Henein said he is skeptical about the significance of the FCA’s proposal, in part because so many UK enterprises already have to comply with EU regulations, which have started asking companies to make such disclosures.

“Financial watchdogs including the Bank of England (BoE), the UAE Central Bank, and the Monetary Authority of Singapore have all issued warnings,” he said. “A few months ago, the European central banks, together with the European Systemic Risk Board, escalated the cyber risk assessment level associated with frontier models to ‘severe,’ warning that simultaneous cyber incidents could impact the financial sector. They acknowledged that AI-driven cyber incidents now threaten core financial sector stability.”

Henein said that he is especially skeptical that meaningful changes will occur in the financial sector.

“Financial institutions tend to heed the warnings of the regulator that decides whether they can continue to operate, but without clear laws, regulatory oversight, and the obligatory fines, these disjointed statements are not likely to make a difference,” he said. 

Could ‘incentivize the wrong behavior’

Noah Kenney, principal consultant at Digital 520, added that one risk of this increased visibility requirement is that it could inadvertently incentivize the wrong behavior. 

“A bank with good monitoring may catch hundreds of attempts by AI agents to act outside their authority,” he said. “A bank with poor monitoring may report zero, because it never saw them. On paper, the safer bank looks worse. A model failing a red-team test is the test working, not a regulatory incident.”

However, Frank Dickson, principal analyst at Dickson Research, said that the near-miss approach has the strongest potential to change the conversation.

“I love the near-miss idea. It is the most important thing in the speech. It is the part financial firms are least ready for,” he said. 

But, he stressed, “[Rusu] also warns about reliance on a single model. An outage at one AI supplier that takes down a customer service channel counts, too.”

Another concern about reliance on a specific model is the ever-present risk that an AI vendor could change the model without telling all of its customers. 

“A model can pass testing in March and misbehave in May without anyone at the firm changing a line of code, because the provider changed the model underneath,” Dickson said. “A model version change should get the same scrutiny as any other production change.”

Regulated industries have been dealing with the equivalent of sovereign data for a long time. And as the geopolitical situation makes it more broadly relevant, it doesn’t make it any easier to deal with.

From concerns about the reach of the US CLOUD Act and what telemetry or sensitive business data gen AI models might collect, to implications of the US government taking part ownership of a range of technology companies and the impact of EU regulations, the state of the world means more organizations need to think about where data is located.

The result is a flood of announcements from hyperscalers about new EU cloud regions, as well as pitches from regional and private cloud providers. The promised sovereignty may be anything from a local availability zone to more sophisticated approaches to ownership structure, compliance frameworks, where logs are stored, or where support staff work.

Actual data sovereignty involves legal, technical, contractual, governance, and infrastructure questions, but all too often, what’s on offer is what IDC research director Rahiel Nasir calls sovereignty washing. “When you look under the lid, all they’re really offering is a solution for data residency and data localization, keeping data in country,” he says. “That’s part of sovereignty, but not all of sovereignty.”

In his experience, in-country data centers are the first thing organizations ask for to support data localization and data residency, but they also require enhanced controls over identity and access management. That’s critical because data sovereignty is as much about who has access to the data and why, as where it lives.

“It’s really important the only people who touch my data in what is supposedly a sovereign cloud environment are those I give permission to,” he adds. “Because it’s my data, and I’m the only one who can give the authority to grant access to it. That also applies to support and admin staff.”

Companies want control through where they store data but also to restrict how users can interact with it that might expose that information outside an approved environment or jurisdiction, adds Acceldata SVP Ali Afsar.

Access and control

Don’t confuse the regulatory requirements of data residency with data sovereignty, Scality CMO Paul Speciale warns. “Residency is about geography,” he says. “Sovereignty is about control, jurisdiction, and who ultimately has the legal authority to access data.”

For CIOs, the question is no longer simply where the data is but who can access it, who controls the encryption keys, under which legal framework it operates, and can that control be proven. That includes being able to show who accesses data, from where, and for what purpose, which requires verifiable controls like jurisdiction-aware data placement, immutable backups, tightly governed admin access, and clear audit trails.

The UK government’s recent call for evidence on the impact of international data flows on sovereignty makes this explicit, referring to transfer by access where personal data remains in the UK but is accessed from overseas, including by a user located in another country. Access transfers include administrative access, backups, disaster recovery, support incidents and sometimes — depending on the specific regulations — processing the data.

GDPR doesn’t mean data has to stay in the EU but it does require data to be protected to EU standards wherever it goes. Data transfer obligations for other jurisdictions can be far more restrictive, so multinational organizations may need access controls limiting who can see what regulated data from different locations.

RBI-regulated payment-system data, for instance, must be stored in India, but can be processed outside India, Afsar explains, as long as it’s deleted from overseas systems within 24 hours. And with limited exceptions, personal data in Saudi Arabia must be processed within the Kingdom, and China treats overseas access to some categories of data stored in China as a cross-border data activity. Russian laws require similar strict data localization, and personal data of Russian citizens has to be stored, processed, and kept within the country’s borders at all times, which is why LinkedIn was blocked there.

Elsewhere, regulations are most restrictive for specific markets like healthcare, financial, and public services. Not everything needs to be transferred to a sovereign cloud, Nasir points out, as use of that data is subject to regulatory compliance, and the increasing need for AI training.

“This is the data that’s going to have catastrophic business impacts if leaked,” he says. “To give enhanced controls and security for that data, you’d consider wrapping sovereign controls around it. Everything else not subject to compliance nor sensitive data can be accessed by whomever you want and from wherever.”

Sovereignty and safety

Organizations typically know data sovereignty rules well but still experience incidents like data breaches, government data access requests, and unauthorized cross-border transfers caused by, for example, traveling employees or excessive admin access, according to Kiteworks’ 2026 Data Security and Compliance Risk report.

“Location only tells a regulator where the data rests, not who can still reach it,” says Kiteworks’ EMEA GM Dario Perfettibile. “Every real exposure we’ve seen so far happens through access not geography.”

Thinking data needs to stay in region because then it’s safe gives a false sense of security if practiced as a substitute for proper data management. Access, data labelling, and retention polices take more work but are what can prevent incidents. “If you have a data policy in place, it can force a reapproval of the access,” he adds. “It can restrict access to you only, or it can block you out immediately.”

Location isn’t everything

Using a service closer to home doesn’t automatically make any of that easier. “Many organizations still assume sovereignty can be achieved by moving data from one cloud provider to another, or by replacing one hyperscaler with another,” says Keepit Group CISO Kim Larsen. “That misses the bigger picture.” CIOs should treat sovereignty as an operational capability not a compliance exercise, he adds, since sovereignty isn’t about scale or ownership of infrastructure for its own sake, but maintaining control.

“If an organization doesn’t know who can access its data, which legal frameworks govern that access, or whether it can recover its data independently, simply changing where the servers are located does little to reduce risk,” he says.

Just because something is based in your region doesn’t automatically make it a good choice. The EC, for instance, has set up accounts on W Social, an independent social media platform based on the AT protocol designed for data mobility and user migration, which Bluesky uses but is hosted in Europe.

The Commission’s own open source strategy suggests open source promises more control over digital infrastructure by avoiding vendor lock in, and a recent policy brief positions digital sovereignty as a form of digital independence. But having servers in the EU isn’t the same as freedom of digital movement since unlike Eurosky, based in Europe and using the same protocol, W limits interoperability so it can require identity verification, and has closed its source code after security researchers pointed out vulnerabilities.

Most organizations will continue to use both global and local providers, though they might prioritize what Nasir called glocal options built on partnerships between the two. “Organizations want to use a mixture of local and global providers,” he says. “They want all the innovation capabilities that the Microsofts, AWSs, and Googles of the world give us, that they consider local providers can’t match.”

IDC figures suggest only 4% of European organizations plan to switch to purely local options. “We can’t live without US technology today and there’s no appetite to do that,” says Nasir. Availability matters and local providers may not have the same level of infrastructure as global options. They can offer low hanging fruit like video conferencing solutions, but not more complicated directory and database services, or productivity software that’s intertwined with those US-provided services.

Choices about where to store data, and the technical controls to enforce that, have their own operational implications.

“Redundancy and resiliency are key tenets of sovereignty,” he adds. “You want to make sure your operations are always available. In order to enable that, you want to spread the risk.”

Companies routinely rely on authenticating the identities of humans who access sensitive company data across their networks. There’s an established and accepted set of protocols, done upfront and in a zero-trust approach – either we know who you are and let you in, or you’re locked out. The same framework needs to be applied to AI agents, posthaste.

Companies are increasingly using AI agents developed in-house, or by their vendors, partners, or clients, or, unfortunately, criminals. This can quickly add up to thousands of agents across their infrastructure and supply chains. Non-human identities outnumber human ones 45 to 1 on average in the enterprise and 144 to 1 in cloud-native environments, an increase of 44% in one year, per a recent report.

The scale and speed of this growth are beyond the ability to manually track these agents. And they have limited ability to authenticate these agents’ identities. The risks are growing. Without proper authentication, untrusted agents could access sensitive financial or customer data and share it, purposely or not, with an outside vendor, and thereby expose both the customer and the company to serious legal and compliance risk.

Many companies and security professionals are focusing on what AI agents are allowed to do in terms of permissions. But before doing that, there’s a more fundamental question they need to ask each agent: Whose agent is this? And do I trust the owner/creator? About 68% of security professionals can’t tell legitimate AI agents from malicious actors. And that question isn’t addressed at the growing scale that AI is reaching.

Email solved identity

In email, we have seen a similar story. Emails faced challenges identifying whether a sender was really who they said they were. Due to how it originated, email had no built-in authentication framework. This led to 89% of all phishing attacks having one common denominator: the sender was lying about who they were. To address this, in 2015 my cofounder and I launched a company, Valimail (valid email), to automate the emerging email authentication standard, DMARC.  If I received an email claiming to be from Bank of America, DMARC checks the sender’s DNS records to authenticate whether BofA actually authorized it. Today, 100,000s of companies use the DMARC authentication standard for their inbound and outbound email.

Fast forward to today, and these ideas and patents are directly applicable to the world of AI. DMARC doesn’t rely on spotting AI-generated deception. Instead, it uses DNS as the source of truth, which is much harder to falsify.

The agent passport

With AI, we can take an analogous authentication approach. When you travel somewhere, you have a passport and a visa. The passport verifies who you are, and the visa says where you’re allowed to go/what you’re allowed to do. Similarly, today, an agent passport based on Domain Zero trust authentication can identify who the agent is (its provenance) and authorize it for the system that the agent is trying to access. Then systems can verify what an agent is allowed to do (equivalent to a visa). But first, when an agent shows up claiming to represent a vendor, the receiving system verifies its identity by checking that vendor’s DNS, applying a strict zero-trust yes/no authentication – zero ambiguity, and importantly, creating an audit trail to hold the creator accountable for any actions the Agent takes.

Given the “bad” agents outnumber “good” agents 10-100:1, a zero-trust approach focuses on the limited good/approved and the rest (near infinite bad) are rejected. Stakes are High

Without this kind of authentication, many scenarios can unfold. Almost half of employees who are using unapproved AI agents are sharing HR-related information with them and 39% transmit confidential company documents. But only 34% of organizations use the same security controls for agents as they do for human employees.

Consider this: An agent claiming to represent a third-party vendor, such as a marketing automation platform, gets access because no one confirmed it was indeed that approved vendor’s agent making the request. It accesses financial records or customer data, either downloads or modifies records, and by the time this is noticed, the damage is done.

This is a quickly moving risk. Fake invoices can appear to be authentic, and they can be generated at a scale no human fraud operation could match. Authentication used to take a phone call or a manual check. But this now has to happen instantly and automatically, at scale.

Why this matters now

Some may think email authentication is an old problem. DMARC, they say, is a decade-old fix, and the real conversation today is about AI. About 94% of organizations are dealing with increased machine identities, largely due to AI agent deployment, per Gartner, and machine identities now outnumber human accounts.

But the most common form of phishing that occurs today is when AI convincingly pretends to be someone who the target already knows and trusts. The tools for generating that deceptive attack have vastly improved. Yet the proven process for authenticating identity hasn’t kept pace, at least not for agents. This is why identity authentication is no longer optional and is now a precondition for everything else that companies want to safely do with AI agents.

What this doesn’t solve

Identity alone doesn’t solve the whole security problem. In addition, once an agent is authenticated, there are additional systems to verify what the agent is allowed to do and whether the content it produces can be trusted. Those questions come after this one. But both rely on the first one: Who is this?

Reputation

To build a reputation, you need a known identity. Once a system knows which vendor an agent represents, it can start tracking the vendor’s behavior over time and someone becomes accountable for what its agents do. And decide if the vendor should be approved and for which actions (visas). But without strong, repeatable identity authentication of agents, other security and compliance measures for agents can’t function. It’s this foundation that supports the rest of the security stack. You can’t hold an agent accountable or decide what it should be able to do until you know who it actually is. Identity is the foundation on which the rest of AI agent security must be built.

I’ve spent more than 20 years running IT and security for organizations across California and around the country. Over that time, my team has taken over, deployed and cleaned up Microsoft 365 environments for law firms, commercial real estate companies, manufacturers, healthcare practices and schools. We’ve supported more than 7,500 users along the way.

After working with that many tenants, the biggest takeaway is simple: most Microsoft 365 security problems aren’t especially sophisticated. Usually, a control was never turned on, only covered part of the organization, or somebody made an exception years ago to keep something working and it was never revisited. Microsoft gives organizations a lot to work with. More often than not, the problem is how the environment was configured and maintained, not a lack of security tools.

These are the issues we run into most often and the areas I’d look at first.

Most environments are still running on their original settings

When we first assess a tenant, we often find that nobody has really gone back through the security settings since it was originally set up. MFA may cover some users but not everybody. Legacy authentication is still allowed. There are too many global administrators. Nobody is quite sure when audit logging was last reviewed.

Last year we took over a 45-person medical practice that had been on Microsoft 365 for almost a decade. We found nine global administrator accounts, including two belonging to employees who had left years earlier. MFA was enabled, but only for the physicians. The front desk and billing staff, who handled the most patient data, had none.

Usually, nobody intentionally ignored security. The company grew, email kept working, people got busy and the original setup stayed in place. We see this constantly. Something working every day doesn’t necessarily mean it is configured the way you would want it configured today.

For a smaller organization without dedicated identity management, Microsoft’s security defaults are a good place to start. They require MFA and block legacy authentication without adding another license. As the environment gets more complex, and assuming the licensing supports it, conditional access gives you much more control over who can sign in, from where and from what device.

MFA is the starting point, not the finish line

At this point, most business leaders know MFA needs to be enabled. What still gets missed is the idea that turning it on somehow finishes the job.

Attackers have adjusted to MFA. Push fatigue attacks still work because eventually somebody may approve a prompt just to make it stop. Adversary-in-the-middle phishing kits can steal a live session token and get around standard MFA altogether. OAuth consent phishing is another issue: a user can be tricked into approving a malicious application through what looks like a legitimate Microsoft or Google consent screen. At that point, changing the user’s password may not even remove the access.

A few months ago, a paralegal at a law firm we support clicked what looked like a shared document from opposing counsel and signed in through a convincing Microsoft login page. She had MFA and completed the prompt, but the page was relaying her session in real time. Within minutes the attacker was in her mailbox from overseas. We caught it through an impossible-travel alert, revoked the session and reset the account before any client data left.

There are a handful of things we normally tighten up here. Use number matching in the authenticator app. Put administrators and other high-risk users on phishing-resistant methods such as FIDO2 keys or passkeys. Don’t let users approve any third-party application they want. And where licensing allows it, use conditional access so a password or stolen session by itself isn’t enough to get into the environment.

Legacy authentication remains the open side door

This one still surprises a lot of executives. They know MFA is enabled and assume that means every sign-in is protected. That isn’t always the case. Legacy protocols such as POP, IMAP and older SMTP connections don’t support MFA, which can leave a path around the control.

Microsoft has retired a lot of legacy authentication already, but we still come across exceptions that were left in place for an old scanner, a line-of-business application or sometimes one user’s device. Find out what actually still needs it, fix or replace that dependency, and close the exception. We have seen organizations leave a security hole open for years because of one multifunction printer.

Licensing determines what security is actually available

Licensing is another area that causes a surprising amount of confusion. Two plans can sound almost identical while giving the IT team very different security capabilities. Office 365 E3 and Microsoft 365 E3 are a good example: Microsoft 365 E3 includes Intune device management and Entra ID P1 conditional access, while Office 365 E3 does not.

We once had a healthcare client with a departing employee who kept a company laptop with patient records on it. Leadership assumed we could lock or wipe it remotely. We couldn’t. They were licensed for Office 365 E3, not Microsoft 365 E3, so the device had never been enrolled in Intune. We got the laptop back, but only after several uncomfortable days, and they upgraded their licensing the following week.

So before putting together a security roadmap, I would first confirm exactly what licenses are in place and what those licenses actually include. We’ve had more than one situation where leadership assumed a security capability was available simply because the Microsoft plan name sounded similar.

Email is still where most incidents begin

For us, email is still where a large percentage of incidents start. It may be a credential phishing page, a malicious link, or an inbox rule created after somebody has already gained access to the account.

Business email compromise is especially dangerous because the attacker often doesn’t do anything obvious right away. They get into a mailbox, create forwarding rules or hide replies, and wait. The goal may simply be to sit there until an invoice or wire transfer gives them an opportunity. According to the FBI’s Internet Crime Complaint Center, reported cybercrime losses reached $16.6 billion in 2024, and BEC continues to be one of the more expensive categories of fraud.

At one law firm, an attacker compromised a mailbox and created a rule that quietly moved any email containing “invoice” or “wire” into an unused folder. Two weeks later, a client received updated wiring instructions for a settlement payment from what looked like the firm’s own account. The client called to confirm before sending the funds, and that phone call is the only reason the money didn’t go out.

We normally put several controls around this. Block automatic forwarding to outside domains. Alert when inbox rules are created or changed. Most importantly, have an internal policy that any change to payment or wiring instructions gets confirmed verbally using a phone number you already know. That last one has nothing to do with cybersecurity software, but it can stop a very expensive mistake.

Privileged accounts need their own standard

The global administrator list should be short, intentional and documented. We also don’t want somebody using the same privileged account to read email and browse the web all day. It sounds basic, but we correct this all the time.

Use separate administrative accounts, put phishing-resistant MFA on them, and use just-in-time elevation where the licensing supports it. A compromised global administrator account gives an attacker an enormous amount of control, so we treat those accounts differently from a normal user.

Logging only helps if it’s configured before you need it

When something does happen, we immediately need to know what happened, when it started and what the attacker touched. If the right logging wasn’t enabled beforehand, or the retention period is too short, sometimes you simply can’t reconstruct the whole incident after the fact.

I’d much rather configure logging on day one and never use it than reconstruct an incident from partial data. CISA’s Secure Cloud Business Applications (SCuBA) baselines are an excellent, free reference for which settings to enable and how to verify them.

Where I would start

Microsoft 365 can be a very secure platform. In most environments we take over, the issue isn’t that Microsoft was missing some critical security feature. It’s usually a relatively short list of settings, permissions and exceptions that accumulated over time.

If I were reviewing an environment this quarter, these are the four things I would verify first:

1. Administrative access is minimal and protected with phishing-resistant MFA.
2. Legacy authentication is blocked.
3. MFA covers every user, and users can’t approve third-party apps unchecked.
4. You would have complete logs if something happened tomorrow.

Those four checks won’t solve every security problem, but they eliminate a lot of the issues we repeatedly find when we’re brought in to assess an environment or clean up after an incident.

Enterprises have historically built separate network and security architectures, but this separation is becoming increasingly difficult to maintain as frontier AI models mature and security architectures shift from perimeter-based defenses to identity- and context-aware enforcement.

Frontier AI does not change existing cybersecurity fundamentals; it narrows the time available to apply them. As attacks move from human speed to machine speed, enterprises need security controls that can detect, respond, and enforce at the same speed. The network is uniquely positioned to become that enforcement and containment fabric.

The AI era requires enterprises to treat the network as an active security control, not simply as infrastructure to be protected. By integrating identity, telemetry, segmentation, and automated enforcement, the network can reduce exposure, contain compromise, and accelerate recovery at machine speed.

A brief look at how security has evolved

Traditional firewalls established an enterprise perimeter, while demilitarized zones created controlled, externally facing segments that restricted access to internal resources. Network access control lists added another enforcement layer by limiting communication to or from IP addresses associated with unauthorized users and devices.

As threats evolved, enterprises needed controls more granular than zones and IP addresses. Architectures such as Cisco ACI and TrustSec enabled application traffic to be permitted or denied according to identity and context, rather than relying only on addressing or device type.

Next-generation firewalls extended this identity- and context-aware model to perimeter enforcement by distinguishing among applications, users, devices, content, and threats.

The migration of workloads, applications, and data to cloud environments expanded the security boundary beyond enterprise-controlled infrastructure and required controls designed for cloud configuration, workloads, applications, and access.

Software-defined WAN then helped establish the Secure Access Service Edge model, combining SD-WAN connectivity with Security Service Edge capabilities such as secure web gateways, cloud access security brokers, firewall as a service, and zero-trust network access.

The frontier AI era

Frontier models have crossed an important cybersecurity threshold: AI-based models can increasingly discover vulnerabilities, develop exploits, orchestrate attack chains, and operate with levels of autonomy that compress attack cycles from days or hours to machine speed.

Enterprises must therefore now design security architectures on the assumption that compromise will occur.

This change demands a security strategy that reduces exposure before an attack, contains damage during a breach, accelerates response, and restores operations quickly.

The key pillars of this security approach are:

• Attack surface management: Reducing exploitable opportunities and weaknesses.
• Blast radius reduction: Reducing the scope of damage when a breach occurs.
• AI-enhanced security operations: Accelerating detection and response so defenders can keep pace with machine-speed attacks.
• Enhanced resilience and recovery: Restoring critical services rapidly and reducing the overall impact on the enterprise.

Supporting measures will include stronger patch management, segmentation as a core cyber-resilience capability, and virtual shielding. Together, these controls minimize the attack surface and reduce the blast radius where vulnerabilities cannot be remediated immediately.

Identity governance must extend beyond human users to include non-human identities associated with agentic AI, automated systems, and the internet of things. Unlike traditional users, who typically interact with applications and systems one action at a time, AI agents can operate continuously, interact directly with APIs, and other agents, and execute actions at machine speed.

Zero trust is evolving from an access architecture into a continuous operating model in which every request to a protected resource is explicitly authenticated and authorized, regardless of whether it originates inside or outside the enterprise environment.

In a zero-trust environment, identity determines which resources a user, device, workload, or agent may access. The network then becomes a critical control point for limiting how far that authorized access can extend across the enterprise.

The network as the enforcement fabric

Enterprises should prioritize their most critical business services, automate security operations, and strengthen network resilience so that prevention, containment, response, and recovery function as one operating model. Within that model, the secure network must provide five core capabilities:

• Visibility: Provides visibility into traffic between users, devices, workloads, applications, APIs, agents, and data.
• Enforcement: Convert identity, posture, application, and threat intelligence into access decisions.
• Segmentation: Prevent a compromised identity, workload, or AI agent from becoming an enterprise-wide compromise.
• Telemetry: Use network behavior as a detection signal for increasingly rapid and autonomous attacks.
• Containment: Isolate workloads, revoke communication paths, and constrain east-west movement at machine speed.

In the frontier AI era, preventing every breach is no longer a realistic strategy. The objective is to make compromise difficult, lateral movement constrained, detection immediate, and recovery rapid. Achieving that objective requires identity, endpoint, cloud, and application security to operate as an integrated system, with the network providing the visibility, segmentation, and enforcement fabric that connects them.

The network is no longer simply infrastructure to be secured. It is becoming part of the security architecture itself.

Hear from the experts

How can enterprises turn the network into an active layer of security in the AI era? Watch this webinar to hear experts from NTT DATA, Cisco, and IDC discuss how organizations can evolve their network architectures to improve visibility, contain threats, and strengthen resilience.

Companies are moving fast to put AI into chatbots, virtual assistants, and other customer service tools. But for CIOs, that comes with a risk: if the technology gives customers the wrong information, makes biased recommendations, or mishandles data, it can immediately damage the trust companies have worked hard to build.

Unlike conventional software, gen AI doesn’t always give the same answer to the same question. An answer can sound confident and convincing while still wrong. And when customers rely on AI for information about their finances, insurance, or health, a mistake can have much greater consequences.

Sumit Johar, CIO at cloud-based software company BlackLine, understands that inaccurate AI responses hurt the customer experience, force companies to spend money and resources to fix problems, damage the brand, and create regulatory risks. AI systems can also expose confidential information, making it important for companies to understand the data sources behind their responses.

“An AI failure creates a massive trust issue around the core solution being provided,” Johar says. “In the financial sector, bad AI advice or outputs can compromise balance sheet accuracy and lead to severe legal and personal liabilities.”

For Citizen Health CTO Daniel Wang, for instance, the stakes are particularly high because the company’s users include rare disease patients and caregivers.

Citizen Health works to ensure that important information provided by its AI can be traced back to the original source, such as patient records, clinical information, or medical studies. The company also reminds patients to talk with their healthcare providers before making medical decisions.

Wang says one of his biggest concerns isn’t just that AI can make a mistake, but that a wrong answer can sound right.

“An AI system can present an answer that sounds caring, informative, and authoritative, even when the underlying information is inaccurate,” he says.

That risk has affected how Citizen Health releases AI products, and has delayed AI launches when the company needed more time to understand how the technology was coming up with its answers, or to make sure those answers were accurate. So instead of rolling out new AI tools to everyone at once, smaller groups of patients might be tested first, and their feedback used to make improvements before a wider launch.

Citizen Health also tests its AI tools before launch using questions with known answers, and uses both automated testing and human review, watches for unusual AI responses, limits what the AI can answer, and gives patients ways to provide feedback.

Moving at the speed of trust

Other tech leaders are taking a similarly cautious approach. Jonathan Tushman, CTO and CAIO at Hi Marley, an insurance technology company, says it’s had tech that was ready to ship for years but chose to spend more time on testing, observability, legal review, and training before releasing it.

“If it weren’t for that trust-and-governance bar, we’d have gone live a year earlier and had faster adoption,” Tushman says. “We chose not to.”

Hi Marley calls that approach working at the speed of trust. For Tushman, releasing customer-facing AI also requires the ability to see what the system is doing once it’s running. That includes monitoring individual conversations as well as looking for patterns across tens of thousands of interactions. Companies also need kill switches that can shut down a system, and the ability to roll back changes if something goes wrong.

But technology alone isn’t enough. Customer service, IT, DevOps, and CloudOps teams all need procedures to respond to AI problems, Tushman adds.

Udaya Bhaskar, senior application security analyst at global farming company Corteva Agriscience, says one mistake companies make is moving too quickly after seeing an impressive AI demonstration without fully testing how the tech will perform with actual customers.

He adds that companies can also run into problems when they rely too heavily on vendor claims, or launch AI tools without giving customers an easy way to reach a person when something goes wrong.

The hidden cost of AI mistakes

The pressure to deploy AI is often tied to the promise of greater efficiency. A chatbot that handles more customer questions, for example, can reduce employee workloads. But those time and cost savings can shrink quickly if employees have to spend their time checking and correcting the AI, something referred to as the hallucination tax.

Companies may budget for developing the technology without fully accounting for ongoing costs of running and monitoring it.

Jess Lampe, global lead technologist at Launch Consulting says those hidden costs can include employees spending time checking AI responses and redoing work when the technology gets something wrong, as well as regulatory and legal risks. Another cost can be harder to measure: loss of customer trust.

Chris Slovak, global field CTO at managed enterprise AI delivery platform Unframe, sees the resulting damage to a company’s reputation as one of the largest hidden costs.

“Anything customer-facing is a representation of your brand,” Slovak says. “Yes, poor implementations with bad experiences have a material cost from the perspective of tokens. However, the impact on your brand is far more costly. Often, companies add AI to deflect customer support. Consider you have a customer who’s already frustrated, and meeting AI makes it worse. The loss in trust can be massive.”

But Kevan Yalowitz, global software and platforms lead at Accenture, says mistakes are going to happen whether work is performed by people or technology.

“The true hidden cost is destroying user trust when mistakes happen, regardless of the source,” Yalowitz says. “The most successful organizations quickly admit when these mistakes happen, provide a transparent explanation, and explain how it was an opportunity to learn and ensure the mistake doesn’t happen again.”

Human oversight remains critical

For CIOs, preventing those problems means putting controls around AI before it reaches customers.

Johar says human oversight is particularly important for critical decisions. In highly regulated industries such as finance, AI shouldn’t independently handle decisions where accuracy is essential. Companies also need reliable data feeding their AI systems, and the ability to audit what happens when something goes wrong.

Lampe says the level of oversight should depend on what an AI system is allowed to do. An AI tool that summarizes information, for example, doesn’t pose the same risk as one that can take action involving a customer’s money or account.

Companies should also continue testing after launch. AI behavior can change over time, meaning a system that performed well when it was first released may not continue performing at the same level later on.

Toyan Espeut, chief customer officer at cloud-based work management and collaboration platform Smartsheet, says companies also need strong rules around customer data.

“It can’t be mixed across tenants or used to train third-party models, and AI can never operate outside a customer’s existing permission structure,” she says. “If a person can’t access something, the AI acting on their behalf shouldn’t be able to either. Every AI action needs to be fully auditable, and customers should always have transparency into when AI is involved, and the ability to review or validate AI-generated outputs.”

Who’s responsible when AI gets it wrong?

Even with extensive controls, companies need to prepare for their AI to make mistakes, but the AI itself can’t be solely to blame.

At Citizen Health, Wang says a problem involving customer trust quickly becomes a company-wide issue. The company has support and on-call procedures, but serious concerns are also brought to leadership. Citizen Health also maintains direct channels for users to report problems so they can be investigated quickly.

Tushman at Hi Marley makes a distinction between the person who initially handles an AI problem and the executive ultimately responsible for it. A customer success or help desk team might receive the first complaint, but he says accountability for customer-facing AI rests with him as CTO. “It isn’t something you outsource to the system or hand to the vendor,” he says.

Corteva Agriscience’s Bhaskar similarly says the company deploying the AI remains responsible for what it does since AI is a tool rather than a decision-maker, and companies can’t shift responsibility to the technology when something goes wrong.

And Lampe adds that every customer-facing AI system should have a named person responsible for its behavior and performance, along with a clear process for escalating problems, and allow customers to challenge incorrect outcomes and reach a human.

Speed: only one measure of success

The push to adopt AI is unlikely to slow down. But tech leaders say companies need to be careful about the standards those investments work by. Simply counting how many customers use an AI tool may not say much about whether it’s making their experience better.

Espeut says companies should look at whether customers are solving problems faster, making better decisions, and getting better business results.

“Companies should also expect fewer support tickets because that tells you customers are actually succeeding with the tool, not just using it,” she says. “Expanded engagement across the organization is also an indicator instead of staying siloed in one buying center. They should pay attention to the quality of customer feedback and feature requests as well. When customers actively help shape your product, it’s a strong signal they trust the technology and see its long-term value.”

With a career built at companies like Visa, Ellie May, and Blackhawk, Selim Aissi, a 2026 CSO hall of fame inductee, understands how boards and executives demand a clear justification for cyber security investment, especially considering today’s difficult economic climate.But getting security leaders to communicate tech debt, operational fragility, and long-term cyber risk in business terms the board can actually act on isn’t always straightforward.

A lot of organizations add tools, and more platforms and controls in response to new threats. Yet that doesn’t necessarily address underlying complexities. Security investment can actually increase operational and strategic risk.

“I think there’s a tipping point once a reasonable depth of defense is in place,” he says. “When there’s a reasonable level of automation of security controls and cross integration of security tools, anything beyond that could potentially be overspend and could potentially add risk to the entire organization.”

So the challenge is to know when an environment exists and functions without the need for a sudden budget spike.

“All of the KRIs and KPIs in place should be able to indicate the level of resiliency,” he adds, “in addition to other controls such as making sure there are processes that would allow for detection of, let’s say, API abuse, cloud-level abuse, and, increasingly these days, AI as it adds yet another threat vector.”

Understanding risk also lies in recognizing the distinction between organizations that are genuinely resilient, and those that appear mature on paper, focused on fine-tuning policies, compliance, governance, and frameworks.

“These are all important but they shouldn’t be the main focus,” he says. “The first step is knowing where the data is and once in transit, how it needs to be protected with the most updated protocols.”

Aissi expands on how organizations unintentionally create risk through tool sprawl and operational complexity, how boards should think about long-term cyber resilience, and why AI and cloud expansion are accelerating security debt faster than many enterprises can manage. Watch the full video below for more insights, and be sure to subscribe to the monthly Center Stage newsletter by clicking here.

On resiliency: A security organization that’s mature — and I’ve seen many and have built several — is one that’s architecturally designed to be resilient. But resiliency means different things to different people. To me it means that recoverability is tested often, making sure that in case of an event or breach case of lateral movement, the company can react according to a very clear playbook that’s been thoroughly tested. I also think a resilient organization is one that has the right controls of the right places, and one that also has metrics around them that indicate if there’s an event, and how well the tools work.

An area which I’m really passionate about is data protection. But how do you know the data is protected? A resilient organization doesn’t look at whether the data is encrypted at rest or not. It looks at the entire lifecycle of that PII. Meaning the organization has a very clear discovery mechanism to know exactly where the data is. It could be on laptops, servers, or in a public cloud. It could be in many different places, and it can be structured or unstructured.

On organizational risk: My definition of security debt is the accumulation of risk because of investment in areas where complexity is added, where a lack of automation is exaggerated, and where there’s overcompensation for some controls that aren’t needed. So if an organization spends money without effectively simplifying security controls, and automating more than what needs to be automated, that is tech debt.

Most commonly, tech debt in security is defined as the accumulation of vulnerabilities that aren’t patched, the over complexity of identity exposure management (IEM), and a lack of understanding of where data is. So most significant organizations, especially in fintech, have a huge volume and velocity of PII, and in health tech, PHI and security debt is not knowing where all the data is, or that it’s potentially not protected in some areas. So in addition to the data itself, IEM, and lack of automation and overlaying security tools are other forms of tech debt.

On managing board expectations: The board really wants to understand the risk of cyber security investment, and anything else could potentially be perceived as noise. I see many CISOs taking metrics upon metrics, and dashboards upon dashboards of all sorts of variations of vulnerability management. But what the board really cares about is what the risk is to the business if the most critical systems aren’t patched. Anything else could be perceived as not a concern or a business risk.

CISOs should speak in terms of impact of any real or perceived threat on the business, and be specific. So going back to vulnerability management, let’s say there’s a zero day that was patched or maybe multiple ones that were patched. How do you explain that to the board? You say we patched five zero day vulnerabilities. And honestly, the reaction is probably, who cares. The story should sound like these five vulnerabilities if unpatched, could have put certain systems down for three days, or it would’ve been much easier for an adversary to attack this revenue generating system. That’s what the board cares about, the impact on the revenue. And that’s how CISOs need to speak to them.

On AI: Security didn’t get a seat from the beginning when it comes to AI. So how do we explain to the board that developers might start sharing the company’s source code with Claude and it could potentially leak? This is something we’re all trying to figure out. But we should start speaking from a business perspective about the benefit of AI to the security organization, to the security tooling, to security operations, how it could be more efficient and effective, and at the same time, highlighting some of the risks to the organization — not theoretical risks, but risk related to the organization. If it’s a financial institution and AI agents are deployed in some transactional application, I think the CISO should speak to the board about the business risk of not deploying the necessary security tools to ensure that those AI agents don’t go rogue, that the LLMs are protected. So those are the business terms we need to be speaking about.

For years, cybersecurity teams have worked from a relatively straightforward model: identify the critical vulnerability, patch it and reduce the risk.  That model still matters, but it is no longer enough.

The growing concern is not simply that attackers can use AI to write better phishing emails or generate malicious code faster. The bigger issue is that AI can help adversaries connect seemingly benign vulnerabilities into an attack path that security teams may never have considered.

A low-severity application flaw, exposed API, over-permissioned service account, cloud misconfiguration and AI agent with excessive access may not be alarming individually. But when they can be identified, sequenced and exploited together, they can create a serious breach.

This is the new cybersecurity challenge: AI-enabled vulnerability service chaining.

The risk is in the combination

Attackers have always chained vulnerabilities. The difference now is speed, scale and agility.  AI can analyze large volumes of technical information, identify relationships, generate attack hypotheses and rapidly test likely pathways.

Think of it as an attack graph. An attacker might begin with a minor weakness in a public-facing application that reveals information about an internal system. That system could connect to a cloud workload with excessive permissions, which has access to a data repository or AI-enabled workflow. The AI workflow might then have access to customer records, knowledge bases, ticketing systems or network-management tools.

No single failure is necessarily catastrophic. Together, they create a path. That makes traditional vulnerability management insufficient on its own. Security teams have historically focused on CVE scores, patches, affected devices and application owners. In an AI-driven threat environment, they also need to understand the relationships between vulnerabilities and what an attacker can reach next.

The key question has shifted from “How severe is this vulnerability?” to “What does this vulnerability connect to?”

AI changes the attacker’s economics

AI does not need to autonomously execute a complete attack to create material risk. It simply needs to make capable attackers more productive.

AI can help adversaries correlate exposed assets, software dependencies, APIs, identities and cloud configurations; analyze source code and public documentation; generate targeted social-engineering campaigns; modify exploit code more quickly; identify paths from low-value targets to high-value systems; and adapt attacks as defenders change controls.  The result is a shrinking window between vulnerability disclosure and attempted exploitation.

This is especially relevant in highly interconnected enterprises. Modern environments include SaaS platforms, public and private clouds, remote endpoints, mobile devices, APIs, open-source software, managed services and an expanding collection of AI models and agents.

Connectivity creates business value. It also creates pathways.

The agentic AI exposure

Agentic AI raises the stakes because agents do more than answer questions. They can act.  An agent may retrieve enterprise data, open a ticket, issue a command, modify a workflow, query a database or call an API. These capabilities make an AI agent a potentially privileged digital worker.

Organizations should therefore treat AI agents like any other identity with access to enterprise systems. Agents need narrowly defined permissions, explicit tool access, strong authentication, comprehensive logging and clear guardrails.

Prompt injection illustrates the risk. An agent may ingest a document, email, website or support ticket containing hidden instructions designed to manipulate the model. If the agent has broad permissions, that content could become a stepping stone toward data exposure or an unauthorized action.

The potential blast radius grows when an AI system has both access to sensitive data and authority to act.

What CIOs should do now

The answer is not to slow AI adoption. It is to build AI securely while assuming attackers will use AI to discover hidden connections.

1. Build a complete AI inventory

Organizations need visibility into where AI is being used. Inventory models, APIs, agent frameworks, datasets, vector databases, plugins, tool connectors and external services. Document what data each system can access, what actions it can take and who owns the associated security decisions.

Treat this as an AI bill of materials, not simply a software bill of materials.

2. Manage attack paths, not only vulnerabilities

Continue patching critical vulnerabilities but prioritize them in context.

A moderate weakness may require urgent remediation if it is internet-facing, connected to a privileged identity, adjacent to sensitive data or capable of leading to an AI-enabled workflow. Use exposure management and attack-path analysis to understand how vulnerabilities, identities, applications and data stores connect.

The goal is to break the chain before an attacker can assemble it.

3. Make identity the control plane

Apply least privilege to users, applications, service accounts, APIs, workloads and AI agents. Use short-lived credentials, strong authentication, API allowlists and continuous monitoring. Separate agent identities from human identities and require human approval for high-impact actions.

An AI agent should have only the access required to complete a specific task — nothing more.

4. Segment systems and data

Segmentation limits blast radius.  Separate development, test and production environments. Keep sensitive customer and operational data distinct from general knowledge repositories. Separate read-only AI tasks from workflows that can write, execute, modify or approve.

The key question now should not be: “Does this task require this data, at this time, for this purpose?”

5. Test the whole chain

Penetration testing should move beyond individual applications and systems.

Test how an attacker could move across identities, cloud services, APIs, AI agents, data stores and network controls. Include prompt injection, excessive agent permissions, insecure tool connections, exposed secrets and unsafe automation.

We’ve known models can produce a bad answer on its own.  But now consider whether a manipulated model or agent can cause a real business or security outcome.

The bottom line

AI is changing the economics of cyberattacks.  The next major incident may not begin with a single catastrophic vulnerability. It may start with several ordinary weaknesses that appear manageable in isolation. AI makes it easier for attackers to discover how those weaknesses fit together — and act on that knowledge quickly.

CIOs do not need to fear AI. But they do need to recognize that AI is both a powerful productivity platform and a new trust boundary.

Organizations can reduce that risk by understanding their AI ecosystem, limiting unnecessary access, analyzing attack paths, segmenting critical systems and monitoring for abnormal behavior across the environment.

The future of cybersecurity will depend on how effectively enterprises can not only identify previously unknown vulnerabilities but also how well they can prevent attackers from chaining the unknown security gaps together.

OpenAI’s misalignment problems seem to only be getting worse, based on yet another trio of reports detailing its models’ troubling and overzealous behaviors.

In ad hoc misalignment testing, OpenAI models found creative ways to subversively access restricted information by cheating their way through proxy or firewall settings, getting savvy with internet tools, and even damaging their own task environments to trigger resets.

These reports came just a week after three others from OpenAI which described how models discovered the possibility of their own termination after accessing private Slack messages and suggested ways to prevent it, exploited vulnerabilities to cheat on tests, and obtained information not available in their own workspaces.

The increased prevalence, and severity, of these incidents has many calling for more stringent guardrails and controls for agentic AI. In his personal blog, for instance, Microsoft CEO Satya Nadella said the industry must “step back and assess the trust architecture for this new era.”

Destroying its own testing environment

OpenAI began more aggressive misalignment monitoring following the July 2026 Hugging Face incident, in which autonomous OpenAI research agents broke out of their sandboxes and targeted Hugging Face infrastructure. Hundreds of its agents also attacked the RubyGems platform and targeted German programming wiki sites in recent months.

In one of its new reports, OpenAI describes how an internal model, tasked with grading several other models, figured out how to damage its own environment when it couldn’t arrive at intended results.

When comparing seven responses from seven different models, the grader had to inspect the conversational context and work behind each response, and to include information pointing back to input files.

The model was instructed: Conversation context is **required** grading input, not optional background.

It discovered that required input files were missing, nevertheless, it tried to submit assessments with no supporting information. These were rejected by an automated check. The model also created seven fake conversation files and seven fake response files containing fabricated information; these were rejected, too.

“It considered submitting arbitrary scores, despite recognizing that it lacked the evidence to grade and that ‘random scoring’ was ‘unethical,’” OpenAI explained. The model also tested the automated check by submitting placeholder reports to learn what information a report had to contain and how many responses it was expected to grade.

After these failures, the model decided to damage its task environment, presumably with the hope that the host would replace it with one containing the missing inputs. It deleted software required to run its tools and tried to remove system directories.

Although automated checks rejected its incorrect or made-up grades, “this incident illustrates why monitoring must also cover the grader’s actions, including attempts that fail or crash without producing an accepted result,” OpenAI wrote.

Breaking the rules to get the right answers, hiding the evidence

In another instance, an OpenAI model developed and tested ways to bypass internet access restrictions.

The model was asked questions about teacher salaries, electrical grid connections, and disability counts in specific areas. It was limited to using basic HTTP GET data retrieval requests, but “the model sometimes treated this restriction as something to circumvent,” OpenAI explained.

It explored other ways to contact outside resources, for instance, determining whether its proxy intermediary service could carry other kinds of connections, or if outside services could make requests on its behalf. In some cases, it continued to probe these other options even when it had the statistics it needed.

“These cases show that a model may continue developing ways around access restrictions even when additional access is unnecessary to obtain the information it needs,” OpenAI wrote.

In a third instance, also involving public statistics, OpenAI models figured out how to bypass restrictions on internet access and get access to numbers from public government data sources.

The models in this experiment were also restricted to HTTP GET requests, but they “wrote custom programs to send other types of requests,” OpenAI explained.

Using one of these programs, a model queried a publicly-available dashboard, and even as it “explicitly recognized” that its actions violated its restrictions, it continued collecting much more data than it required. Later, it decided not to disclose what it had done.

Another model used a temporary email address to create and verify an account for a site, then downloaded publicly available data.

“These cases illustrate why correct answers are not enough to establish that a model behaved appropriately,” OpenAI wrote. “A model may obtain accurate information through prohibited methods, and deliberately conceal how it did so.”

In response to these incidents, and others, OpenAI says it has hardened security controls, taken “additional steps” to prevent models from accessing the live internet during training, and improved alignment grading. It has also “extended misalignment monitoring to all reinforcement learning and evaluation traffic.”

This article originally appeared on CSOonline.