I spent three days at GISEC Global 2026 in Dubai looking at cybersecurity products, speaking with vendors and trying to understand where the market is actually moving.
After a while, one thing became difficult to ignore.
Different stands. Different products. Different cybersecurity problems.
Very similar vocabulary.
AI-powered. Agentic. Autonomous. Zero Trust. Sovereign. Quantum-safe.
This is not necessarily a criticism. Most of these themes represent genuine changes in how security architectures are being designed. But when hundreds of companies begin using the same terminology, the terminology itself stops being particularly useful.
You have to look underneath it.
That, more than any individual product announcement, was probably my main takeaway from GISEC Global 2026.
The 15th edition of GISEC ran from 16–18 September at Dubai Exhibition Centre, Expo City Dubai, under the theme Cyber First: The New Digital Order. Post-event reporting put the scale at more than 750 cybersecurity brands, around 350 speakers and visitors from more than 130 countries.
There was plenty to see.
The more interesting question was what all of it actually meant.
AI was everywhere. That made the word less useful.
It would be difficult to discuss GISEC 2026 without starting with AI.
But simply saying that “AI dominated the event” misses the more important development.
The market is splitting into two distinct conversations.
The first is AI for Security.
This is the side most security teams already recognise: detection, correlation, investigation, threat intelligence enrichment, alert triage and increasingly automated response.
The SOC workflow being presented is gradually moving away from:
collect telemetry → generate alert → send to analyst
towards something closer to:
collect → contextualise → correlate → investigate → decide → act
GISEC’s programme reflected that direction through discussions around agentic SOC architectures and movement from alerts towards autonomy. Vendors were also showing systems designed to complete larger parts of an investigation before an analyst becomes involved.
That does not mean the autonomous SOC has arrived.
I would be cautious with that claim.
What looks much more realistic today is bounded autonomy: AI systems performing enrichment, correlation and investigation, and perhaps executing certain pre-authorised actions, while governance and human accountability remain part of the architecture.
That distinction matters.
The second conversation is potentially even more important: Security for AI.
Once companies start connecting employees, applications and autonomous agents to LLMs, AI itself becomes infrastructure that requires security controls.
Now the questions include shadow AI, sensitive data leakage, model access, prompt injection, RAG security, agent identity, tool permissions and MCP access.
Products from companies such as LangProtect, ThreatLens and DeepintShield illustrated how quickly this security layer is developing. Some focus on controlling enterprise AI usage and data. Others go further into runtime controls, agent permissions or the actions an AI system is allowed to execute.
This changes how I think an AI security product should be evaluated.
“Does it use AI?” is almost the least interesting question now.
I would rather ask:
What can the AI actually see?
What context does it have?
What is it allowed to decide?
What can it execute?
And what prevents it from doing the wrong thing?
By GISEC 2026, “AI-powered” had become too common to tell me very much about a product. The architecture underneath the claim was far more interesting.
AI agents are quietly turning security back into an identity problem
There was another detail hidden inside the agentic-AI discussion.
An AI agent capable of querying systems, accessing enterprise data or invoking tools is not simply another chatbot.
It is an actor.
And actors need identities, permissions and boundaries.
That brings some very familiar security principles straight back into the discussion: least privilege, authorisation, separation of duties, auditability and traceability.
The “user” performing an action increasingly may not be a person sitting at a keyboard.
It might be a workload.
A service.
Or an AI agent.
GISEC provided several signals in that direction. Identity controls were visible in privileged-access discussions, Dubai’s government security-posture initiative and conversations around AI agents as non-human identities.
The technology may be new.
The requirement to know who or what is allowed to do what is not.
Cybersecurity looked increasingly like infrastructure policy
One of the things I found more significant than another AI feature was how prominently critical infrastructure appeared in the conversation.
Energy. Telecommunications. Power. Government. Nuclear environments. Industrial systems.
GISEC had a dedicated Critical Infrastructure Stage, and the discussion was noticeably wider than traditional enterprise security.
That difference matters because securing an industrial environment is not the same as protecting a normal IT estate.
You cannot always patch quickly.
You cannot assume an agent can be installed everywhere.
Legacy systems may stay in production for years.
Availability and safety may matter more than almost anything else.
In that environment, cybersecurity stops being primarily about protecting laptops and servers.
It becomes part of operational resilience.
For critical infrastructure, a cyber incident can affect production, transportation, communications, utilities or essential public services.
That is why I think the broader framing at GISEC was important.
Cybersecurity is increasingly being treated not simply as an IT function, but as part of the infrastructure on which organisations, economies and governments depend.
“Sovereign” means more than putting a server in the country
Cyber sovereignty was another term that appeared frequently.
Like AI, it risks becoming meaningless if it is used without explaining the architecture underneath it.
A locally hosted product is not automatically a sovereign architecture.
The more useful questions are harder.
Who controls the data?
Who controls the encryption keys?
Who has administrative access?
Where does telemetry leave the environment?
Which external dependencies are required?
Who can investigate and respond if something fails?
Can the organisation continue operating if a provider, jurisdiction or external service becomes unavailable?
The UAE’s cybersecurity initiatives around national policy, government security posture, critical infrastructure and encryption made the sovereignty discussion particularly relevant at GISEC. One concrete example was the DESC and Microsoft initiative designed to provide a continuously updated security-posture view across Dubai government entities.
That is much more tangible than putting the word “sovereign” on a booth.
Sovereignty starts becoming technically useful when you can identify and control your dependencies.
Quantum security was surprisingly practical
Quantum cybersecurity can easily disappear into futuristic presentations.
GISEC took parts of the conversation somewhere more useful.
The Global Quantum Drill focused on practical post-quantum scenarios, while the announcement of Global Quantum X for 2027 showed that cryptographic transition is moving further into mainstream cybersecurity planning.
The practical lesson is not to rush out and buy something labelled “quantum-safe”.
It is far less glamorous.
Find your cryptography.
Which algorithms are being used?
Which applications rely on them?
Which certificates, services, appliances and protocols contain quantum-vulnerable public-key cryptography?
How long does the protected information need to remain confidential?
What does each vendor’s migration roadmap look like?
NIST’s post-quantum guidance points in the same direction: organisations should already be identifying vulnerable cryptography and planning how it will eventually be replaced.
So one of my unexpectedly practical GISEC takeaways was this:
Before discussing quantum products, build a cryptographic inventory.
There is a lot of engineering work between those two points.
Threat intelligence becomes useful when it meets exposure
Threat intelligence was obviously present, but the approaches I found more interesting were the ones trying to answer a difficult operational question:
Does this threat actually matter to us?
A feed containing thousands of indicators is not automatically useful intelligence.
The value increases when intelligence is combined with external exposure, identity context, vulnerability state and business importance.
Companies including Censys, CloudSEK and ThreatLens represented different parts of this direction at GISEC, linking internet visibility, attack-surface information, threat intelligence and security operations.
The distinction may sound small, but operationally it is huge.
Security teams rarely suffer from a shortage of data.
They suffer from difficulty deciding which part deserves attention first.
The startup conversations were often where things became interesting
Large cybersecurity vendors naturally have a major presence at an event like GISEC.
But I also spent a significant amount of time looking at younger companies and more specialised technologies.
That is often where product discovery becomes useful.
Not because every startup will become the next major cybersecurity platform. Most will not.
What interests me is when a company takes a narrow operational problem and approaches it differently.
Across the conversations I had at GISEC, I encountered technologies around automated threat modelling, AI security, agent controls, identity and session security, exposure intelligence, SAP security, privileged access and other specialised areas.
The research around GISEC North Star points in the same direction: innovation was particularly visible around AI security, governance, exposure/context and security automation.
There is a commercial contradiction here, though.
Startups are solving increasingly specific security problems at exactly the same time that enterprise customers are trying to reduce operational complexity.
Both trends are real.
And eventually they collide.
Cybersecurity has a tool problem as well as a threat problem
Walking through an exhibition containing hundreds of cybersecurity products produces a strange thought.
How many more products can an enterprise security team realistically operate?
EDR.
SIEM.
SOAR.
IAM.
PAM.
Vulnerability management.
NDR.
Email security.
Cloud security.
Application security.
Threat intelligence.
Exposure management.
DSPM.
CNAPP.
ITDR.
And now another generation of AI security products.
Many of these technologies solve legitimate problems. Some new attack surfaces genuinely require new controls.
But operational complexity is also real.
Recent industry research referenced in the GISEC dossier shows that organisations still struggle to understand the capabilities already present in their security stacks, while large enterprises can operate dozens of tools across many different vendors. At the same time, other research indicates that many organisations still expect to add more security vendors rather than simply consolidate.
That is why I do not think the answer is simply “buy fewer tools”.
The better question is:
How many independent consoles, data models, policies, workflows and investigation contexts does your team have to operate?
Twenty well-integrated technologies may create less operational friction than eight completely isolated ones.
The issue is not the logo count.
It is fragmentation.
This is also where my monitoring and observability background shapes how I look at cybersecurity architecture.
Infrastructure, networks, applications, cloud platforms and security systems often see different pieces of the same problem.
Security becomes more effective when those pieces of context can be connected.
Visibility alone is not enough.
Context is what turns visibility into a decision.
So, what actually happened at GISEC Global 2026?
Plenty happened.
New products were launched. Partnerships were announced. Governments discussed cyber resilience. AI security expanded in almost every direction. OT received serious attention. Quantum migration became more practical. New startups appeared around problems that barely existed as standalone categories a few years ago.
But those individual announcements are not what I will remember most.
What stood out to me was the tension underneath them.
Cybersecurity keeps creating increasingly specialised technologies because the attack surface keeps changing.
At the same time, customers need those technologies to behave less like isolated products and more like parts of a coherent architecture.
AI makes that tension even clearer.
It promises to reduce operational burden, while creating new applications, identities, agents, data flows and security controls that also have to be managed.
The same can be said for quantum migration, cloud security, OT, identity and sovereignty.
Every new capability solves something.
Every new capability also becomes another architectural dependency.
That changes the questions I want to ask when looking at a new cybersecurity technology.
Not:
Does it have AI?
Not:
How many detections does it provide?
Not even:
How many features does the platform have?
I want to know what it sees that I cannot already see.
What context it adds.
What decision becomes better because it exists.
What it can automate safely.
How it integrates with the architecture already in place.
What operational burden it introduces.
And, ultimately, which security problem becomes measurably smaller after deployment.
If a product cannot answer those questions clearly, adding another dashboard is probably not innovation.
After three days at GISEC Global 2026, that was the point I kept coming back to.
When every vendor starts using the same words, stop comparing the words.
Start comparing the architecture.