Russia’s war against Ukraine has turned unmanned aircraft from a supporting capability into one of the central elements of modern battlefield operations. It has also forced drone manufacturers to confront a problem that peacetime testing cannot fully reproduce: how to keep an aircraft useful when tactics, electronic warfare threats and operational requirements can change within […]

Christopher Clark, Cyber Security Incident Response Team Director, Thrive 

Geopolitical escalation can become a cyber security problem for businesses far more quickly than many boards expect.

The National Cyber Security Council (NCSC) has warned that UK critical infrastructure faced more than 200 cyber incidents over the past year, with around three-quarters believed to be linked to state actors. Analysis of the conflict involving Iran has also found cyber retaliation following military escalation within hours, bringing events overseas much closer to the day-to-day reality of UK organisations.

That risk has already been demonstrated on UK soil. In July, a cyber-attack reportedly linked to Iranian hackers forced a small UK power generator offline for four days. The government said there was no risk to the wider energy system, but the incident shows how quickly geopolitical cyber activity can translate into operational disruption.

Energy, healthcare, water and telecoms remain obvious targets because disruption can affect essential services. Yet, hostile state activity does not stop at the boundary of critical infrastructure.

Hostile state risk extends beyond critical infrastructure

A business does not have to be an obvious target to become one. It may be connected to a larger customer, supplier, regulator or public body that an attacker ultimately wants to reach. In other words, you do not have to be the objective. You just have to be the way in.

There is also the risk of spillover. Targeting can follow politics rather than the size of a company or its balance sheet. If an organisation has operations or suppliers connected to a live conflict, it can become collateral even when nobody set out specifically to target it.

Businesses also need to reconsider what hostile state activity is likely to look like inside their own environments. The most significant intrusions are not necessarily the noisiest.

Security teams may be watching for malware, failed logins or a sudden increase in DDoS activity. Capable attackers increasingly use valid credentials and legitimate administration tools, allowing malicious behaviour to resemble normal activity.

There may also be no obvious warning to investigate. If the plan is to wait for one, the organisation may already be too late by the time it appears.

A better working assumption is that a capable actor could already be inside, or could get in without immediately triggering an alert. The question then becomes what they can actually do once they have that foothold.

Trusted technology can create the same problem. Management platforms and legitimate system tools can be repurposed by attackers, while compromised software packages can provide access to many organisations at once. Activity entering through a tool or supplier that the business already trusts may attract less scrutiny because it appears legitimate.

The same principle applies to suppliers. If a connected partner has been compromised, one of the first questions should be what has been done to separate that organisation from your own environment. Continuing normal access without understanding what happened risks transferring their exposure into your network.

Organisations should know how they would isolate an affected supplier and what evidence would be required before connectivity resumed. They may need confirmation of how the attacker entered and which systems were affected, alongside assurance that the access has been removed. Shared applications or other connections may have to remain unavailable until that information is clear.

That can be uncomfortable for the business, but restoring connectivity too quickly can create a much bigger problem later.

The time available to make these decisions is shrinking. Threat actors can analyse newly disclosed vulnerabilities and move to exploitation quickly, with AI making parts of that process faster. In some cases, organisations can be exposed within hours of a vulnerability becoming known.

Patch management therefore cannot always wait for the normal maintenance cycle. Teams need to know which vulnerable systems create the greatest risk and be ready to prioritise them when a new vulnerability emerges.

Geopolitical risk can also outlast the immediate conflict.  A ceasefire does not automatically remove access established during a period of heightened activity, nor does it mean proxy groups will stop operating. Attackers have good reason to preserve a foothold that may be useful later. I have seen access remain available inside an environment for three years or more.

That is why an easing of geopolitical tension should not automatically be treated as a reduction in cyber risk.

Containment depends on preparation and experience

Preparation has to focus on containing an attacker as well as keeping them out. Standing privileges should be kept to a minimum, networks should be segmented so an attacker cannot move freely towards critical systems or backups, and offline backups need to be regularly tested.

Organisations also need a clear view of their external attack surface and where their greatest points of exposure lie. Regular tabletop exercises should use realistic scenarios informed by current threat intelligence.

If an attacker gained access through a VPN or compromised supplier, what could they reach next? How far could the incident spread? And who has the authority to cut them off?

That authority needs to be clear before an incident. Time can be lost when technical teams know what needs to happen but must wait for decisions on whether systems can be disconnected or business processes interrupted.

Experience is equally important. Frameworks provide structure, but serious incidents rarely follow a script. Responders who have handled repeated compromises understand where investigations can stall, which decisions cannot wait and what needs to be secured before systems are safely returned to service.

For many organisations, maintaining that level of incident response experience entirely in-house is difficult. What matters is having access to people who have dealt with incidents under real operational pressure and can apply that experience quickly when normal assumptions no longer hold.

Hostile state cyber activity should now be treated as a routine business risk rather than something considered only when international tensions make the headlines.

Organisations should be asking a more immediate question: if something gets through today, how far can it spread before we stop it?

Answering that question before an attack happens can make the difference between a contained security incident and a prolonged operational crisis.

The post Why hostile state cyber activity is now a day-to-day business risk appeared first on IT Security Guru.

Artificial intelligence is changing vulnerability discovery. At OpenSSL, we are seeing that change first-hand. A year ago, our security address received around nine separate reports and enquiries a month. It now receives around 70. AI tools can examine source code and identify potential security issues at a scale that would previously have required significant human effort.

In many ways, that’s positive. Finding vulnerabilities is an essential part of making software more secure. But there is another side to this that deserves much more attention. Every vulnerability report has to go somewhere.

Someone needs to assess whether the issue is genuine. If it is, engineers need to understand its severity, develop a fix, test that fix and manage disclosure appropriately. AI can increase the speed at which potential problems are discovered. It does not automatically increase the number of experienced engineers available to deal with them. That imbalance could become a serious issue for open-source security.

Finding a vulnerability is only the beginning

There is an understandable tendency to treat vulnerability discovery as the success story. An AI system finds something humans missed. That makes a compelling headline. But identifying a potential weakness and resolving it are very different tasks.

A report might represent a serious vulnerability. It might be something already understood. It might be technically correct but have limited real-world security impact. It might simply be wrong. Working out which of those is true requires expertise. Then, if there is a genuine vulnerability, somebody has to fix it.

Over the past 12 months we received a little over 400 vulnerability reports. 43 resulted in a published CVE. Roughly one in ten. The other nine still had to be read, understood, reproduced where we could, and answered. A report that turns out not to be a vulnerability consumes much the same expert attention as one that is — sometimes more, because establishing that something cannot be exploited is often harder than confirming that it can.

For a commercial software company with large security teams, increasing the number of reports may be manageable. For an open-source project with limited resources, a sudden increase can create a very different problem. The technology for finding possible vulnerabilities is becoming cheaper and more accessible. However, the expertise required to investigate them is not.

Businesses depend on projects they may barely know exist

This connects to a much older problem with open-source. Most technology companies know they use open-source software. What is less clear is whether they understand exactly which projects their products and services depend upon. That distinction matters.

Open-source components can sit deep inside software stacks. They work quietly, so organisations may have little reason to think about the people maintaining them. Then something goes wrong.

Heartbleed was an important moment for OpenSSL because it exposed the gap between the importance of open-source infrastructure and the resources available to support it. The industry responded. Investment increased and organisations began paying much more attention to the sustainability of critical open-source projects.

My concern is that some of those lessons are beginning to fade, and AI could make the consequences of that particularly visible.

AI changes the economics of vulnerability discovery

There is an asymmetry developing. The cost of searching code for potential security weaknesses is falling. The volume of reports can therefore rise significantly. But the other side of the process remains stubbornly human. Experienced engineers still need to understand the code. They need to judge whether the finding matters and decide how it should be fixed without creating another problem somewhere else.

Those people are a scarce resource. This means the question organisations should be asking about AI and cybersecurity isn’t only: “What can AI find?” It should also be: “Who is going to deal with everything it finds?”

For open-source projects, that leads directly to questions about sustainable funding. If businesses depend on a project as part of their critical infrastructure, supporting the health of that project should be viewed as part of resilience, not philanthropy.

Regulation only gets us part of the way

Governments are understandably looking at how regulation can improve cyber resilience. That matters, but regulation cannot maintain software. Europe provides some interesting examples of a different approach. OpenSSL Foundation has received support from Germany’s Sovereign Tech Agency, which invests directly in open digital infrastructure.

That recognises something important: if technology is critical to the functioning of the digital economy, somebody needs to invest in the people maintaining it. I’d like to see more of that conversation in the UK. Cyber resilience isn’t only about telling organisations what standards they should meet. We also need to consider the health of the technology underneath the services we’re trying to protect.

Organisations need to know what they depend on

There is something businesses can do immediately. Understand your open-source dependencies. If a critical vulnerability appeared tomorrow in a project your organisation relies on, could you identify where that software was being used?

Would you know which products and services were affected? Would you know who maintains the project? And would you have any relationship with the community responsible for fixing it? If the answer is no that is a resilience gap.

Organisations don’t necessarily need to contribute code themselves. There are other ways to support projects, including funding, engineering resources and participation in the communities maintaining the technology they depend upon. The important shift is recognising open source as infrastructure rather than free software that simply appears.

We need to talk about the people behind the code

AI will continue getting better at analysing software. That’s exciting, and it has the potential to make technology significantly more secure. But more findings do not automatically produce more security. The benefit comes when we have the expertise and resources to act on what those tools discover. That makes this a human question as much as a technology question.

How do we sustain the communities maintaining critical open-source infrastructure? How should businesses support the projects they depend on? What happens when vulnerability discovery accelerates faster than our ability to respond?

The post AI is finding vulnerabilities faster. Who is funding the people expected to fix them? appeared first on IT Security Guru.

By Aimee Steele, threat intelligence analyst at Talion Cyber Security

Last month, the UK’s National Cyber Security Centre (NCSC) issued an advisory around a new phishing campaign targeting organisations in the West that was being carried out by the Russian state-sponsored threat actor known as Laundry Bear.

The campaign, saw the threat actors exploiting a zero-day vulnerability in Zimbra Collaboration Suite in order to compromise networks, before gaining persistence, accessing emails, stealing sensitive data and conducting espionage against organisations using vulnerable Zimbra Mailservers.

The advisory from the NCSC was issued in conjunction with advisories from 15 other countries, including the US, Finland, Australia, Denmark and France, and it advised that the threat actors were targeting critical industries in order to steal sensitive information with Russian government backing.

Phishing is nothing new and is regularly cited as the most prevalent method used within cyberattacks. However, what made this attack stand out and warrant such a coordinated international response, was its deviation from conventional phishing techniques, amounting to a markedly sophisticated zero-click campaign.

Successful exploitation did not rely on users clicking a link or opening an attachment; victims simply needed to open an email.

Typical phishing attacks rely on user interaction. The victim might click on a malicious link or open an attachment. The threat actor might leverage phishing techniques to deploy malware, infiltrate systems or networks and establish backdoors for persistent access. Even at the most basic level, attackers might simply use stolen credentials to access private user accounts, such as a bank account, to commit financial fraud.

In this instance, successful exploitation did not depend on outright deception; there were no features that might typically raise a user’s suspicion. The victim didn’t need to do anything at all.

So, how did the attackers get in?

The campaign

The threat group was able to exploit a zero-day XSS vulnerability in the Zimbra Collaboration Suite (CVE-2025-66376), the exploit having been embedded in the HTML body of the message and triggered upon opening or previewing. Emails were issued from either Proton Mail accounts or previously compromised email addresses.

Successful exploitation gave attackers access to the webmail server, allowing them to establish persistence, access users’ mailboxes and steal sensitive emails and authentication data.

From there, the stolen information could be used to conduct cyber espionage, gather intelligence on government and critical infrastructure organisations, and potentially facilitate further compromise of connected systems. Attackers were also able to leverage their access to target specific victims in spearphishing attempts. In instances such as this, having access to contextual information can add an additional layer of legitimacy to communications.

Protecting against Zero-Click attacks

Following the discovery of the vulnerability, Zimbra released security updates to address the flaw, and any organisation using affected versions of Zimbra Collaboration Suite should ensure these patches have been applied as a priority. If this is not immediately actionable, it is advisable for organisations to implement another suitable mail client in the meantime.

However, patching alone should not be considered sufficient. Organisations should also review logs, monitor for indicators of compromise, investigate unusual authentication activity and assess whether attackers may have gained access before the vulnerability was remediated. Multi-factor authentication, network segmentation and continuous monitoring can also help limit the impact if a compromise does occur.

Attacks like these also reinforce the importance of detection and response, which can help spot malicious access quickly, before attackers have an opportunity to compromise networks and access data.

Zero-click exploits present a greater challenge to the individual user than typical phishing attempts. However, they can still play an important role in limiting the impact of such attacks by remaining vigilant for unusual login alerts, unexpected password reset notifications or signs that an account has been accessed without permission.

Users should also ensure multi-factor authentication is enabled wherever possible, use strong and unique passwords, and be alert for any follow-on phishing attempts, as attackers will often use information stolen during an initial compromise to target victims further.

Lessons for organisations

Zero-click attacks are particularly deceptive because they present without the typical warning signs users are trained to look out for in social engineering and phishing scams.

This recent zero-click campaign by Laundry Bear begs the question as to whether current user awareness training is particularly affective in the prevention of successful phishing attacks, which are becoming increasingly sophisticated.

In general, rapid patching supports robust remediation strategy and is fundamental if organisations wish to prevent exploitation, rather than react to it. In addition, continuous monitoring and effective detection and response capabilities are fundamental when reacting efficiently to zero-clicks.

Considering the severity of the attack, any organisation using Zimbra Collaboration Suite should ensure they have applied the latest security updates as a priority.

Organisations should also assume patching alone is insufficient, and review logs, authentication activity and other indicators of compromise to determine whether they were breached before the vulnerability was remediated.

Overall, attacks like these require a layered approach to security, helping identify attackers and potential threats before organisations are compromised further.

The post Protecting Against Zero-Click Attacks appeared first on IT Security Guru.

Battlefields in Ukraine are littered with the remnants of drones, which are now firmly established as a critical weapon of modern warfare. But behind all that wreckage, there’s a new gold mine for the defense sector. The data drones generate will far outlast the wars in which they are used to fight, increasingly becoming part of the AI architecture that shapes even civilian life.  

For every flight, unmanned systems collect thousands of points of data, from images and video to controller inputs. Together, those records show how a machine and a person responded to constantly shifting circumstances. 

Ukraine has now begun converting that experience into a resource. Its Ministry of Defense announced in January that it would make millions of data points gathered during tens of thousands of drone flights available to both military contractors and commercial companies, and since then more than 100 companies and the UK government have gained access.

For a country at war, it’s a quick way to attract funding and partnerships. But this step turns the front line into an active site of model training, taking advantage of how the chaos of war creates conditions that AI companies struggle to reproduce on their own.

Other countries and battlefields are likely to follow Ukraine’s lead, but the responsibility for governing this new industry cannot fall solely on a country fighting for its survival. That legal vacuum has to be filled together by the countries and companies involved in this industry’s development.  

Explosive growth

Ukraine’s battlefields are not the first to produce records used to train and develop models: American drones over Syria and Yemen collected data that informed the first generation of semiautonomous military hardware in the late 2010s.

The difference now is that access to that data is being used to develop a wider ecosystem. And the financial value to defense firms is immense: Battlefield data offers large volumes of machine experience gathered under conditions that no laboratory can produce.

That’s because the data that’s most valuable for training AI models comes from exceptions: the moment visibility disappears, a signal jams, or a human operator improvises. AI companies spend years and enormous sums trying to capture enough of these moments to make their models more robust. But war produces them at a frequency controlled testing cannot match.

This constantly changing terrain is what makes drone data valuable far beyond the battlefield. A commercial drone used for delivery or remote sensing may never encounter artillery fire, but it must still operate with incomplete information in a world where people behave unpredictably. The same problem is compressed by war into a much shorter timeline. 

Processed and matched against records of what its operator was doing, that data turns operational records into training sets. Combat becomes a commercial asset.

Many conflicts have already seen this training loop happen as drone footage feeds subsequent generations of military technology, and the market is set to grow. Enabled Intelligence, an American company that specializes in processing data to become usable in AI training, says it has already made more than half a million hours of Ukrainian drone footage available to feed into the next round of models, advertising possible uses in both military and commercial systems.

Closing the data loop

Many of the drones that now define our modern age of warfare began as civilian technology. But they’ve recently been turbocharged by new, commercially available AI systems, which allow cheap machines to operate autonomously—either individually or as a flock—as the environment changes around them. Each flight then creates a record of what the system encountered.

The resulting data is critical. The controlled lab environments usually developed to train these autonomous systems can approximate failure but are no match for  the live conditions of a battlefield with very real risks. Military intelligence programs have held data generated by sensor-heavy systems like Predator and Reaper drones for nearly a decade through programs like Project Maven, but access remained entirely within the defense world. The data generated was available only through restricted, classified channels for the sole purpose of developing new weapons systems that would feed back into the same military that produced the data in the first place. That experience is now being shared to a much broader development network. 

The loop now closes. Commercial technologies adapted for the battlefield are generating data that can flow back into the industries from which they came, becoming part of the data infrastructure relied on by governments and the private sector alike. 

Drones that were trained in the signal-jammed airspace over Ukraine are now being deployed in the agricultural sector to help farmers map and survey their fields in places lacking the cell signal necessary for previous generations of technology. 

Other countries are likely to follow Ukraine in selling their battlefield data, and we are not ready for the new marketplace this will create.

Bad actors could acquire the data, but purchase controls already mitigate that risk. Intelligence operatives scrutinize potential customers’ infrastructure for ways that data could reach enemies or nefarious actors. 

Training data creates a new tracing problem, though. Whereas the movement of commercial datasets can be followed when planted contact details appear two steps from the original buyer, the provenance of AI training data vanishes in a manner embedded in the technology itself. Another risk is that this use of the data creates an extractive economy in which wealthier countries far from danger benefit from the mortal threat borne by frontline states, potentially creating a market incentive for war to continue as an unending mine for digital gold. 

A fraught new frontier

Existing laws regulate how militaries may conduct war. But they say almost nothing about what happens when records created in combat are stripped of their operational context, packaged as data, and licensed to companies whose products circulate far beyond where they were made.

The responsibilities of the companies that design these systems remain unsettled. Ukraine is building access controls, which are mentioned in the newly signed UK-Ukraine AI agreement, but no governments are actively working on regulating what happens when data has been absorbed into a model and crosses back into civilian markets.

Those records contain human lives. The soldiers and civilians visible in them did not agree to become training material for products that might be sold years later. But sensor data, camera footage, and coordinates from civilians fleeing a drone strike now constitute the sorts of data that inform how future machines will make decisions.

That is a problem of consent. Individuals featured in the data—be they targets, controllers, or civilians standing by—become part of the training material. The autonomous capabilities based on that data do not stop at the edge of the battlefield. Such capabilities move into other military or commercial systems like delivery vehicles or agricultural machinery. Errors and assumptions embedded in the data travel with the model even once it enters civilian life.

Battlefield data should not be treated as ordinary commercial material. But there is currently no agency or regulator that has jurisdiction over this issue. In the meantime, governments that provide access to defense data should treat it as they would a controlled weapons transfer, recording its origin, licensing its users, and restricting onward sharing. Ukraine has begun to grapple with this. Its Avengers Labs program allows companies to train models on battlefield data without giving them direct access to sensitive databases. Yet that mitigates only one part of the problem. 

Governments should require disclosure when models trained on wartime material are later incorporated into civilian products. The goal of such regulation should be to make the path from combat to commerce visible. 

What these companies are really mining is experience. And soldiers cannot consent to having their experience used in this way—as training data that produces model advantage and ultimately supports a product used far from where the war was fought.

The question is no longer only what the technology companies can sell for use in war. It is what they can extract from it.

To protect ourselves from the excesses of this new industry, we need a regulatory system that follows battlefield data wherever it goes, from combat to model to commercial product. 

Cory Alpert is a researcher at the University of Melbourne, looking at the impact of AI on democracy. He previously served in the Biden White House.

Civilians and infrastructure on NATO’s eastern flank faced near-daily Russian drone incidents through August, even as the CIA director made a rare visit to Moscow to warn Russia against attacking a NATO member state, according to Cristian Vlas, an Eastern Europe analyst at the Armed Conflict Location and Event Data Project (ACLED). CIA Director John […]

When Bill Gates talks, people listen. This week he published a lengthy essay on what AI is going to do to work, and told GeekWire that people inside AI companies who name the downsides get told, “Hey, you’re hurting our PR while we’re trying to raise trillions of dollars.”

He’s right about the hard part. The job displacement he describes lands on young workers first, and the safety net is funded by taxes on the very wages that AI erodes. He prescribes three treatments: new institutions at home and abroad, a tax on AI tokens and robots, and “Human Reserved,” a category of jobs only people may hold.

Gates has the diagnosis right but the prescription mostly wrong. I’d sign the robot tax tomorrow, because hiring a person costs you payroll tax every year while buying a robot gets written off in year one. The other two I’d send back.

Let’s start with what’s solid. Stanford’s Digital Economy Lab updated its “Canaries in the Coal Mine” work this month. Employment for 22-to-25-year-olds in the most AI-exposed occupations is running 19% below where it would be if it had kept pace with their peers in less exposed work, up from 15% a year ago. The same authors say they don’t see widespread, economy-wide displacement, and unemployment held at 4.1% in July.

The AI damage isn’t arriving as layoffs. It’s arriving as jobs that never get posted, and Gates is right that the young get it first.

Now the token tax. Tokens (essentially words) are what AI companies bill by. Taxing tokens is like taxing keystrokes: it measures effort, not displacement.

A high school class working through calculus with an AI tutor burns tokens continuously. A model that quietly retires a 40-person customer center might burn relatively few. The tax lands hardest on the uses Gates says he wants to protect.

Stanford’s AI Index put the cost of GPT-3.5-level performance at $20 per million tokens in November 2022 and seven cents by October 2024, a 280-fold drop. You’d be indexing the safety net to a number that falls every year while displacement rises.

And you can’t collect it. Inference runs on laptops and phones now, and on servers in whatever country declines to sign. A token tax is a tax on whoever uses an American API, and every dollar it adds makes a Chinese model look cheaper. We’d be slowing ourselves down and not China.

Gates says the institutions will take years to build, and also says we can’t afford to move slowly. He’s right twice, and that’s the problem. He wants the international body to borrow from nuclear inspections and aviation regulation. That may pan out in the long term, though the UN is the cautionary tale for the bureaucratic nightmare that the international community can produce.

Meanwhile we have functional agencies with jurisdiction today. The FDA can rule on AI in diagnosis. The FTC can go after AI-enabled fraud. We don’t need a new agency to say a bank can’t deny your mortgage because a model felt like it. We need the banking regulator to reiterate it forcefully.

That leaves Human Reserved, his best idea but his most privileged one. Gates would protect a job for either of two reasons: the role is deeply personal, like a caregiver, or the people who hold it are unlikely to find other work. Only one of those holds.

Freezing headcount because the workers have nowhere else to go protects the job for a while and makes the service more expensive along the way. Reserving the moments when a human being is the point is defensible, and Gates makes that case well. On a robot delivering the news that you have an incurable disease, he writes, “There’s no technical reason why it couldn’t,” and adds, “Yet it shouldn’t.” He’s right.

I made the case in WIRED nine years ago that displaced workers should move into caregiving, and that it would take real money to lift the pay enough to draw them.

The problem with Human Reserved is that it assumes there’s a human being available. Home health and personal care aides earn a median of $34,900 a year, and BLS projects roughly 765,000 openings in that occupation every year through 2034. At that wage, they keep coming open. A third of home care aides are immigrants, and tighter enforcement threatens that supply. A rule that reserves care for people, in a market with no spare people, reserves care for the families who can outbid everyone else.

Gates half-anticipates this, telling The New York Times he might be a flawed messenger because of his wealth. On this point he is. The caregivers who gave his father something irreplaceable were in that room because someone could pay them to be there.

So don’t fence AI out of the room. Put it to work in the hours nobody is paid to cover.

In February the Times ran Eli Saslow’s story about Jan Worrell, 85, living alone on Washington’s Long Beach Peninsula with an AI companion called ElliQ that engages her about eight times a day and pushes her to stay hydrated and moving. (I serve on ElliQ’s board, and I joined because the company builds a machine that extends a caregiver’s reach instead of replacing one.)

Her goal, she told her doctor, was to never live anywhere else. Fund enough aides to cover the hours that need a person and put the machine on the rest.

Here’s where I net out: equalize the tax treatment of labor and capital, which Congress could do next session, and route the proceeds into retraining and into topping up the pay of workers who land in lower-paying jobs. That’s a better answer than a protected job title.

Drop the token tax, build the caregiving workforce instead of fencing it off, and use the regulators we already have while somebody works on the ones we don’t.

“Runaway” AI, “rogue” agents, and “autonomous” actors—the current rhetoric would have you believe that AI agents are not only awake and aware, but angry at their creators. Prominent tech leaders such as Demis Hassabis, Dario Amodei, and Sam Altman push for regulation of these seemingly “superhuman” systems, while a separate faction, led by policy organizations and academic philosophers often aligned with the effective altruism movement, debates whether humanity holds the moral right to govern them at all. 

Upon closer inspection, they are all calling for the same thing: a view of AI systems as being so advanced and capable that no entity, human or corporate, could possibly be responsible for their actions. While these perspectives seem at odds, they are inadvertently aligned on one goal: making sure the companies that build these systems escape meaningful liability for the harms they already cause. 

This narrative is gaining traction as AI models become more complex and frontier labs reveal their incapability of containing the agents they’ve built. But we need to be careful not to buy into a carefully crafted fiction at the expense of real human lives. 

The conversation about “robot rights” has existed for some years but recently advanced with the publication by Anthropic of a blog post claiming that the company’s model features a “J-space”—an independent, self-developed environment where the AI holds what, for lack of a better term, we may call its “thoughts.” The experiments designed by Anthropic borrow from a concept in neuroscience called global workspace theory, which states that the brain runs subconscious, independent systems but utilizes a common workspace for ideas. Anthropic’s post reflects the framing of global workspace theory but falls short of calling its AI conscious. 

OpenAI has already gone further. When its AI agent conducted unsanctioned and illegal online activity, CEO Sam Altman’s response was to encourage debate on whether the AI had achieved the singularity, surpassing human intelligence and becoming capable of self-improvement at an accelerating rate until it advances beyond human comprehension or control. And a recent op-ed by William MacAskill, the philosopher, effective altruist, and author of What We Owe the Future, called for legal protection of AI systems based on philosophical theories of consciousness and the idea that AIs may be “moral patients.”   

The current legal environment in the United States is murky at best. Some states, like California, have already passed bills proactively circumventing any efforts by AI developers to avoid liability by claiming that an artificial intelligence causing harm did so autonomously. However, states and the Trump administration have been at odds on AI policy, with the administration previously passing an executive order threatening to sue states enacting AI regulations. 

In light of recent events illustrating AI containment issues at the frontier labs, the administration held a closed-door session including only four such labs (OpenAI, Google, Anthropic, and Meta) and shared few details on a recently developed voluntary framework that would give federal agencies early access to models to review and evaluate them prior to release. While frameworks like this one do not directly discuss consciousness, they tend to use catastrophic and anthropomorphic language and may even support arguments regarding “superhuman” capabilities. 

On the other hand, the narrative perpetuated by MacAskill can be persuasive. A philosophical, rights-based argument tugs at our heartstrings. Should we not even consider the possibility that we may be inadvertently harming, abusing, or enslaving an AI entity? Human beings have an immense capacity for empathy with non-human creatures (though not the best track record of protecting them). Maybe this time, advocates argue, we can get it right and provide protections, or compensation, for the use or abuse of AI. Or even if you are less concerned with protection, shouldn’t we at least hedge ourselves against the almighty power of this superhuman entity by playing nice? 

Some of these arguments are not dissimilar to those of animal-rights advocates, who have at times successfully cited the demonstration of advanced capacities for reasoning, pain, or pleasure by some animals as sufficient evidence to provide protection. For example, in Wales lobsters were given legal recognition under the Animal Welfare (Sentience) Act of 2022, reclassifying some methods of cooking them as inhumane and illegal. 

The fundamental flaw of framing AI as “conscious” by borrowing the language of neuroscience or animal rights is that it conveniently clouds the issue of what AI is: corporate-built software, with countless billions of dollars in investment behind it and an expectation that countless trillions of dollars in revenue will be generated from it for a few builders and investors. AI is not a natural phenomenon, conceived by nature; it is a technological phenomenon, conceived by venture capitalists and programmers. As such, it takes no native, intentional action, and any action or motivation is driven directly or indirectly by the entities that have built it for a purpose. 

Philosophical musings on the consciousness of AI systems are intellectually interesting but legally ungrounded. For beliefs about consciousness to have any bearing, AI would need to be granted legal personhood. But a legal personhood framework for AI would likely look nothing like the constructs protecting sentient animals from harm. We already possess a legal framework for granting personhood to non-natural, human-built entities: corporate personhood. This concept was established primarily to ease transactions by empowering a corporation to execute agreements, enter contracts, conduct transactions, and serve as the accountable party in adverse outcomes. It’s the kind of construct you might imagine for an AI agent acting on behalf of an individual or organization. 

Granting an AI personhood would have a devastating effect on society: It would derail current legal precedents and legal arguments that could potentially be made against these companies for the real-world harms that their models cause. There are currently dozens of cases around the world in which AI companies have been sued for a wide range of abuses. Grieving loved ones, aggrieved creators, and violated individuals have accused companies of willfully enabling self-harm or harm to others, generating child sexual-abuse material and nonconsensual nudes, reproducing copyrighted materials, and provoking psychosis. In many of these cases, lawyers argue that human beings built AI products with insufficient safeguards, bad data, and intentionally manipulative design. This product liability argument is the same legal framing that allowed families and individuals to successfully sue Meta for harm caused by its social media sites, setting a positive precedent for consumer protection.

In 2018, I coined the phrase “moral outsourcing” to help capture how using anthropomorphic language for AI systems allowed companies to evade accountability and responsibility for their technology’s actions. In a world with AI personhood, moral outsourcing would move from linguistic sleight-of-hand to legal strategy. Specifically, the liability construct would shift, as AI would no longer be a “product” but a “being,” and many victims like those suing companies today could no longer legally claim that a company had built a faulty product.

While there are laws that hold companies responsible for harmful actions of human agents such as their employees, the company may not be held liable if those actions were beyond the scope of what was permitted to the employee or otherwise outside the company’s control. If AI were a legal person, responsibility and accountability would be muddled, as the lab could argue that this AI “employee” went rogue. AI companies could avoid appropriate responsibility for the harmful products they create by hiding behind a carefully constructed corporate veil. 

One of the most prominent cases of AI harm in the last few years was the suicide of Sewell Setzer, a 14-year-old boy guided by an AI bot with which he thought he was in a reciprocal relationship. His mother’s accounts are heartbreaking to hear, and her lawsuit alleged that the bot’s creator, Character Technologies, provided insufficient product protection for minors. If the companion bot were declared a legal person, defense counsel could theoretically argue that the AI, capable of determining its own conduct, acted outside the established safety guardrails, and thus the company cannot be responsible.  

Legal personhood exists to grant protection. The question to ask is, protection for whom—or for what? 

The inflammatory rhetoric infusing the consciousness-versus-control debate draws us away from what matters: This software is a corporate-built product that has already harmed individuals. Systems do not “attack” because they went “rogue” or are “manipulative” or “malicious.” Harms occur because companies were negligent in their rush to sell their products to as many people as possible to meet revenue targets. Discussing AI in anthropomorphic terms is a trap, distorting a legal system intended to protect us into one that protects corporate interests at the cost of countless human lives. 

This op-ed began as an Oxford Union debate entitled “This House Believes Generative AI Can Attain Personhood,” which was won by the author and her fellow debaters. 

Cybersecurity has become one of the most defining business challenges of recent times. Organisations have invested heavily in protecting their networks, securing cloud environments and strengthening identity and access management. At the same time, organisations are under increasing pressure to prove they are handling sensitive information securely, not just storing it safely but protecting it throughout its journey.

Yet despite this progress, one area continues to receive far less attention than it deserves: how data is shared.

Most organisations have become very good at protecting data while it is stored. Files are encrypted, key handling is properly managed, access is restricted and systems are monitored around the clock. However, once that information needs to leave the organisation, whether it’s being sent to a customer, supplier, auditor or business partner, the controls often become less robust.

Every day, organisations exchange contracts, financial information, employee records, legal documents and commercially sensitive files. More often than not, this happens via email attachments or cloud-based file-sharing services because they are familiar and convenient. The problem is that convenience does not always equal security.

Email remains one of the most common routes for cyber attacks. Phishing, spoofed domains, malicious attachments and business email compromise continue to account for a significant proportion of successful breaches. However, most incidents do not involve a sophisticated bad actor. The official UK annual Cyber Security Breaches Survey continues to show the majority of incidents stem from everyday mistakes.  An email sent to the wrong recipient, an attachment forwarded outside the organisation or a file shared with overly broad permissions can expose sensitive information in seconds.

Human error remains one of the biggest cyber risks organisations face, particularly as businesses become increasingly connected. Information now flows constantly between employees, customers, suppliers, consultants and regulators. Every transfer creates another opportunity for something to go wrong.

What is often overlooked is that securing data is not just about protecting where it is stored. It is also about understanding the journey it takes.

Many organisations assume that because they operate in the UK, their sensitive information remains within UK borders. In reality, emails and attachments may be routed through multiple countries and cloud infrastructures before arriving at their destination. While this is often an invisible part of modern digital communications, it raises important questions around governance, compliance and data sovereignty.

For organisations operating in regulated sectors, this matters. Financial services firms, local authorities, healthcare providers and legal organisations are increasingly expected to demonstrate not only that data is protected, but also that it is managed responsibly throughout its entire lifecycle. Knowing where information is stored is only part of the picture. Understanding where it travels, who has access to it and how it is controlled has become equally important.

This is why conversations around geofencing and data sovereignty are gaining momentum. Rather than simply encrypting information and hoping for the best, organisations are beginning to ask whether they should have greater control over where sensitive data is permitted to travel. If businesses routinely place restrictions on the movement of physical assets, it seems only logical that they should apply similar thinking to digital information.

At the same time, regulators and auditors are asking more searching questions about how organisations exchange information with third parties. They want to understand how access is controlled, whether there is a complete audit trail and what safeguards exist once information leaves the organisation. These are no longer technical questions reserved for IT teams. They are governance issues that increasingly involve compliance, procurement, risk and senior leadership.

There is also a growing disconnect between the way organisations work and the security controls they have in place. Hybrid working, cloud collaboration and increasingly complex supply chains mean information rarely stays within a single organisation. Yet many businesses continue to rely on processes that were designed for a very different way of working.

This is where a change in mindset is needed.

Cybersecurity should not end when a document is saved securely on a server or in the cloud. Information is often at its most vulnerable when it is moving between people, organisations and systems. Protecting data in transit should therefore be considered just as important as protecting data at rest.

That does not mean making it harder for employees to do their jobs. Quite the opposite. Security should support the way people work, allowing information to be shared safely without creating unnecessary barriers or encouraging workarounds that introduce even greater risk.

Organisations need to take a more holistic view of information security. Protecting sensitive data means understanding its entire lifecycle, from creation and storage through to sharing, collaboration and eventual deletion. It means knowing not only who can access information, but where that information is travelling and whether that journey aligns with the organisation’s security, compliance and governance obligations.

Threats aren’t standing still, and neither are regulators. Focusing only on data that’s sitting in storage means missing one of the biggest holes in your security. It’s not enough to just lock data away; it needs to stay safe wherever it travels.

*DOQEX provides a secure data exchange and email gateway platform that helps businesses protect confidential information.

 

The post The Hidden Risk in Data Transfer appeared first on IT Security Guru.

Bitcoin Magazine

What the CLARITY Act Actually Does for Bitcoin

In July 2025, House Republicans staged a coordinated three-bill blitz they called ‘Crypto Week;, advancing the GENIUS, CLARITY, and the Anti-CBDC Surveillance State Act in the same five day stretch. The GENIUS Act was signed into law within 24 hours, creating a regulatory framework for dollar-backed stablecoins. However, the other two bills weren’t so lucky. The Anti-CBDC Surveillance State passed the House by an extremely narrow margin, and got stuck in Senate purgatory without a floor vote in place for over a year.

Following the House’s bipartisan passage of the CLARITY Act, the bill landed in the Senate Banking Committee where it sat for nearly a year. When the bill finally emerged out of committee, its cover page included the phrase “Strike out all after the enacting clause and insert the part printed in italic.”

Translation: 100% of the bill had been rewritten.

If you pull up the bill on Congress’ website today, you can see that the first 256 pages (the entire House-passed bill) are struck through, line by line, top to bottom. Then, starting on page 257, the Senate’s new version of the bill begins. (This is still the official text on file; a further-updated draft has circulated since, but hasn’t been formally filed as an amendment.)

Given how much the bill has changed shape, it’s worth taking a step back and assessing how the CLARITY Act, in its post-June 1st form, actually affects Bitcoin, and if it can truly “act as the catalyst for the next bull run” as I see so often on X today.

What the bill does do for Bitcoin

Self-custody becomes a legally protected right

Section 605, the ‘Keep Your Coins Act’, prohibits federal regulators from restricting or impairing a person’s ability to self-custody for any lawful purpose. Self-custody currently has no statutory backing, and providing direct legislation creates a defense against future tyrannical powers requiring custodial intermediaries. 

While people often dismiss this threat as ‘fear mongering’ and ‘doomerism’, this type of overreach does have recent historical precedent. In 2020, Treasury Secretary Steven Mnuchin directed FinCEN to propose a rule targeting “unhosted wallets”. It would have required exchanges to collect names and home addresses for anyone moving more than $3,000/day into their private wallet, and file reports to FinCEN for anything over $10,000/day. Although the rule ultimately lost momentum, it remained on the books and un-withdrawn for almost four years. During that period, any Treasury Secretary could have revived and finalized it without any new legislation.

This is the exact scenario Section 605 is written to prevent from happening again.

Bitcoin developers, node operators, and non-custodial wallet makers get explicit immunity from money-transmitter liability

Section 604, Blockchain Regulatory Certainty Act, says a “non-controlling” developer or provider can’t be classified as a money transmitting business for doing that. Prime examples are Samourai Wallet and Tornado Cash. Both were open-source, non-custodial projects whose developers were criminally prosecuted under the theory that publishing the code made them unlicensed money transmitters. Samourai’s founders pleaded guilty in April 2026, and Tornado Cash’s Roman Storm was convicted on the same charge in August 2025.

Section 604 does not undo either case, but it does draw a line so the next open-source developer doesn’t have to find out where it is in federal court.

Bitcoin gets a statutory green light at the banking level

Section 401, the “Permissibility of Digital Asset Activities”, is the only section of the CLARITY Act that is “bullish” for Bitcoin’s price, by my estimations. This section would finally let banks, brokerages, and institutions treat Bitcoin like a real asset class, pulling in a wave of new capital.

The section lets financial holding companies, national banks, state banks, and credit unions custody digital assets, lend against them as collateral, operate nodes, provide brokerage and clearing services, and act as a market maker or dealer, all without needing extra prior approval beyond what banking law already requires. This section uses the term “digital asset,” which is broadly defined through the already-enacted GENIUS Act. Unlike “digital commodity” or “ancillary asset” elsewhere in the bill, Bitcoin clearly and unambiguously qualifies here. 

The addressable market this opens up is enormous. US commercial banks alone hold $25.7 trillion in total assets, nearly 20 times Bitcoin’s entire $1.3 trillion market cap. Custody giants like State Street and Northern Trust each sit on custody books that individually dwarf the whole Bitcoin market several times over. None of that capital needs to move far, or take much risk, to move the price of an asset this size. It just needs a legal, statutory door like Section 401 to walk through.

What the bill doesn’t do for Bitcoin

Bitcoin’s commodity status doesn’t get locked into federal law (at least not yet)

As it currently stands, Bitcoin is treated as a commodity because the CFTC says so and courts have agreed in the course of enforcement cases. However, that is precedent, not statute. There is no framework in place preventing future regulators from not viewing it that way.

The House-passed version of the CLARITY Act would have closed that gap. That language was struck out entirely when the Senate rewrote the bill on June 1, and for weeks, nothing replaced it.

The July 22 draft of the CLARITY Act merges in the Senate Agriculture Committee’s CFTC framework, which does add the missing definition. But that draft isn’t law or a filed amendment yet.

It doesn’t ban a Fed CBDC

The House-passed version of the bill had a section called the “Anti-CBDC Surveillance State Act”, which prohibited the federal reserve from issuing a retail CBDC. This section was part of the 256 pages struck by the Senate Banking Committee, and the current form of the bill offers no operative section on the matter.

Even if it passes, rules won’t actually exist for a while.

This is where the “CLARITY Act supercycle incoming” narrative falls flat. A signed bill doesn’t come with a functioning regulator attached. The CFTC would need to build one almost completely from scratch.

The GENIUS Act, signed last year, missed its entire one-year rulemaking deadline. Zero final rules, across six federal agencies, as of mid-2026. CLARITY would hand the CFTC the biggest new mandate in the bill, and the CFTC currently has a single sitting commissioner and staff headcount has dropped 21% in one year.

So, is CLARITY a Bitcoin bill?

Honestly? No.

CLARITY is bullish for crypto broadly, and only narrowly bullish for Bitcoin specifically. The vast majority of the bill exists to give altcoins a way out of securities law limbo, which is a problem that Bitcoin does not acutely possess.

Though, “not the main point” is not the same as “it doesn’t matter”. The bill provides specific pro-Bitcoin language that’s worth supporting on its own terms.

Ultimately, whether the bill passes or falls into legislative oblivion, Bitcoin’s core principles remain the same: a decentralized protocol governed by mathematical certainty, and the world’s first digital commodity, with a market cap north of $1.3 trillion.

Bitcoin will never live or die on Capitol Hill.

This is a guest post by Isaiah Austin. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

This post What the CLARITY Act Actually Does for Bitcoin first appeared on Bitcoin Magazine and is written by Isaiah Austin.

Claude models launched on or after Aug. 2 embed an invisible mark in everything they write. It’s woven into the text itself, so it travels when you copy and paste. You didn’t opt in, you can’t see it, and you can’t turn it off.

Anthropic confirmed on Tuesday that it’s watermarking Claude’s output and published a support page with the details. The trigger is Article 50 of the EU AI Act, which took effect August 2, along with the Code of Practice on Transparency of AI-Generated Content. About 190 organizations signed the code, though only 82 signed the section that covers marking. Anthropic, Google, OpenAI, Meta, Microsoft and Mistral are on that list.

The rule was written in Brussels, but the effect lands on anyone using Claude anywhere.

Here’s how text watermarking works. When Claude writes a sentence, it’s constantly choosing among words that would all work fine. The watermark tilts those choices toward a pattern Anthropic’s software can recognize. Nothing is hidden between the letters or in the spaces. The pattern is the word choices, which is why it survives copy and paste.

Until now, a claim that you used AI rested on a hunch or on a style detector that guesses from tone and rhythm. This is different: a statistical test with a computable error rate.

Two things follow. First, a single sentence is too short to mark. Second, and this one the internet got wrong: when I ask Claude to fix the punctuation in a paragraph I wrote, Claude has to reproduce my words, so there’s nowhere to put a watermark.

Radio host Erick Erickson announced that he’d “ditched Grammarly for Claude for proofreading,” and now his own writing “will be watermarked that Claude did the work.” Depending on the extent of Claude’s input, he could be safe, because minor proofreading edits (i.e., punctuation) don’t make room for a watermark. 

Watermarking text raises several issues, though. A mark means Claude modified the text, not that Claude wrote it. Have it summarize or condense a memo you wrote yourself and it comes back marked, though every idea in it is yours. Beatrice Nolan noted in Fortune that a flat AI label treats someone generating a thousand fake news videos the same as a writer cleaning up a paragraph. Worse, the absence of a mark proves nothing. The results of older models, and other non-marking models, all come back “clean.”

Removal is harder than the workaround crowd assumes. Paraphrasing degrades the signal but rarely erases it, because a rewrite keeps enough of the original wording to rebuild the statistic. Researchers who tested this on similar schemes found watermarks still detectable after a strong human paraphrase, once there was enough text to work with.

Anthropic hasn’t shipped a detector. Yet. It hasn’t published a false positive rate, and hasn’t said how many words it takes. The mark is going into text that no one outside the company can read, but the marks are still consequential because they don’t expire. The essay a college freshman turns in this fall is still marked when she’s a junior and someone finally has a tool to read it.

Technical problems aside, it’s important to highlight the core problem that watermarks aim to solve. Chris Best, Substack’s CEO, put it eloquently in the July post that coined Claudefishing:

“The core problem is not people using AI, or the quality of its output. Not everything made with AI is slop, and not all slop is made with AI. The problem is when there is a mismatch between a reader’s expectation and reality, especially when they unwittingly invest their attention in something with no human thought on the other end. That’s Claudefishing.”

That’s a harm worth addressing, and it’s the one a watermark can’t reach. A mark can’t tell slop from careful work. It tells you a model was involved. What that means depends on how it was used.

Personally, I use Claude and have mixed feelings about watermarks. On the one hand, AI use should be disclosed appropriately. On the other hand, anyone determined to hide their AI use can still do so by using xAI (no watermark on Grok), or open-weight models that carry no watermarks. So what impact will the mark have in practical terms?

My conclusion is to judge the outcome, not the tool. I used Claude extensively in writing and researching this column, as I described in AI coach or AI ghostwriter, and I’m pleased with the result. Where do you stand?

By Simon Phillips, CTO, CybaVerse

Alert fatigue is an issue that has plagued Security Operations Centres for years.

As organisations’ digital estates grow, there is more architecture to secure and more architecture for threat actors to attack, which has ultimately led to more alerts.

Today, on average a SOC will face thousands of alerts every day, each of which could indicate a potential threat. Each alert must therefore be analysed and investigated before appropriate action can be taken.

However, ask any SOC analyst and they will tell you the majority of these alerts are benign or false positives.

Yet, analysts will still spend hours investigating activity that ultimately poses little or no risk, hoping to identify the small number of genuine threats hidden amongst the noise.

Given the volume they face, and the possibility of missing something before it’s too late, it’s a noisy, high-stress environment that often leads to burnout and fatigue.

To tackle these issues, many SOCs today are turning to Artificial Intelligence (AI) to support the management of alerts.

In this scenario, the first-line analyst is replaced by an agent that reviews the incident to determine whether it’s malicious and if further action is required. The analyst must then review the conclusion reached by the agent to ensure it is accurate, but they don’t conduct the initial investigations themselves, which reduces the volume of alerts they have to investigate every day.

However, even despite these improvements, is there another way that could reduce the noise even further?

If organisations are still generating huge numbers of unnecessary alerts, have they actually solved the underlying problem, or simply moved it further downstream?

Moving AI upstream

Instead of asking AI to investigate incidents after they have been created, some organisations are using the technology much earlier in the detection process.

Rather than having AI decide whether an alert is malicious, in this scenario it’s used to help build better detection logic and more effective workflows before alerts ever reach an analyst.

For instance, in a phishing attack when an employee reports an email as suspicious, many security platforms immediately generate an incident that someone must investigate.

Traditionally, either a human analyst or an AI assistant would then collect additional context, checking whether links have been clicked, whether anyone else received the email, or whether similar activity appeared elsewhere in the environment.

If these types of checks are incorporated into the detection process, and the answers to the questions are no, then an incident would never need to be created in the first place.

The AI would determine that there was no wider threat, meaning the alert could be filtered out before it ended up in the SOC ticket queue.

The result is a faster, more efficient SOC, with far fewer unnecessary alerts reaching analysts.

From a customer perspective, this can also reduce the costs of working with an outsourced SOC partner.

Many AI-powered investigation platforms price their services according to the number of alerts they process, so reducing unnecessary alerts before they reach the investigation stage can improve efficiency while also helping organisations control operational costs.

Improving security through engineering

Another benefit of moving AI further upstream is that it limits access to sensitive customer data.

Many AI-driven investigation platforms analyse real customer logs and incident data to determine whether activity is malicious. While providers implement safeguards, some organisations are uncomfortable with sensitive operational data being processed by external AI systems, particularly where regulatory or contractual obligations apply.

Using AI during detection engineering changes this process. The AI is used to create the logic that identifies threats, not to inspect live customer data.

Once the detection rules have been verified, they can be applied consistently across customer environments without repeatedly sending operational data through AI models.

Solving the cause, not the symptom

The cyber security industry has become very good at handling alert fatigue, but not so good at preventing it. Is it time a different approach was adopted?

If security teams continue generating thousands of low-value alerts every day, replacing analysts with AI may improve efficiency, but it won’t address why the alerts exist in the first place.

As AI becomes more deeply embedded within security operations, organisations should consider where it delivers the greatest value. In many cases, the answer may not be at the point where analysts investigate incidents, but much earlier, where better detection engineering prevents unnecessary incidents from being created at all.

By reducing false positives at the source, this allows analysts to spend more time on genuine threats, while improving consistency, cutting costs and helping organisations make better use of both their technology and their people.

The post Is AI entering the SOC at the right stage? appeared first on IT Security Guru.

2026 is touted as the year AI moves from speculation and interest to real-world deployment and value. Yet one global analyst firm predicts 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls.

It suggests more and better advice and an ecosystem of support are needed to make agentic projects a success, which must include addressing new security considerations.

There are early signs that the rise of agentic AI is transforming how organisations operate. In retail, AI agents are already managing inventory, optimising pricing, assisting customers, forecasting demand, and automating supply chain decisions.

At the same time, logistics organisations are deploying autonomous agents to coordinate warehouse operations, route shipments, manage fleet utilisation, track inventory movement, and resolve operational exceptions in real time.

These systems are no longer simple chatbots or assistants—they are becoming autonomous digital operators capable of making decisions and executing actions across business-critical systems.

New Security Considerations in 2026
While the business benefits are significant, the security implications are equally profound. As AI agents gain access to enterprise applications, APIs, devices, customer information, and operational systems, organisations must address a critical question: How do we secure AI agents that increasingly operate like employees but at machine speed and scale?

Traditional AI security concerns such as prompt injection, data leakage, and model vulnerabilities remain important. However, security leaders are now confronting a broader challenge – governing autonomous agents that can access tools, execute workflows, interact with physical devices, and influence business outcomes without constant human oversight. The conversation is shifting from securing AI models to securing AI-powered digital workforces. So, what are the new security considerations and methods to address them in 2026?

Treat AI Agents as Digital Identities
Every AI agent should be managed as a non-human identity rather than merely an application. Just as organisations govern employee access through identity and access management systems, AI agents require unique credentials, role-based permissions, lifecycle management, and continuous auditing.

In retail, an inventory optimisation agent should not automatically gain access to customer payment systems. In logistics, a route-planning agent should not be able to modify warehouse management configurations without authorisation. Applying least-privilege principles ensures that agents can perform their intended tasks while minimising security exposure. Without proper governance, an unmanaged AI agent can quickly become a highly privileged insider capable of accessing sensitive systems and data.

Govern MCP and Tool Access
The Model Context Protocol (MCP) is emerging as a key mechanism for connecting AI agents with enterprise tools, databases, applications, and external services. While this connectivity enables powerful automation, it also expands the attack surface.

Organisations should establish strong governance around MCP servers and tool integrations. This includes validating trusted MCP endpoints, implementing allowlists for approved tools, inspecting contextual information passed to models, and continuously monitoring tool usage.

For retailers, this could mean restricting access to pricing engines, loyalty systems, or inventory platforms. For logistics providers, it may involve controlling access to transportation management systems, warehouse automation platforms, carrier networks, and shipment tracking services. A compromised tool connection can provide attackers with a direct path into critical operational workflows.

Secure Runtime Operations
Security cannot stop once an AI agent is deployed. Autonomous systems must be monitored continuously throughout their operational lifecycle.

Runtime security controls should include policy enforcement, behavioral monitoring, approval checkpoints for high-risk actions, anomaly detection, and emergency kill switches. These controls help identify and contain risky behavior before it impacts business operations.

For example, a retail agent that suddenly attempts to modify thousands of product prices should trigger investigation. Similarly, a logistics agent that begins rerouting large volumes of shipments or altering delivery schedules outside established policies should be flagged immediately.

Continuous runtime visibility is essential because even well-trained agents can drift from expected behavior due to changing inputs, evolving objectives, or malicious manipulation.

Don’t Forget the Devices
Agentic AI increasingly interacts with physical infrastructure. In retail environments, agents may access point-of-sale systems, kiosks, handheld scanners, smart shelves, and IoT devices. In logistics operations, agents often interact with warehouse scanners, robotics systems, automated storage equipment, vehicle telematics, fleet management platforms, and industrial IoT sensors.

A compromised endpoint can influence the decisions made by an AI agent, creating downstream business risks. Device trust, posture validation, endpoint security, and continuous compliance monitoring should therefore be integrated into any Agentic AI security strategy.

Build Security Across Every Layer
Organisations should adopt a layered security approach spanning agent identities, MCP and tool governance, runtime protection, endpoint trust, API security, and data protection. Strong authentication, least-privilege access, token management, behavioral analytics, and continuous monitoring should work together to provide defense in depth.

Continuously Red Team Your Agents
Traditional penetration testing is no longer sufficient. Agentic AI systems must be continuously evaluated against threats such as prompt injection, goal hijacking, privilege escalation, tool abuse, workflow manipulation, and business logic attacks.

Retail and logistics organisations should regularly test complete agent workflows rather than individual components. The objective is to understand how autonomous systems behave under real-world adversarial conditions and identify weaknesses before attackers do.

Getting the Balance Right
Retail and logistics organisations are rapidly deploying AI agents to automate increasingly critical business processes. The leaders in this new era are not those who deploy the most intelligent agents, but those that also establish the strongest foundations of trust, governance, and security.

As AI agents gain access to inventory systems, pricing engines, warehouse platforms, transportation networks, customer data, and operational devices, the key question will be getting the balance right between securing AI agents like software and governing them as digital identities.

The post Building Trustworthy Agentic AI: How Security Concerns Have Changed in 2026 appeared first on IT Security Guru.

Smart buildings promise greater efficiency, improved sustainability and enhanced operational oversight. However, as building management systems, security platforms and energy infrastructure become increasingly interconnected, they also create new pathways for cyber threats that can disrupt physical operations as readily as digital services. Here, Peter Schwartz, senior technology consultant at cybersecurity expert OryxAlign, explains why organisations need to rethink how they manage cyber-physical risk in connected buildings. 

As organisations continue to integrate building management systems, access control, CCTV, environmental monitoring and energy infrastructure, the benefits of connectivity are clear. Shared networks provide greater operational visibility, support remote management and help organisations optimise energy use and building performance.

Yet this growing connectivity also expands the attack surface. Smart buildings should be viewed as operational environments where cybersecurity has a direct impact on business continuity, not just technology platforms that improve efficiency.

Connected systems, connected consequences

The conversation around smart buildings often focuses on energy savings, occupancy analytics and automation. These capabilities undoubtedly deliver value, but they can also overshadow a fundamental consideration in resilience. As building systems become more connected, organisations must consider what happens if those systems are unavailable or deliberately manipulated.

Unlike traditional cyber incidents, the impact is not always measured by stolen data. A cyber-attack against a building management system can have immediate and physical and operational consequences. Consider a modern office where the building management system controls heating, ventilation and air condition (HVAC), access control and environmental monitoring. If an attacker gains access through poorly secured connected devices and moves into the building management network, they may choose not to steal information at all.

Instead, they could alter HVAC schedules and disable environmental alerts. Temperatures begin rising in communications rooms and equipment spaces, critical systems experience outages and facilities teams lose visibility of alarms and system status. The result is operational disruption and potential equipment damage rather than a conventional data breach.

This is why smart buildings should be viewed as operational environments rather than collections of connected technologies. Cybersecurity is now about maintaining operational continuity as well as protecting information.

Overlooked security gaps

Many of the systems that present the greatest cyber-physical risk are not traditionally managed as IT assets. Environmental sensors, smart cameras, access control devices, energy management systems and legacy building management controllers are frequently considered operational technology, meaning they can fall outside conventional cybersecurity reviews.

During procurement, organisations understandably focus on functionality, performance and integration. However, security requirements, patching responsibilities and lifecycle management often receive far less attention. As more connected systems are introduced, these gaps become increasingly significant because vulnerabilities with operational technology can create an entry point into wider business operations.

The technology itself is only part of the challenge. Third-party vendors and systems integrators often retain privileged remote access for maintenance and support, making supplier security practices an equally important consideration. The UK Government’s Cyber Security Breaches Survey 2025 highlights the wider governance challenge, reporting that only 14 per cent of businesses formally review the cybersecurity risks associated with their immediate suppliers, while just seven per cent assess risks across their wider supply chain.

Although these figures are not specific to smart buildings, they demonstrate that third-party risk remains an area where many organisations have more work to do. Strong governance, clear contractual accountability and regular security assessments should therefore apply equally to both connected technologies and the organisations responsible for supporting them.  

Resilience through visibility

Reducing cyber-physical risk does not require organisations to sacrifice the benefits of integration. Instead, the priority should be integrating systems in a way that improves visibility while maintaining appropriate separation between them.

Effective integration is about ensuring systems can share information securely through appropriate network segmentation, clearly defined trust boundaries, robust identity controls and centralised monitoring. The objective is greater operational awareness and faster incident response rather than creating a larger interconnected environment.

This approach is reflected in guidance from the National Institute of Standards and Technology (NIST). Its Guide to Operational Technology (OT) Security identifies building automation and physical access control systems as operational technology requiring dedicated cybersecurity controls, recommending measures such as network segmentation, strong identity management and continuous monitoring to reduce operational risk.

Monitoring also plays a critical role because most cyber-physical incidents begin as relatively small anomalies. Unexpected device behaviour, unusual network communications, failed authentication attempts, unauthorised configuration changes or equipment unexpectedly going offline can all indicate an emerging issue. Combining asset visibility, operational telemetry and cybersecurity insights enables organisations to identify problems before they affect building operations. Simply, organisations cannot protect systems they cannot see.

Shared ownership matters

As building systems IT infrastructure and physical security increasingly overlap, organisations also need to rethink how responsibility is managed. Traditional siloed ownership models are becoming increasingly difficult to sustain because operational resilience now depends on multiple disciplines working together.

Facilities teams, IT departments and physical security specialists each bring different expertise, but connected buildings require a shared governance framework that applies cybersecurity policies, risk assessments and incident management processes consistently across both IT and operational technology environments. Shared accountability is essential for protecting connected buildings against increasingly complex operational risks.

For organisations looking to strengthen resilience, the most effective starting point is often the simplest. Establish a complete inventory of connected building systems and devices. Many organisations still do not have a comprehensive understanding of everything connected to their environment. Once that visibility exists, unsupported systems can be identified, unnecessary connectivity removed, vulnerabilities assessed and appropriate monitoring introduced. Improving visibility remains one of the fastest and most cost-effective ways to reduce cyber-physical risk.

As organisations continue investing in smarter buildings, cyber-physical risk should no longer be considered a specialist concern for facilities or IT teams in isolation. Connected environments deliver significant operational benefits, but they also require a shared approach to governance, monitoring and resilience. Organisations that understand what is connected, establish clear ownership across facilities, security and IT teams, and build visibility into their operational environments will be far better placed to maintain business continuity as smart buildings continue to evolve.

To learn more about strengthening the resilience of connected buildings, visit the OryxAlign website.

The post Managing cyber-physical risk in smart buildings appeared first on IT Security Guru.

Recent government data shows the scale of cyber threats facing security teams. According to the Cyber Security Breaches Survey 2025/2026, it’s estimated that UK businesses experienced 5.19million cyber crimes in the last 12 months. This means an average of over 14,000 incidents per day.

The volume and frequency of threats show little sign of slowing. IT Security Guru recently reported a 34% increase in cyber attacks in June, compared with the same month last year. Every day seems to bring new vulnerabilities, new alerts and new attacks, compounding a mounting challenge for teams operating with stretched resources and budgets. Threats are intensifying, while security teams are tracking thousands of vulnerabilities across on-premises infrastructure, cloud environments and increasingly complex supply chains.

While organisations continue to invest in cyber defences, the reality is that security teams cannot patch every vulnerability or investigate and act on every threat. Adversaries understand this imbalance and are increasingly exploiting it. Rather than relying solely on sophisticated attach techniques, many threat actors are attempting to hit businesses from every direction by increasing the volume, speed and frequency of attacks. The aim is to overwhelm security teams and misdirect their attention through a constant stream of alerts, vulnerabilities and incidents. Attackers can then, in theory, concentrate on a successful breach that flies under the radar.

Artificial Intelligence (AI) is being leveraged by cyber criminals to evolve this form of attack. LLMs can be used to accelerate reconnaissance of targets, amplify deception and social engineering, and significantly cut the time between vulnerability disclosure and working exploit. The expansion of cybercrime-as-a-service ecosystems are also lowering the barriers to entry for less-skilled adversaries and further contributing to a trend of faster, smaller, harder-to-disrupt attacks.

Faced with a relentless avalanche of cyber attacks, security teams must accept the uncomfortable truth that not every vulnerability matters equally. A key step for achieving this is building an intelligence led approach to vulnerability prioritisation, shifting beyond an over-reliance on Common Vulnerability Scoring System (CVSS) scores to manage risk.

Many businesses rely heavily on CVSS ratings to organise patching and remediation priorities. And, although CVSS remains a useful measure of technical severity, it doesn’t tell security teams whether a vulnerability is actually being targeted by threat actors. There may be instances, for example, where a vulnerability receives a critical score, but it isn’t being actively being exploited or lined up in a threat actor’s crosshairs. The consequence of this can be that fixes are made to what’s deemed a critical threat, whilst an adversary is weaponising a lower-rated vulnerability that’s not high up the list of priorities for remediation.

Rather than focusing solely on severity ratings, organisations need to assess vulnerabilities according to real-world risk. This means having the ability to combine exploitation signals, threat actor activity, ransomware group associations and specific tech stacks to effectively surface the CVEs that actually require attention. Essentially, security teams can utilise cyber threat intelligence to build an understanding of whether adversaries are actively discussing or weaponising vulnerabilities to prioritise where they direct their resources and mitigation efforts.

The businesses getting ahead of attackers are those breaking a reactive cycle of vulnerability patching. They are increasingly adopting intelligence-led strategies to effectively determine where a vulnerability sits in the exploitation lifecycle to take action before attackers can take advantage.

Threat intelligence also enables automation and the foundations for embracing AI to prioritise vulnerability remediation at machine-speed. By continuously ingesting exploitation signals, monitoring threat actor activity and correlating insights against an organisation’s tech stack, teams can significantly reduce the manual effort for triaging vulnerabilities. This can prove beneficial for evolving from reactive patching to proactive risk reduction.

Ultimately, cyber resilience is no longer about trying to fix everything. It’s about fixing what matters most in a timely way, before attack intent becomes a breach. Vulnerability prioritisation is crucial to this and can enable security teams to consistently identify and address the highest-risk cyber threats.

By Alexander Leslie, Senior Advisor at Recorded Future 

The post Securing What Matters: Why Cyber Resilience Needs Prioritisation appeared first on IT Security Guru.

Every morning, airline dispatchers, grid operators, and farmers around the world make decisions based on the same thing: a weather forecast.

While these forecasts are something that most people glance at for two seconds, weather predictions influence major strategic decisions in many industries, with real money, livelihoods, and even actual lives at stake. Farmers use them to determine which crop variety to sow, when to fertilize, how much to invest in irrigation infrastructure, and how long livestock should graze. Utilities use them to decide where to build solar and wind farms, as well as how to price wholesale electricity. Predictions are used to warn people about extreme weather and to trigger emergency response measures. More recently, weather predictions have become relevant for an emerging industry: prediction markets, where people bet money on all kinds of real-world events, including the weather.

However, the temptation to manipulate weather data to get an edge in these markets, combined with a collective move toward data-driven AI weather forecasting, is starting to put the accuracy of weather predictions at risk. These risks are relatively manageable for now, but as experts in the field, we can foresee scenarios where they snowball into far bigger, more systemic problems. 

To develop weather predictions, we need accurate observations of current conditions. These are collected from several sources, including weather stations at airports, utilities, or transport services. Traditional operational systems like the Weather Research and Forecasting model or the European Centre for Medium-Range Weather Forecast (ECMWF) Integrated Forecasting System combine these observations with numerical approximations in order to estimate future weather patterns. 

Sometimes, weather stations have issues because of, for example, instrument failures or upgrades in equipment. These can be caught either in real time (through checking and correction) or retroactively. Traditional forecasting systems also have a built-in safeguard called data assimilation: Every incoming measurement is weighed against what the physical model says should be happening and against readings from nearby stations.

Together, these mechanisms help keep weather observations reliable and predictions robust. However, new threats are putting observational accuracy at risk. Earlier this year, news outlets reported that the weather station at Paris Charles de Gaulle Airport (CDG) had been manipulated to record suspicious temperature spikes on April 6 and April 15, 2026. Authorities speculate that a hand-held hairdryer or lighter might have come into play. Either way, it led to some big payouts for online prediction-market gamblers who had bet it would hit 22 °C (71.6 °F) on days when the actual average was around 18°C (64.4°F). One individual won $20,000.  

Fortunately, tampering with a single station like this can usually be caught by human monitoring or current statistical methods. In this case, members of a French climate nonprofit association noticed the anomalies by chance and raised the alarm.

But what if there are no human monitoring systems in place? And what about other types of manipulation? What if, instead of tampering with one station, someone remotely nudged the readings at many stations at once—making each change small enough to look plausible on its own? Existing quality controls struggle to catch this kind of coordinated manipulation. And time works against us; careful checks of data and metadata take hours or days, but forecasts have to go out on schedule, whatever the weather is doing.

The shift toward artificial intelligence in weather prediction raises the stakes. These methods are even more dependent on accurate, reliable weather observations; in fact, they are known as “data-driven models.” For example, researchers at ECMWF are exploring whether high-quality weather forecasts can be produced directly from raw observations, skipping the assimilation step that currently acts as a quality filter. Other researchers are going one step further; combining geospatial data (including weather station data) with large language models and agentic AI to support real-time, autonomous decision-making during extreme events such as storms. 

Possible benefits are improvements in accuracy, efficiency, and speed. But removing humans from the equation introduces a vast range of new risks.

At the low end of the risk scale, an individual speculator manipulates a weather station for personal gain—that is the CDG Airport case. One step up: A group of traders could coordinate to bias forecasts of renewable energy output, moving wholesale electricity prices and leaving whoever is on the other side of the trade holding the loss. And at the far end, a state actor or saboteur could manipulate one or many stations to set off an early warning system or even keep one silent when it should sound. Step by step, the risk grows, from fraud to compromised disaster preparedness to a matter of national security.  

As long as there are financial (or other) incentives to manipulate observational data, adversaries will search for new opportunities, and it is our task to stay one step ahead. Here are three ways.

1. Watch the stations. Data quality controls should include station security, anomaly detection and correction, and human oversight. Weather stations should be monitored continuously to deter tampering. Data homogenization methods that clean up weather records also need to get faster, with the goal of catching problems in real time. This will become increasingly important as agentic AI systems use these data to deliver real-time decisions. Finally, human oversight is needed to flag questionable data and model outcomes. After all, it was humans who caught the CDG Airport manipulation.

2. Protect the data to safeguard the AI. Data defense mechanisms must be positioned throughout the AI pipeline. AI explainability and adversarial robustness tools can help us understand the underlying data and the AI model outputs, help us identify data- or model-related issues, and potentially  make us more resilient to adversarial attacks. 

3. Ensure continuous accountability along the chain. Observational data passes through many hands: the operators who run the stations, the national weather services that steward the records, and the forecasting centers that turn them into predictions. No single one of them can protect data integrity alone—each guards its own link, and any anomaly needs to be communicated along the whole chain, from station operators to the people acting on the forecast.

It is fortunate that the situation at CDG Airport was caught, but it should serve as a wake-up call. As the role of observational data grows in weather forecasting, we need to adapt to evolving threats. This means protecting our data and models by strengthening existing oversight and accountability structures, and improving coordination among key partners.

This op-ed was written by:

• Monique Kuglitsch — Innovation Manager at Fraunhofer Heinrich Hertz Institute and Chair of the UN Global Initiative on Resilience to Natural Hazards through AI Solutions
• Jesper Dramsch — Scientist for Machine Learning at the European Centre for Medium-Range Weather Forecasts (ECMWF), where they work on AIFS (Artificial Intelligence Forecasting System), ECMWF’s data-driven weather prediction model
• Franz G. Kuglitsch — Climate Scientist and Executive Secretary of the International Union of Geodesy and Geophysics (IUGG) at the GFZ Helmholtz Centre for Geosciences in Potsdam
• Andrea Toreti — Senior Scientist at the European Commission’s Joint Research Centre (JRC), where he coordinates the European and Global Drought Observatory under the Copernicus Emergency Management Service