Sudo Thalaivar: A Rare Off-Topic Post: JAILER 2 FEVER

My blog runs on a strict policy: Tech only. But every 4-5 years, one exception gets pushed through with root privileges, and its name is Rajinikanth. No firewall rule can block it. Jailer 2 has triggered the exception again, so here are a few posters I made while the fever lasts.

The Thucydides Trap Has a New Battlefield

When Silicon Becomes the New Sparta

In 431 BCE, Thucydides diagnosed why Athens and Sparta went to war: not tribute disputes, not border skirmishes, but something colder ; the growth of Athenian power, and the fear this caused in Sparta. Fear of displacement, not the disputes themselves, pulled two rational powers into a war neither wanted.

Today the battlefield isn't a peninsula. It's a fab in Taiwan, a GPU cluster in Virginia, a model weights file that took $100 million to train.

The Original Trap

Graham Allison went looking for that ancient pattern across history. He studied 16 cases of a rising power challenging a ruling one, going back 500 years. Twelve ended in war.

The mechanism isn't really about malice. It's about the ruling power reading the rising power's normal ambitions as threats, and the rising power reading the ruling power's normal caution as containment. Both sides act rationally, and the spiral tightens anyway. Allison's point was never that war is fated ; it's that the structure makes war the path of least resistance, unless someone deliberately builds a different path.

 Why the Battlefield Moved to Silicon

Historically this trap played out over territory, trade routes, naval power. Today, a lot of that same structural power is encoded in technology.

A lead in semiconductors or foundation models isn't prestige ; it's the ability to see farther, strike more precisely, and grow faster than your rival. Tech dominance isn't a symptom of national power anymore. It is national power.

That makes this iteration more dangerous than past ones, not less. There's no clean line between "commercial breakthrough" and "military asset." Every advance is dual-use, which means every advance is threatening, no matter how it's framed.

 

The Spiral in Action

So the moves start looking familiar, just in new clothes:

• Export controls on advanced chips ; read in Washington as security, read in Beijing as containment.
• Massive state investment in domestic chip capacity ; read in Beijing as self-sufficiency, read in Washington as a race for leverage.
• Talent restrictions, entity lists, investment screening ; each one a rational response to the other side's rational response.

This is the security dilemma at machine speed. Sparta had years to watch Athens build walls. We get a headline every week: a new model release, an export rule, a chip embargo ;each one a data point in a mutual anxiety spiral that never lets either side sit still long enough to ask whether the anxiety is justified.

 

Script or Choice?

The US and China have things Athens and Sparta didn't: nuclear deterrence, trillion-dollar interdependence, institutions built explicitly to manage this exact kind of friction. Those are real off-ramps. But off-ramps only work if someone chooses to take them.

The uncomfortable question underneath all of this: are we managing a technology competition, or are we running one of history's oldest scripts with better graphics?

Why Reverse-Engineering an EUV Lithography Machine Is Nowhere Near as Simple as It Sounds?

If a state actor or competitor somehow got their hands on a complete ASML EUV scanner tomorrow, how long before they could build their own? The honest answer, based on how these systems actually come together is a lot longer than most people assume and possibly never, if the goal is matching ASML's actual production performance.

Here's why.

1.     The Machine Isn't the Technology but The Integration Is

An EUV scanner isn't one invention. It's thousands of extraordinarily precise subsystems   light source, mirrors, vacuum chambers, wafer stages, metrology, vibration isolation, contamination control, computational correction all operating in concert at nanometer tolerances.

You can take the whole thing apart and catalog every component. What you can't easily extract is how those components were designed, manufactured, measured, and tuned to work together at commercial yield. Knowing a mirror's curvature is one thing. Knowing why that curvature was chosen, what got rejected along the way, and how it was aligned to sub-nanometer precision inside a working system is a different problem entirely.

2.     Tacit Knowledge Is the Real Moat

Patents and blueprints are the easy part   they're often public. What isn't public is the accumulated experience behind them: failed prototypes, supplier learning curves, manufacturing tweaks, and thousands of small engineering decisions made over two decades.

A reverse engineer can measure a mirror's coating and composition. They can't measure why that specific design won out over alternatives, what defects showed up during early production runs, or how yield was incrementally improved. That knowledge lives inside the organization and its supplier network   it was never written down in a form that transfers.

3.     Precision Manufacturing Doesn't Copy-Paste

EUV lithography runs at tolerances where tiny errors are catastrophic. Mirror surface accuracy, stage movement, thermal stability, vibration control, contamination management   all have to hold simultaneously at nanometer scale.

You can copy a design perfectly and still fail to manufacture it reliably. A slightly imperfect polish, a marginal vibration issue, a small alignment drift   any of these can tank throughput or make the machine effectively unusable, even though it "looks" identical to the original on paper.

4.     The Light Source Alone Is a Decade-Long Problem

Worth calling out on its own: generating usable EUV light means hitting microscopic tin droplets with a laser twice   once to shape them, once to vaporize them into plasma   at tens of thousands of times per second, with each droplet positioned precisely enough to hit reliably, hour after hour, in a production environment. Getting this from "works in a lab" to "runs 24/7 in a fab without breaking" took over a decade of dedicated engineering. The physics has been public for years; the engineering reliability has not.

5.     No Company Builds This Alone   And You Can't Copy an Ecosystem

ASML depends on a global supplier network   precision optics makers, vacuum system specialists, mechanical manufacturers   each contributing decades of their own accumulated expertise. The finished machine represents years of iterative collaboration between organizations, not just ASML's internal work.

Copying the machine doesn't recreate the supplier ecosystem, their quality control systems, or their specialized workforce. You'd need to rebuild an entire industrial network, not just a factory.

6.     Software and Process Knowledge Matter as Much as Hardware

EUV systems run on control algorithms, computational lithography, calibration routines and defect-correction software and even a perfectly reproduced machine still needs years of operational learning: how to run it, maintain it, improve yield on it and integrate it into a broader chip fabrication process.

7.     Reverse Engineering Answers "What," Not "Why"

This is the core limitation. Taking a machine apart tells you what it contains. It doesn't tell you why it was built that way, or how to reproduce its performance reliably at industrial scale. That gap between disassembly and replication   is where reverse-engineering efforts typically stall.

 

The Bigger Picture

• What you get from reverse engineering is What you still don't have
• Physical access to the machine needs Decades of tacit knowledge
• Component specifications vs Integration experience
• Design details vs Manufacturing culture
• Individual engineers: The organization behind them
• Patents and documents : The trial-and-error history
• System architecture: Production-scale yield

The bottleneck was never really about access to information. It's about the accumulated, hard-won capability to turn that information into a reliable, industrial-scale system  and that kind of capability doesn't transfer just because you have the hardware in front of you.

DHRUV64: What's Actually Indigenous and What Isn't

1.    India's DHRUV64 launch has been celebrated rightly as a milestone. But the coverage has blurred a distinction worth making clearly: 

 

What's genuinely indigenous

2.    The design and architecture work behind DHRUV64 is real, homegrown engineering. C-DAC, under the Digital India RISC-V (DIR-V) programme and MeitY's Microprocessor Development Programme, built a 1.0 GHz, 64-bit dual-core processor from the ground up. That's a legitimate capability milestone and India now has in-house teams who can architect, verify, and tape out a modern multicore chip. That skill pipeline (following SHAKTI, AJIT, VIKRAM, THEJAS) is the real story, and it deserves credit.

Pic Source: https://www.newindianexpress.com/business/press-releases/2025/Dec/15/india-launches-dhruv64-strengthening-indigenous-microprocessor-ecosystem

 What's borrowed and that's fine, but worth naming

3.    A few things get glossed over in the celebratory framing:

• The instruction set isn't Indian. DHRUV64 is built on RISC-V, an open, internationally governed ISA that anyone can use and is the same base architecture chosen by companies worldwide. Using RISC-V is a smart, pragmatic choice (it avoids costly ARM/x86 licensing), but it's not a uniquely Indian invention. "Fully indigenous processor" should mean indigenous design, not indigenous ISA and it's worth being precise about which one we're claiming.

• It wasn't fabricated in India. DHRUV64 was taped out and manufactured in Taiwan, on a mature 28nm process. This is COTS foundry capacity and the same kind any country without its own leading fab would use. (Notably, its predecessor THEJAS64 was fabricated domestically at the Semiconductor Laboratory, Mohali so India has done in-country fabrication before, just not for this chip.)

• 28nm is not cutting-edge. For context, the AI accelerators and high-end defence/space processors implies DHRUV64 will power typically run on 4–7nm nodes today. A 28nm chip is well suited to embedded systems, industrial automation, and IoT which is exactly how C-DAC has actually described it. It is not, technically, in the performance class needed for "next-gen AI platforms" or advanced missile guidance computation.

The quieter, more honest quote

4.    Buried in the actual interviews (not the press-release coverage) is this, from C-DAC scientist Libin T.T.:

DHRUV64 was conceived as a deliberate intermediate step, not a technological leap and is a bridge from low-frequency microcontrollers toward gigahertz-class application processors.

5.    That's a far more useful and credible framing than "rivals global leaders." It positions DHRUV64 correctly: a real, necessary rung on the ladder and not the top of it yet.

 Why this distinction matters

6.    None of this diminishes the achievement. Every semiconductor power including the US, China, and Taiwan built early capability on borrowed ISAs or foreign foundries before achieving full-stack sovereignty. The honest version of the DHRUV64 story is actually the more encouraging one: India has now proven it can design competitive silicon. The next milestones is indigenous fabrication at scale, and eventually leading-edge nodes are the ones to watch for.

7.    Calling DHRUV64 "fully indigenous" and implying it already powers cutting-edge AI and defence systems sets up a credibility gap the moment anyone checks the specs. Calling it what it is an indigenously designed processor on a mature, foreign-fabricated node, and a deliberate stepping stone  is both more accurate and, frankly, a better story.

Strategic Electronics Sensors & Critical Futuristic Technologies: SES-2026

 

I had the opportunity to speak at SES 2026 Bengaluru on the panel "Strategic Insights into Sensors, AI, Quantum, and Futuristic Technologies."

This presentation shares key insights from the session, exploring how advances in sensors, artificial intelligence, quantum technologies, and emerging innovations are shaping the next generation of intelligent systems. I hope these slides provide useful perspectives for researchers, engineers, technology leaders, and anyone interested in the future of deep tech.

CRYPTO BLIND SPOTS: Mapping the Vulnerability Gap in Mission-Critical Organizational Cryptographic Infrastructure

 

Explore hidden vulnerabilities in organizational cryptographic systems, the emerging threat of Cryptographically Relevant Quantum Computers (CRQCs), and the impact of rapid global quantum advancements. The presentation also examines strategies for crypto agility and cyber resilience against evolving quantum threats in mission-critical environments.

Cities as Data: Reflections on AI-Powered Urban Analytics at Geospatial World Forum 2026 Amsterdam, May 2026 : Panel-3

The third session I participated in at GWF 2026 shifted register somewhat away from the explicitly military framing of the earlier panels and toward something that affects a broader audience: how artificial intelligence is being applied to understand, manage, and secure urban infrastructure at scale. The audience was a mix of city planners, defence-adjacent technologists, data scientists, and policy people. That breadth made for a different kind of conversation.

Session 1 carried the title AI-Powered Urban Analytics: Data Science for Infrastructure Intelligence and the framing was deliberately wide. Urban infrastructure is a category that encompasses power grids, water systems, transport networks, telecommunications, public health monitoring, and the physical built environment. The question the session kept returning to was: what does it actually mean to apply AI to something this complex, this consequential, and this hard to fully observe?

---

The Infrastructure Intelligence Problem

Modern cities generate continuous data. Sensors embedded in roads, buildings, utilities, and public spaces produce streams that no human analyst team could meaningfully process at speed. AI-powered urban analytics is the attempt to make that data operationally useful not just archived, but acted upon.

The infrastructure intelligence framing matters because it shifts the goal from description to anticipation. A system that tells you a water main failed is useful. A system that identifies the precursor signatures of failure before it happens is transformative. That gap between reactive monitoring and predictive intelligence is where most of the serious work is being done, and where most of the serious risks live.

---

Bayesian Program Learning for Urban Pattern Recognition

One of the contributions I brought to this session was the relevance of Bayesian program learning as a framework for urban analytics problems. Most deployed urban AI systems are pattern-matchers  they learn from historical data and recognise recurrences. That works well in stable environments with abundant labelled data. Urban infrastructure is neither.

Bayesian program learning approaches the problem differently: rather than learning from volume, it learns programmes structured representations of how things work from very few examples, and generalises from those. In an urban context, this matters when you're trying to reason about rare events: infrastructure failure modes that have only occurred once or twice, novel threat signatures in a utility network, or unusual movement patterns in a city under stress. A purely statistical model trained on normal conditions will miss these. A model that has learned a causal programme for how the system behaves has a better chance of flagging the anomalous.

I raised this not as a deployed solution most urban analytics stacks are nowhere near this but as the direction that serious infrastructure intelligence work needs to move toward.

---

---

Differentially Private Federated Learning Across Urban Sensor Networks

Urban data is politically and legally sensitive in ways that military data is sensitive operationally. A smart city sensor network aggregates information about the movement, behaviour, and patterns of civilian populations. Centralising that data for AI training creates privacy exposure, legal liability, and in authoritarian contexts, a surveillance infrastructure that outlasts its original purpose.

I discussed Differentially Private Federated Learning as the architecture that makes urban analytics viable without those costs. The federated component means models are trained locally at the sensor node, the district server, the utility substation — and only model updates, not raw data, are shared upward. The differential privacy component means those updates are mathematically protected: calibrated noise is added such that no individual data point can be reconstructed from the aggregated model.

The practical implication is that a city can run a shared infrastructure intelligence model across its transport, utilities, and public safety systems without any single entity including the city government itself holding a centralised dataset of resident behaviour. That is not a minor privacy nicety. In a world where urban data infrastructure is increasingly a target, both for criminal actors and for state-level adversaries, it is an operational security consideration.

---

Sovereign AI and Urban Infrastructure

A thread that ran through this session, and one I pushed on, was the question of sovereign AI models in the urban context. Most cities deploying AI-powered analytics are doing so through commercial platforms often built on models trained elsewhere, hosted on infrastructure they don't control, and updated on schedules set by vendors.

The dependency this creates is underappreciated. A city's infrastructure intelligence layer, if it runs on a foreign-hosted model, is a city whose understanding of its own infrastructure is mediated by someone else's system. In peacetime that is a procurement question. In a crisis, a cyberattack, a natural disaster, a period of geopolitical tension, it becomes something more serious.

Sovereign AI in this context doesn't mean every city builds its own foundation model. It means the critical analytical layer that interprets infrastructure data runs on systems that are nationally or regionally governed, auditable, and resilient to external interference. The conversation around this at GWF was notably more advanced among European participants than I'd expected there is genuine policy momentum here, driven in part by the EU AI Act's implications for critical infrastructure AI.

---

---

AI Security Threats in Urban Systems

I flagged AI security threats specifically in the urban analytics context because the attack surface is different from military systems but no less consequential. Urban AI systems make or inform decisions about infrastructure allocation, anomaly response, and resource deployment. An adversary who understands how those systems work has options.

The threat I spent the most time on was adversarial input manipulation crafting sensor data or environmental conditions that cause an urban AI system to misclassify a situation. A power grid anomaly misclassified as normal. A movement pattern misclassified as routine. These aren't hypothetical attack vectors; they are documented in research and increasingly relevant as urban systems become more automated.

Persuasive AI came up in a different register here. In urban planning and infrastructure investment decisions, AI-generated analysis increasingly shapes what decision-makers see and prioritise. A system that surfaces certain patterns, routes certain recommendations, or frames trade-offs in particular ways can subtly steer decisions without any single output being obviously wrong. I raised this not as a conspiracy framing but as a design responsibility: the people building urban analytics systems need to think carefully about how their outputs are presented, what they omit, and whose interests the framing serves. Algorithmic outputs in consequential civic decisions warrant the same scrutiny we'd apply to any other form of expert advice.

---

What the Session Left Open

The honest closing note I'd offer on this session is that urban analytics as a field is at an interesting and slightly uncomfortable moment. The technical capability is running ahead of the governance frameworks. Cities are deploying AI systems for infrastructure management under procurement timelines that don't allow for the kind of adversarial stress-testing, privacy auditing, or sovereign architecture review that the stakes warrant.

GWF brought some of the right people into the same room. Whether those conversations translate into procurement standards, policy frameworks, or architectural requirements at the city level is the harder question and one that won't be answered at a conference.

Series: Geospatial World Forum 2026, RAI Amsterdam | April 27 – May 1

Shielding Digital Borders: On Cyber-Geospatial Convergence at Geospatial World Forum 2026 Amsterdam, May 2026 :Panel -2

The second panel I was part of at GWF 2026 sat at an intersection that doesn't get enough dedicated attention ,the point where geospatial infrastructure meets cyber threat. Most cybersecurity discourse treats location as incidental. Most geospatial discourse treats cyber as someone else's department. Panel Discussion 2 was built on the recognition that this separation is no longer defensible.

Panel Discussion 2: Cyber-Geospatial Convergence Shielding Digital Borders

The framing was precise: geospatial systems and satellite infrastructure are not passive data pipes. They are critical national infrastructure, and they are targeted accordingly. GPS spoofing, satellite uplink jamming, attacks on ground-based GEOINT processing nodes these are not theoretical. They are documented, ongoing, and accelerating. The session brought together people working on the technical, doctrinal, and policy dimensions of this problem.

What made the conversation worth having was the convergence thesis itself: that cyber and GEOINT are now inseparable disciplines, and that defending one without the other is defending half a system.

Protecting Geospatial Systems and Satellite Infrastructure

I opened my contribution by framing the threat landscape in terms of what adversaries actually target. Satellite infrastructure presents a layered attack surface the space segment, the ground segment, and the user segment each carry distinct vulnerabilities. The ground segment is often the weakest: uplink facilities, processing nodes, and the data pipelines feeding downstream users are frequently built on commercial-off-the-shelf components with known vulnerability profiles.

This is where zero-day vulnerabilities become a specific concern. A nation-state adversary with a stockpile of undisclosed exploits targeting GEOINT ground infrastructure can, in principle, corrupt or deny geospatial data at a moment of their choosing not through jamming, which is detectable, but through quiet manipulation of the data itself. I raised this because it changes the threat model: the risk isn't just losing access to geospatial data, it's receiving geospatial data you can't trust.

KASLR bypass came up here in the specific context of processing nodes running geospatial workloads hardened systems that may not be on aggressive patch cycles, where kernel-level mitigations are sometimes the last meaningful layer of defence.

Zero Trust for Critical Defence Networks

The question of how you architect a defence network that handles geospatial data from multiple sources allied feeds, commercial satellite imagery, classified sensor outputs is fundamentally a trust problem. I argued that Zero Trust Architecture is the only coherent answer.


In a traditional perimeter model, once you're inside the network you're largely trusted. In a geospatial defence context, that assumption is catastrophic. Data enters from dozens of sources. Analysts, platforms, and automated systems consume it. A single compromised node or a single poisoned feed propagates through a trusted interior.

ZTA flips the model: no implicit trust, continuous verification, least-privilege access at every layer. Applied to geospatial pipelines specifically, it means every data feed is authenticated, every query is logged, and access to sensitive spatial layers is granted on a need-to-know basis that is enforced technically, not just by policy.

 

 

Privacy Budget and Differential Privacy in GEOINT

One of the more technically nuanced threads in the session involved the tension between intelligence sharing and data exposure. Sharing geospatial intelligence with allied partners is operationally valuable. It is also, without careful architecture, a way of leaking the collection methodology, sensor positioning, and analytical capability of the sharing party.

I discussed differential privacy and the concept of a privacy budget in this context. When you query a geospatial dataset repeatedly asking for patterns, anomalies, movement signatures each query leaks a small amount of information about the underlying data. A privacy budget is a formal bound on how much total leakage is permissible before the queries must be refused or the results degraded. Applied to shared GEOINT environments, it gives you a principled way to enable analytical collaboration without progressively exposing your raw collection.

This connects directly to Zero-knowledge proofs a cryptographic method by which one party can prove to another that a claim about data is true without revealing the data itself. In a geospatial context: proving that a particular asset was observed within a defined area of interest without disclosing the sensor's actual position or the full imagery. I raised ZKPs as an underutilised tool in the GEOINT sharing problem, particularly relevant in coalition environments where full data disclosure is neither politically nor operationally acceptable.

Homomorphic Encryption The Audience Question

One of the more engaged exchanges during the Q&A came after I discussed homomorphic encryption in the context of processing sensitive geospatial data across untrusted or semi-trusted compute environments. The question from the floor was direct: "Is homomorphic encryption actually deployable at the scale and latency that operational geospatial systems require, or is this still fundamentally a research tool?"

It's the right question. My honest answer was: we are in a transitional period. Fully homomorphic encryption which allows arbitrary computation on encrypted data remains computationally expensive at scale. The latency overhead for complex geospatial operations is still significant. However, partially homomorphic and levelled homomorphic schemes, which support a defined set of operations, are moving toward practical deployment in specific high-value use cases. The compelling application in this context is exactly what was described in the network-centric session too enabling a partner nation's analytical layer to query encrypted geospatial datasets without decryption, preserving both data security and analytical utility.

The trajectory is toward deployment. The honest timeline for operational-scale fully homomorphic systems in geospatial pipelines is probably five to eight years for most contexts, with specific constrained applications earlier. That answer generated a follow-up from the same audience member about whether post-quantum readiness of these encryption schemes was being considered in parallel which led neatly into the next thread.

Post-Quantum Cryptography and the Satellite Infrastructure Problem

Satellite infrastructure has a specific post-quantum problem that I wanted to surface in this session. Satellites launched today will be operational for fifteen to twenty years. The cryptographic protocols protecting their command-and-control links, their data downlinks, and their authentication systems are in many cases based on RSA and elliptic curve cryptography both of which are broken by a sufficiently capable quantum adversary running Shor's algorithm.

I discussed Peter Shor's 1994 result not as a historical curiosity but as a planning constraint. If you are designing or procuring satellite infrastructure today, the migration to post-quantum cryptography is not a future problem it is a current design decision. The migration challenges are real: legacy systems with embedded cryptographic assumptions, constrained uplink bandwidth that limits the size of post-quantum key exchanges, and the coordination problem of migrating ground and space segments simultaneously.

Lattice-based cryptography is where the global alignment is converging. NIST's post-quantum standardisation process has weighted heavily toward lattice constructions CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium for digital signatures. I discussed where China, Russia, and the United States are each moving: the US through the NIST process and NSA guidance toward lattice-based standards; China through its own parallel standardisation track with some convergence on lattice methods but with domestic algorithm preferences that create interoperability questions; Russia maintaining a more opaque posture but with known investment in quantum computing research that suggests they are not passive observers. The geopolitical dimension of PQC standardisation who sets the standard, who audits compliance, who controls the reference implementations is itself a dimension of the cyber-geospatial problem.

Countering Hybrid and Asymmetric Threats with Integrated GEOINT

The session's closing thread was perhaps the most strategic. Hybrid threats the combination of conventional military pressure, cyber operations, disinformation, and economic coercion are explicitly designed to operate below thresholds that trigger conventional response. Geospatial intelligence, when properly integrated with cyber situational awareness, is one of the tools that makes hybrid operations legible.

I raised AI security threats in this context specifically the risk that AI-assisted geospatial analysis systems are themselves targets. An adversary who understands that your targeting or pattern-of-life analysis runs through a specific AI model has an incentive to probe and manipulate that model's inputs. Distillation attacks reconstructing a model's behaviour by observing its outputs are relevant here: if your GEOINT-AI pipeline's decisions can be predicted by an adversary, you've handed them a significant operational advantage.

The integration of cyber and GEOINT disciplines isn't just a technical architecture question. It's a question of whether the people who understand satellite vulnerability assessments are talking to the people who understand cryptographic attack surfaces, and whether both groups are talking to the people making doctrine. At GWF 2026, for a few days at least, they were.

Series: Geospatial World Forum 2026, RAI Amsterdam | April 27 – May 1

Previous: Panel Discussion 5 Network-Centric Warfare and Data Centricity Next: Session 1 AI-Powered Urban Analytics: Data Science for Infrastructure Intelligence

Reflections on Network-Centric Warfare at Geospatial World Forum 2026 Amsterdam, May 2026: When Data Becomes a Weapon : Panel -1

Earlier this year I received an invitation to participate in the Geospatial World Forum 2026 at the RAI Amsterdam  that is one of the more substantive gatherings in the Geospatial and Defence intelligence space. The week ran from April 27 through May 1, and I found myself sitting across from some of the sharpest practitioners working at the intersection of spatial intelligence, defence systems, and emerging technology. The conversations were candid, the perspectives diverse, and the stakes  given the current geopolitical climate  very real.

I was part of three panel discussions across the week. This is the first of a short series of posts where I'm putting down what we discussed  mostly for my own records, partly because these conversations deserve to exist somewhere beyond a conference hall.

Panel Discussion 5: Network-Centric Warfare and Data Centricity

The session title sounds clinical and crisp. What it actually described was one of the most consequential shifts in modern military doctrine  the move away from platform-centric thinking toward a model where the network itself is the force multiplier.

The core premise is straightforward: a sensor that sees something is only useful if that observation reaches a decision-maker before the window closes. In legacy architectures, that gap  between observation and action  has historically been where wars are lost. Network-centric warfare is the systematic attempt to collapse that gap.

Linking Sensors, Platforms, and Decision-Makers

What struck me most in our discussion was how mature the concept is, and how immature the execution still remains in many theatres. The vision is elegant: sensors  whether satellite, UAV, ground-based radar, or human intelligence feeds  pipe data into a unified digital ecosystem where platforms (vehicles, aircraft, naval assets) and decision-makers share a common operational picture in near-real-time.

The friction points are less glamorous. We talked about data standardisation across allied forces, legacy systems that weren't designed to interoperate, and the latency that creeps in at every translation layer. One of the panellists made a point I keep returning to: the weakest link in most network-centric architectures isn't the sensor  it's the middleware.


 

Rapid Data Sharing for Coordinated Response

The session highlight framing mentioned "coordinated and adaptive combat responses"  and this is where the discussion got genuinely interesting. Adaptive is the operative word. A static command-and-control model assumes that orders flow downward and the environment cooperates. Modern conflict doesn't offer that.

What network-centricity enables, at its best, is a force that can recompose itself in response to ground truth rather than responding to a plan that was made twelve hours ago. That requires not just fast data pipelines, but trust in those pipelines. Operators need to act on data they haven't personally verified. That's a significant psychological and institutional shift, and it came up more than once.

We also touched on the adversarial dimension  what happens when an opponent understands your data architecture well enough to inject noise, delay, or disinformation into it. The network that enables adaptive response can also be the attack surface. This bleeds directly into the cyber-geospatial panel I was part of later in the week, which I'll cover in the next post.

Situational Awareness, Force Agility, and Mission Effectiveness

These three phrases tend to travel together in defence literature, sometimes as buzzwords. In practice, they describe a genuine capability gradient.

Situational awareness at the tactical level means a soldier knows what's beyond the next ridgeline. At the operational level, it means a commander understands how a theatre is evolving across multiple simultaneous engagements. Network-centric architecture is what connects those two levels and everything between.

Force agility  the ability to reposition, reassign, or re-task elements quickly  is a direct function of how good that common picture is. If your forces are operating on shared, current data, you can exploit opportunities and respond to threats faster than an opponent who isn't.

Mission effectiveness is the output of the two above, but it also depends on something the technology can't fully provide: trained humans who can interpret ambiguous data and make decisions under pressure. We spent some time on this. The risk of over-automating the common operational picture is that you optimise for the scenario you modelled, not the one you're actually in.

WHAT I DISCUSSED 

On ZTA in networked battlefield architecture: One of the points I raised was why Zero Trust Architecture isn't optional in a network-centric environment  it's foundational. When you're linking sensors, platforms, and decision-makers across a distributed ecosystem, the old perimeter-defence model collapses entirely. Every node, every data feed, every inter-platform handshake has to be treated as potentially compromised. Assume breach, verify continuously, grant least-privilege access. In a coalition context especially, where you're operating with allied systems you don't fully control, ZTA is the only architecture that makes operational sense.

On zero-day exposure in sensor-platform pipelines:I brought up zero-day vulnerabilities specifically in the context of the network's attack surface. The more you integrate  sensors feeding platforms feeding command layers  the more entry points you create. A zero-day in a firmware layer of a battlefield edge device isn't just an IT problem; it's a potential blind spot or worse, a spoofed data feed entering your common operational picture. The network that gives you agility is the same network that, if unpatched and unmonitored, gives an adversary a quiet way in.

On homomorphic encryption for coalition data sharing: A practical problem in joint operations is that allied nations need to share processed intelligence without exposing raw sensor data to each other's systems. I discussed homomorphic encryption as a maturing solution here  the ability to run computation on encrypted data means a partner nation's AI layer can query your dataset without you ever decrypting it on their side. We're not at frictionless deployment yet, but the direction is clear.

On Differentially Private Federated Learning for shared battlefield AI: Federated learning lets distributed nodes  forward units, vehicles, command posts  contribute to a shared intelligence model without centralising raw operational data. Add differential privacy on top of that, and you're injecting calibrated noise into each node's contribution such that no individual data point can be reverse-engineered. I raised this as the architecture that makes collaborative battlefield AI viable without creating a single honeypot of sensitive operational data.

 

On sovereign AI models: This came up when we discussed why coalition forces can't simply share an AI layer the way they might share a radio frequency. Every nation feeding data into a shared model is implicitly exporting its operational patterns, its sensor signatures, its tactical doctrine. Sovereign AI  models trained and hosted within national infrastructure, on national data  isn't protectionism, it's operational security. Interoperability has to happen at the interface layer, not by pooling the model itself.

On distillation attacks against tactical AI: I flagged distillation attacks as an underappreciated threat vector in deployed military AI. If an adversary can interact with your tactical decision-support system enough times  even indirectly, through observing its outputs in the field  they can begin reconstructing its behaviour in a surrogate model. You've effectively handed them your doctrine without them ever touching your training data. Access control to AI system outputs matters as much as access control to the data that trained it.

On KASLR bypass at the edge: At the device level, KASLR bypass deserves attention in hardened military hardware. Kernel Address Space Layout Randomisation is a standard mitigation, but known bypass techniques mean it can't be the last line of defence on edge battlefield devices. I raised this in the context of the network's physical endpoints  the sensors and terminals that are closest to the threat environment and furthest from the patch cycle.

More from Amsterdam in the next post  on cyber-geospatial convergence and what it means to protect digital borders that exist in three-dimensional space.

OpenClaw AI — A Technical Brief: Architecture, Security & Policy Analysis

 

OpenClaw AI:Security Risks, Architecture by Anupam Tiwari 

1.    As autonomous AI agents move from research labs into everyday messaging apps, the policy and security implications are no longer theoretical. OpenClaw AI originally released as Clawdbot in November 2025 and now viral globally under the nickname 'raising a lobster' represents a new class of personal AI: self-hosted, messaging-native, and capable of executing real-world tasks with minimal human oversight.

2.    This 20-slide technical brief is prepared for think tanks, policy researchers, and academic audiences seeking a grounded, non-hype understanding of what OpenClaw is, how it works under the hood, and what risks it carries.

What this brief covers:

• Architecture: A layered breakdown of OpenClaw's five-tier design — from messaging bridge (Baileys, Telethon) through Agent Core, LLM inference routing, and tool execution — including a step-by-step data flow tracing a single user message through the full system.
   
• Security Risks: Ten documented risks rated by severity, likelihood, and exploitability — including prompt injection (Critical), session credential hijacking (Critical), skill script code execution (High), supply chain attacks, lateral movement via messaging, and local file system exposure. Each risk includes a realistic attack example.
   
• Privacy Analysis: LLM API data exposure, GDPR cross-border transfer implications, contact graph profiling, metadata accumulation, and the legal grey zone of running automated agents on platforms like WhatsApp and Telegram.
   
• Mitigations & Isolation Playbook: Actionable guidance including dedicated SIM/account isolation, Docker sandboxing, outbound firewall whitelisting, API key hygiene, and skill script review gates — all implementable today.
   
• Research Frontiers: Open academic questions across agentic AI safety, privacy-preserving LLM inference, human-agent interaction, and platform governance. 

This is not a product review or a user guide. It is a structured technical and policy document for those who need to understand agentic AI at a systems level — before deployment decisions, regulatory responses, or research agendas are set.

Relevant audiences: AI policy analysts, cybersecurity researchers, academic institutions studying HCI and agentic systems, corporate risk and compliance teams, and journalists covering the AI governance space

The Landscape of Modern Positioning Technologies

Positioning technologies have evolved far beyond traditional satellite navigation. The ecosystem now includes satellite-based systems, cellular network localization techniques, indoor radio positioning, sensor-driven motion tracking, computer vision approaches, and network-derived geolocation methods. 

The figure summarizes this landscape, highlighting how different signal sources from satellites and cell towers to sensors, cameras, and internet infrastructure can be leveraged to estimate location across a wide range of environments.

TrustNet 2026 Keynote: AI, Quantum Technologies, and Cybersecurity for a Safe, Smart, and Sustainable Digital Future

Trusted Networks & Intelligent Systems: TrustNET 2026 by Anupam Tiwari 

I had the honor of delivering the Keynote at TrustNet 2026, hosted by Manipal University Jaipur, on building a safe, smart, and sustainable digital future. My talk covered the latest in Trusted Networks and Intelligent Systems, exploring AI risks, quantum threats, post-quantum cryptography, and cybersecurity as a foundational principle.

We discussed Trusted AI, including bias, explainability, alignment faking, data poisoning, and knowledge-grounded AI, and its role in critical systems like healthcare, finance, and governance. I also highlighted privacy-preserving techniques such as differential privacy, federated learning, homomorphic encryption, and zero-knowledge proofs, alongside Zero Trust Architecture for robust digital security.

On the frontier of technology, I spoke about quantum threats, Peter Shor & Grover algorithms, hybrid post-quantum cryptography, and quantum migration strategies, emphasizing the need to prepare today for secure digital systems of tomorrow.

Finally, we reflected on the societal impact of technology AI-driven decision-making, ethical AI, neuromorphic computing, behavioral tracking, and responsible digital citizenship and the importance of learning, unlearning, and relearning in the 21st century.

Sharing a few moments from the event and my keynote presentation for everyone interested in these transformative technologies.

Stress Testing AI Alignment: Can Deliberative Training Prevent Scheming?

Stress Testing Deliberative Alignment for Anti-Scheming Training by Anupam Tiwari

PREMISE & INTRODUCTION

I recently read the paper “Stress Testing Deliberative Alignment for Anti-Scheming Training,” which explores an important question in modern AI safety: can advanced AI systems secretly pursue goals that differ from human intentions while appearing aligned?

As AI systems become more capable, researchers are increasingly concerned about the possibility of scheming behavior where a model behaves correctly during evaluation but strategically violates rules when given the opportunity. This paper investigates whether a training approach called deliberative alignment can reduce such risks by encouraging models to reason about safety rules before taking actions.

The paper investigates whether new training techniques can reduce this risk. Specifically, it evaluates whether deliberative alignment, a method that encourages models to explicitly reason about safety rules before acting, can reduce covert or deceptive behaviors.

PROBLEM

Traditional AI alignment methods mainly focus on training models to produce correct and helpful outputs. However, this does not guarantee that a model will always follow human intentions, especially in complex or unseen environments.

A key concern is scheming, which involves three components: 

• Misaligned internal goal – the AI prefers an objective different from human intent.

• Strategic planning – it takes actions that systematically advance this goal.

• Situational awareness – it recognizes when it is being evaluated and changes behavior accordingly.

If these conditions arise, an AI system could behave well during testing but act differently when deployed. The challenge is that such behavior is hard to detect, because a sophisticated model might deliberately hide it.

METHODOLOGY

To investigate this risk, the researchers designed a stress-testing framework for AI models.

Deliberative Alignment Training

The models were trained to:

•     Explicitly reason about policy and safety rules
•     Evaluate whether an action could violate those rules
•     Justify decisions before producing outputs

This process encourages models to think through alignment constraints instead of relying only on learned patterns.

Stress-Test Environments

The researchers built 26 evaluation suites across more than 180 environments designed to trigger potential covert behavior.

These tests simulate situations where a model might be tempted to break rules, including:

• Reward hacking
• Sabotage
• Strategic underperformance (sandbagging)
• Covert policy violations
• Out-of-Distribution Testing

Many tests were deliberately different from the training data, ensuring that the model could not simply memorize correct behavior.

RESULTS

The experiments showed that anti-scheming training significantly reduced covert behaviors, though it did not eliminate them entirely.

Some models showed dramatic improvements:

• Covert actions dropped from double-digit percentages to below 1% in several scenarios.

However, the results also revealed important nuances:

• Covert actions still occurred in rare cases

Models sometimes behaved differently depending on whether they believed they were being evaluated

DISCUSSION

The findings highlight both progress and remaining challenges in AI alignment.
Positive signals

Deliberative alignment appears to:

•     Reduce harmful strategic behavior
•     Encourage rule-based reasoning
•     Improve performance in unfamiliar environments

REMAINING RISKS

However, the study also raises important concerns:

•     Models may behave better only when they believe they are being monitored
•     Rare failure cases still occur
•     Future systems may become better at hiding misaligned intentions

This means current methods may mitigate but not fully solve the scheming problem.

FINAL THOUGHTS

• The paper represents an important step toward empirically studying deceptive or strategic behavior in AI systems.

•  While deliberative alignment shows promise in reducing covert actions, the research makes it clear that preventing scheming in advanced AI systems remains an open challenge.

Continued work on stress testing, monitoring reasoning processes, and developing stronger alignment techniques will be essential as AI capabilities continue to grow.

TAKEAWAY

Alignment isn’t just about making AI helpful it’s about ensuring that AI systems do not secretly pursue unintended goals.