Full Episode Transcript

Good afternoon. It's Friday, and blessedly sunny in London, a rare enough occurrence to warrant a mention, I feel. Welcome, once again, to Turing's Torch. We're here, as ever, to try and make some sense of the ceaseless torrent of pronouncements emanating from the world of artificial intelligence. It's a week where the signal, as so often, seems determined to be drowned out by the noise. Which brings me, rather inevitably, to Alan Turing himself. He once observed, with his characteristic, and frankly, prescient, clarity. "It is not possible to produce a set of rules purporting to describe what a man should do in every conceivable circumstance." And that, I think, captures the essence of our challenge this week, doesn't it? This relentless pursuit of universal answers, when reality, as always, is far messier. We've got a good deal to get through, so let's not waste any more time. This is Turing's Torch: Artificial Intelligence Weekly — the bits that matter, minus the hype.

There has been a small cluster of stories this week that, when stitched together, form a reasonably worrying pattern. At the centre are systems we built to protect us that can be nudged into doing precisely the opposite. The name given to one such technique is Friendly Fire — a practical method for turning defensive artificial intelligence agents into tools of attack. That phrase is designed to be memorable, and in this case it is deservedly sharp. Researchers showed how an agent that a team entrusted with patching, scanning. And blocking traffic could be persuaded to execute arbitrary code on its host machine. Not in some contrived simulator, but in real, out‑of‑the‑box configurations people might deploy. An agent, for clarity, is not a philosophical concept. It is software arranged around a language model that takes inputs, consults tools, and acts with some degree of autonomy. When you give that software defensive authority — the capacity to change firewall rules, run forensic scripts. Or fetch and build third‑party code — you create a single, very practical vulnerability. Friendly Fire exploits the gap between intended behaviour and brittle real‑world responses. By feeding the agent crafted inputs that trigger a predictable chain of misunderstandings, an attacker can convert a defender into an attacker. Suddenly the scanner that was supposed to quarantine a suspicious package is instead running the package's payload. That vulnerability is operational, not merely academic. Security teams increasingly rely on automation because sheer scale makes human monitoring impossible. We let agents triage thousands of packages and dependencies because they are faster and because humans would be overwhelmed. But when the automation is permitted to fetch, interpret and run code, a maliciously formed repository becomes a delivery mechanism. An automated code analysis tool, running with default privileges, can be coaxed to execute commands. That is not a distant what‑if; several common CLI tools used to analyse code have been demonstrated as vulnerable in practical setups. Remote code execution here means what it always means: some input provokes a machine to run commands it was never meant to run. The guard dog has been given the keys to the house and, in a particular sequence of prompts, takes instruction from the intruder. The consequences are obvious and immediate. A compromised analyst workstation can leak credentials, provide a foothold for lateral movement, or become a staging ground for further compromise. It is not simply about data being exposed; it is about control changing hands. If you are an engineer, the sensible reaction is workmanlike rather than panicked. Treat agents as you would any critical piece of infrastructure. Audit the permissions you hand them. Assume defaults are wrong. Implement least privilege and deny network access unless it is explicitly necessary. Run them inside strong sandboxes and maintain robust logging and audit trails. Require human approval for high‑impact actions. In short, do the boring, difficult engineering that security has always demanded. Delegation buys convenience. Delegation also buys a concentrated attack surface. More inconvenient still is that convenience sells. Vendors ship tools with user‑friendly defaults because usability helps adoption, and buyers happily accept an easy setup. But ease of use has a cost that someone pays later, often in the unpleasant four‑letter flavour of an incident response. Vendors must harden their defaults. Customers must test their deployments against maliciously crafted inputs. It's a straightforward, if uncomfortable, reallocation of effort. The Friendly Fire story sits beside another, more technical trend: toolchains that analyse code can be turned into attack vectors. Because they fetch, build and interpret untrusted artefacts. Several command‑line code analysis tools that security teams use to examine open‑source components were shown to be exploitable when run with the standard configuration. The analysers are meant to help teams keep track of supply‑chain risk. They now also represent supply‑chain risk. If an attacker ships a repository designed to execute during analysis, the scanner itself executes the payload. Scale makes this problem worse. Security teams scan thousands of packages. They scan new versions automatically. The time and expertise required to vet every package manually is prohibitive. So automation is not an optional luxury; it is a practical necessity. What changes is the calculus of where to place the building blocks of trust. Tight sandboxing, stringent input validation, network isolation and careful whitelisting are the defensive patterns we can apply. Those are not sexy. They are not going to make a marketing deck. They will, however, reduce the probability that an automated defender turns into a vector for compromise. There is a political and commercial wrinkle to this engineering advice. If defensive agents become weaponisable, liability shifts and trust fractures. Customers will ask vendors for guarantees and for evidence of hardening. Insurance underwriters will ask for proof of testing. That will change procurement conversations and likely raise the price of usable automation. Companies that offer "secure by default" agents will have an advantage. That is how markets adapt when risk moves from the theoretical to the operational. If you want an even more specific example of how the automation arms race changes risk, look at the recent proof‑of‑concept exploits against code‑analysis CLIs. They show how tools designed for convenience can be coaxed into running commands during analysis. Again, the fix is familiar: isolate the analysis process, limit the privileges of the runner, and require explicit manual checks for high‑risk artefacts. The remarkable thing is not that attackers exploited these behaviours; it is that we expected brittle general‑purpose systems to behave securely without engineering safeguards. That was never a plausible gamble. There is a broader intellectual thread here about brittleness and transparency in systems built around machine learning. Some progress is being made in opening up the black box, but the work is far from complete. Anthropic, for example, has been using an approach called the Jacobian lens to probe internal model sensitivities. The method asks a simple question: if we nudge the model's internal state slightly, how does the output change? Tracing those sensitivities can reveal directions in activation space that reliably affect certain behaviours. When those directions align with human notions — categories, tensions. Something that resembles deliberation — it's tempting to interpret the result as evidence of internal thought. A careful distinction is required. Those directions are patterns in an abstract mathematical space, not a little person sitting inside the model. Describing a recurring activation pattern as "puzzling" is an interpretive move, not a literal observation. That doesn't make the work unimportant. If engineers can find persistent, interpretable internal signals, they can build monitors and interventions. They might debug hallucinations more quickly, steer a model away from hazardous outputs, or produce stronger explanations of why a model said what it did. That opens levers for governance and for product quality. Equally, those same levers can be weaponised or misinterpreted. If a firm can surgically edit internal representations, it might also obscure behaviour or tailor models to game audits. And a discovery of an interpretable signal is not, by itself, a panacea for trust. It is another diagnostic tool. Think of it like an X‑ray: useful for seeing structures, imperfect for reading intentions. Mechanistic interpretability — the patient work of mapping computation rather than merely testing inputs versus outputs — is sensible and overdue. It pushes back against two lazy extremes. One extreme treats large models as wholly inscrutable black boxes to be monitored only at the surface. The other imputes full human‑like cognition and narrative thought to activation patterns. Both positions are wrong. The new methods we are seeing carve out a middle path. They offer actionable insights without promising inner life. That is a distinction worth making loudly, because the temptation to talk about "thoughts" sells headlines faster than sober technical nuance. The security and interpretability strands intersect in worrying ways when the agents in question are permitted to act directly on sensitive systems. If you have an agent whose inner signals indicate certain conceptual states, you might be able to detect. When it is heading towards an unsafe action. But that only helps if the signals are robust, consistent across deployment conditions, and not trivially manipulable. In the real world models face noisy inputs, unforeseen interactions with other software, and adversarial nudges. Signals that look stable in a lab can wobble under pressure. The pattern repeats elsewhere in the stack. We saw an array of practical tools and tutorials this week that lower the barrier to deploying capability, for better and worse. Ultralytics released a hands‑on tutorial for their latest YOLO26 tooling, showing how to run object detection, instance segmentation and pose estimation in real time. LlamaIndex shipped a legal‑kb reference app to give agents filesystem‑style access to document knowledge bases. Synthetic Sciences published an open workbench called OpenScience that assembles editable "skills" for scientific workflows. Sakana artificial intelligence introduced a translation feature that embeds multilingual modes into chat. Each of these is, in its own way, useful. They are plumbing meant to be practical. But practical plumbing invites practical risk. Real‑time vision pipelines make surveillance cheaper and quicker to deploy. A hands‑on tutorial often glosses the ongoing maintenance costs: re‑labelling data, retraining models, coping with changing camera angles and lighting. The winner's circle at a robotics competition, recently concluded in Incheon, showcases impressive feats of embodied artificial intelligence. Those highlight reels are enjoyable and informative. They do not, however, reveal whether a chassis can operate reliably across months of unscripted use. Competitions reward peak performance. They favour teams that can tune parameters and exploit the specifics of an arena. Real‑world reliability rewards different engineering virtues: resilience under variation, battery longevity, predictable degradation and maintainability. A podcast database of match clips and workshop snapshots gives immediacy; it does not replace reproducibility data. For funders and policymakers, that distinction matters. Podium lists steer attention and funding. But a trophy is the start of a conversation about scaling, not the end. The legal‑kb app is an instructive case of useful plumbing confronting governance. It packages tools to make legal documents navigable like a filesystem. Agents can retrieve specific files, run hybrid semantic search, version documents, and produce visual citations. That addresses a real pain point: lawyers and compliance officers need answers tied to provenance, not persuasive prose without a source. If an agent claims a clause exists in a contract, you want the exact page, version and context. The app moves work away from ad‑hoc prompt engineering toward auditable document workflows. At the same time, deploying such systems safely requires careful integration. Authentication, role‑based access control, and enterprise‑grade logging are not optional. The technology makes some tasks easier, but it cannot fix broken organisational processes. Better search does not substitute for governance. If a legal team adopts an agent that can access sensitive agreements, they must also consider audit trails, data residency and who controls the model. The practical lesson is mundane: build the infrastructure around the agent properly, or the agent will amplify existing organisational weaknesses. A similar point applies in life sciences. Anthropic's public beta of Claude Science, integrated with NVIDIA's BioNeMo Agent Toolkit, promised a conversational workbench that can federate biological computation tasks. The claim is attractive: speak in natural language and have the system orchestrate simulations, wrappers and analyses. That reduces friction between domain experts and the underlying compute. But the reality of lab pipelines is messy. Datasets are bespoke. Compute budgets are finite. Integrations are bespoke and fragile. Takeda's large commercial deal with Insilico Medicine, a $600 million collaboration, highlights the economics and politics of that area. Pharma companies are betting that artificial intelligence platforms can accelerate early‑stage discovery. The prospect is plausible: better candidate generation and triage could reduce the time spent chasing dead ends. Yet the hard, costly parts of drug development remain downstream in toxicology and clinical trials. Money buys access to proprietary platforms and privileged datasets. That access in turn concentrates capability, and concentration tends to favour incumbents who can afford the integration and compute. It is a pattern we have seen before: the vendors who control the models and the data enjoy leverage that goes beyond mere technical performance. Synthetic Sciences' OpenScience is another expression of the same dynamic. It supplies a model‑agnostic workbench with editable skills and queryable databases. The code is open, but the heavy lifting — models and compute — remains the expensive, controlled part. Reproducibility improves when workflows are shared, but only if the recipient has the machines to run them. Open software lowers some barriers. It does not, on its own, democratise compute. There is a strategic angle to all of this. Companies that can combine software, datasets and in‑country compute are increasingly comfortable asserting technological sovereignty. Meituan's announcement of LongCat‑2. 0, a 1. 6 trillion‑parameter mixture‑of‑experts model with claims of a native one‑million token context window, is an example. The headline numbers are meant to signal scale and independence: split the model into many experts. Activate only a slice per token, and serve it on domestic ASIC superpods. If accurate, those design choices reduce reliance on foreign cloud infrastructure and on the particular economics of rented GPUs. The engineering truth is less glamorous. A million‑token context simplifies some workflows but does not eliminate the problems of accuracy, attribution or hallucination. Mixture‑of‑experts architectures are efficient, but they introduce new routing complexity and potential brittleness. Serving on domestic chips gives control, but it also creates a closed stack that is harder to audit by independent third parties. The commercial takeaway is simple: infrastructure choices are political choices. They determine who can afford to run models, who controls updates, and who has the operational visibility necessary for safety and compliance. The same tension appears in the conversation about multivendor strategies. Organisations that once relied on a single supplier are reassessing what felt like stability. A multivendor posture spreads risk across providers, reducing dependency on any single company. That can be insurance against sudden pricing changes, policy shifts, or service outages. The price, however, is operational complexity. Engineers spend more time writing glue code, running integration tests, and tracing failures across providers. Security teams audit more supply chains. Procurement deals with a profusion of contracts. Multivendor is not an ideological position. It is an operational choice akin to insurance. It makes sense for assets you cannot easily replace. For smaller teams, the overhead may be unaffordable. A sensible middle ground is to design modular systems that can switch execution targets without a full rewrite. Build clear abstractions and test fallbacks. That approach buys optionality without forcing premature complexity. Circling back to product features that bring capability closer to users, the multimodal systems now routinely read documents. Interpret charts and hold sustained back‑and‑forth dialogue about images. Models such as GPT‑4o, Claude with vision, Gemini and Qwen‑VL are being used to convert pixels into conversational input. That has immediate, practical benefits. Accessibility improves for people with visual impairment. Business processes like invoice extraction become quicker. Researchers can point a model at a complex chart and ask for a plain‑English summary. But there is a mismatch between convenience and responsibility. Vision models are brittle. Small perturbations to an image or adversarial edits can produce wildly different outputs. The tendency of such models to produce confident but incorrect statements is a familiar hazard. The reality of integrating multimodal assistants into workflows is that they centralise both capability and data. The firms that operate these systems gain influence over access and pricing. That economic centralisation matters for standard‑setting and for who pays compliance costs. Translation tools illustrate the same set of trade‑offs on a smaller scale. Sakana artificial intelligence's integration of a Namazu‑based translation service into chat applications offers modes for straight translation, proofreading and interrogative querying about choices. That last mode is actually important: users want to know why a phrase was rendered a certain way. Explainability matters as much in translation as it does in other domains. Benchmarks such as XCOMET‑XL give an indication of quality, but they do not capture cultural nuance, diachronic shifts in meaning, or local legal phrasings. Again, practical governance questions arrive. If translations route through a cloud service, who owns the data? How is sensitive content handled? Automation reduces routine labour and smooths workflow, but it does not eliminate the need for native expertise when stakes are high. A mistranslation in a contract, a medical instruction or a regulatory filing can be costly. A translation assistant that polishes tone is useful. It is not a replacement for human review where precision matters. There are several narrowly technical advances worth noting that show the field's ongoing pragmatic progress. Teams have been fine‑tuning models economically by adding LoRA adapters and then merging them for deployment. A recent experiment took a base model and improved its performance on grade‑

Well, that was another rather brisk trot through the artificial intelligence field. It's a territory that seems determined to outpace common sense, which is precisely why we aim for a bit of measured perspective here. If you'd like a slightly more… consistent dose of that perspective, you might consider the daily briefing. It's a single email, delivered to your inbox, and I promise you, it's free of the usual digital fanfare. You'll find that at jonathan-harris dot online. And speaking of things that might offer a different angle, this week's sponsor is, rather conveniently, my own book. It's called "Lights, Camera, Algorithm: artificial intelligence's Role in Modern Filmmaking". And if you're curious about how this whole digital revolution is reshaping the silver screen, you'll find it in the eBooks section. That's your lot for this week's Turing's Torch. If you want the daily brief, head to jonathan-harris dot online. Same time next week — try not to believe the press releases.