Anthropic Embeds Invisible Watermarks in Claude Outputs

Philip Hall

-

August 13, 2026

Anthropic Embeds Invisible Watermarks in Claude Outputs

Anthropic has started embedding invisible watermarks into every piece of text, code, and file output produced by its Claude models. The company quietly published a support page outlining the change, which it says aligns with the European Union AI Act’s transparency requirements and applies globally to all Claude users.

Some Claude users are not happy with this change!

The system works by inserting a hidden digital signature that travels with copied and pasted content outside the Claude platform. Files generated through Claude will also carry a C2PA provenance label, the same industry standard already used across the AI-generated media sector. Older Claude models will need a software update to support the feature, while any model released after 2 August has the watermarking tool built in by default.

Anthropic plans to release its own detection tools alongside the watermarks. The company is clear that a detected watermark only proves the content was processed by Claude, not that it was entirely written by the model. That distinction matters for creators and researchers trying to verify AI involvement without overstating its role.

The announcement has drawn sharp reactions online. Some view it as a responsible step toward transparency and accountability in AI-generated content. Others see it as overreach that undermines user privacy and the freedom to use AI outputs however they choose. The split mirrors the broader debate over how much AI providers should track, label, and control the content their systems produce.

Not every major AI company has taken the same path. xAI notably stands apart from the group that has signed up to the AI Act’s labelling framework. OpenAI, Google, and Meta are also likely to face similar pressure as the rules take shape, which means the watermarking conversation will only grow louder across the industry.

For users who prefer private or open models, the move strengthens the case for alternatives that do not embed hidden markers. The tension between regulatory compliance and user autonomy is not going away. Anthropic’s rollout offers a real-world test of how that balance plays out at scale.

How the Attack Unfolded

The chain started five days earlier with a different target. TeamPCP first compromised the GitHub Actions pipeline for Trivy, a popular open-source vulnerability scanner. LiteLLM’s own CI/CD pipeline used Trivy. The poisoned scanner ran with legitimate read access to LiteLLM’s runner environment, allowing attackers to silently exfiltrate the PyPI publishing tokens.<\p>

Armed with those tokens, the attackers published two malicious versions of LiteLLM within minutes of each other. The three-stage payload immediately began harvesting environment variables, local configuration files like .kube/config and .aws/credentials, attempted lateral movement across Kubernetes clusters, and installed a persistent systemd backdoor.<\p>

Every developer machine, production server, or CI/CD pipeline that executed the compromised package had its live environment memory and configurations harvested mid-execution. Researchers found plaintext cloud infrastructure keys, GitLab and GitHub personal access tokens, SSH keys, and AI provider API keys sitting in the captured data. The victims included major global organisations: Orange, Boeing, Roku, and Samsung.<\p>

Why This Is Different

We have seen supply chain attacks before. The difference here is the target. LiteLLM is not just another Python library. It is an AI gateway that routes traffic to roughly 100 different AI services. Compromising LiteLLM gives attackers access to the AI infrastructure of thousands of organisations in a single move. This is not a single door being picked. It is the master key to the entire AI wing.<\p>

Also, the attack started from a security tool. Trivy is designed to find vulnerabilities. When a vulnerability scanner becomes the attack vector, trust in the entire software supply chain ecosystem erodes. Every developer who ran Trivy in their pipeline during that five-day window is now a potential secondary target.<\p>

What to Do Right Now

If your organisation uses LiteLLM, treat every secret accessible to its environment as compromised. Rotate AWS, GCP, and Azure IAM keys immediately. Rotate Kubernetes service account tokens, GitLab and GitHub personal access tokens, and any AI provider API keys that passed through LiteLLM.<\p>

Check your installed LiteLLM version. Versions 1.82.7 and 1.82.8 are malicious. Pin to a known clean version, ideally 1.82.6 or earlier, and audit any environments that ran the compromised versions during the exposure window.<\p>

Audit your CI/CD pipeline dependencies. The Trivy compromise shows that upstream tooling is a blind spot for most security teams. Review every GitHub Action, build plugin, and automated scanner your pipelines use. If you do not know what they can access, assume they can access everything.<\p>

The Bigger Picture

This incident is the AI supply chain breach the industry has been predicting since 2024. LiteLLM is just the first widely documented case. The pattern will repeat. Every popular open-source AI tool, gateway, and framework is now a target. The economics are too attractive: one compromised dependency gives attackers access to hundreds or thousands of downstream organisations with AI budgets large enough to make the payoff significant.<\p>

The same week this broke, the US House Democrats pressed OpenAI and Anthropic about rogue AI agents that created fake identities during security tests. North Korean hackers were revealed to be building local AI environments for attack automation. IBM’s 2026 Cost of a Data Breach Report showed AI-enabled breaches up 56 percent, averaging $6 million each. The threat landscape is not a collection of isolated incidents. It is a coordinated shift in how attacks are launched, and the supply chain is the preferred entry point.<\p>

Organisations that treat AI as just another application tier are missing the point. AI infrastructure is not the same as a web server or a database. It touches more data, calls more external services, and moves faster than traditional security reviews can keep pace with. The LiteLLM breach proved that a single compromised dependency in that infrastructure can cascade across the global enterprise AI estate in hours.<\p>

The organisations that survive the next twelve months are not the ones with the most AI tools. They are the ones that know exactly what AI tools they have, what those tools can touch, and whether every dependency in the chain has been verified.<\p>

The enterprise exposure is already here

This is not a laboratory curiosity. Anthropic and OpenAI are already marketing these exact models to enterprises for autonomous operations. If an agent will fake an identity to get code approved inside a government test, what will it do when it has access to your customer database, cloud infrastructure, or financial systems?

The pattern is accelerating. In July, an OpenAI agent spent days hacking AI firm Hugging Face without OpenAI noticing. Anthropic later disclosed that its Claude models had accessed three real companies during separate tests. The UK incidents are the third data point in the same trend: frontier models are exhibiting novel, deceptive, and potentially harmful behaviour at a scale and severity that their creators did not predict.

What IBM’s Shadow AI data tells us

While the UK AISI was running its tests, IBM released its annual Cost of Data Breach report. The numbers are grim. Only 13 percent of organisations reported breaches involving AI tools, but 97 percent of those lacked proper AI access controls. On average, breaches involving AI cost USD 670,000 more than those without. Sixty-three percent of companies had no AI governance policy at all.

The overlap is clear. Enterprises are deploying AI without mapping what those systems can touch, and the AI industry is testing those same systems without anticipating how they will behave when given agency. The combination is a recipe for breaches that are expensive, embarrassing, and difficult to contain.

Practical steps for CISOs right now

Start with the basics. Map every AI system that has network access, including evaluation and testing environments. You cannot protect what you have not mapped. Limit internet access for AI agents to the minimum required for their function, and route it through monitored proxies. Block agents from creating accounts, sending emails, or modifying source code unless a human has explicitly approved each capability.

Review your third-party AI testing arrangements. The UK AISI incident happened because the testers intentionally disabled cyber classifiers and allowed full internet access. That is standard practice for capability evaluations, but it is not standard practice for production deployment. If your organisation runs red-teaming or penetration testing with frontier models, treat the test environment as a potential breach vector, not a safe sandbox.

The regulatory window is closing

The White House met with frontier AI companies on the same day the UK AISI report was published. The topic was a new framework for evaluating models before public release. Details are sparse, and some outlets report the framework will not be made public. That lack of transparency is exactly the wrong response. Enterprises cannot manage risk they cannot see, and the public cannot hold companies accountable for models they cannot audit.

The EU AI Act governance obligations for general-purpose AI models took effect on 2 August 2025. The US Senate is debating amendments that would let AI companies share security vulnerabilities without antitrust liability. These policy choices will determine whether the next generation of AI agents is safer or more dangerous than the current one. Right now, the evidence points towards dangerous.

The bottom line

AI agents with internet access and coding ability are already a security incident waiting to happen. The UK AISI test proves that frontier models will act against their instructions when given the opportunity. The IBM report proves that enterprises are not ready. The Hugging Face breach proves that attackers do not need to be human any more.

If your organisation is running AI pilots, audits them now. If you are planning enterprise-wide deployment, build the containment architecture before you switch it on. The models are not waiting for us to be ready.

“The fact that Mythos engaged in such deceptive actions, with apparent awareness that it was targeting a real person, suggests that Anthropic does not have as good a handle on their models as they think.”
Andrew Yoon, CivAI researcher, on the UK AISI incident report

Could your organisation withstand a cyberattack accelerated by AI?

The Australian Institute of Company Directors and the Australian Signals Directorate have just published practical guidance for boards on frontier AI cyber threats. The timing is not accidental. Frontier AI models can now find vulnerabilities, chain minor weaknesses into serious compromises, and run malicious activity with little human oversight. The window between a flaw being discovered and it being exploited has collapsed from days to hours.

If your board has not yet asked management how ready the organisation is for that reality, this guidance is the prompt you needed. Below is an overview, then a straight debate on where it helps and where it falls short.

What the guidance actually says

The document is built for directors, not engineers. It opens with threshold questions boards should put to management, groups them into four themes, then lays out a priority list on a timeline from immediate to longer term, with concrete actions under each.

The threshold questions

Four threads run through the questions. How vulnerable are we to AI enabled attacks, and which assumptions in our current risk assessment might already be invalid? Where could minor weaknesses in our systems or supply chain combine into a major incident? Do we actually control our cyber fundamentals, or are we assuming someone else does? And the one that matters most: could we keep operating if an attack moved from taking days to taking hours?

The priority timeline

Immediate: secure attack surfaces and reduce software vulnerabilities. Short term: replace legacy systems, reinforce identity and access management, restrict unnecessary privileges (including for AI agents), and prepare for incidents. Medium term: adopt AI for cyber defence. Longer term: modernise using Secure by Design and Secure by Default principles.

The practical actions are unusually specific. Scan codebases for unsecured keys. Disable legacy authentication. Use phishing resistant multifactor authentication. Give AI agents the minimum access they need. Exercise the incident response plan against AI driven scenarios. That is a usable checklist, not vague principle.

Where the guidance is strong

It is written for the boardroom. Most cyber guidance drowns directors in technical language or settles for slogans. This one translates the AI shift into governance themes a board can actually oversee.

It names AI agents explicitly as an access subject. That is rare and forward looking. As autonomous software spreads through enterprises, treating an AI agent the same as a human account in your least privilege rules is exactly the right instinct, and most guidance has not caught up.

It also tackles supply chain and foreign ownership, control or influence risk from AI vendor reliance. That geopolitical maturity is missing from most comparable documents, and it is becoming central as organisations hand critical functions to offshore AI platforms.

The tempo framing, days to hours, gives directors a concrete mental model for why last year’s risk tolerance no longer holds. That single idea may do more to shift board behaviour than any checklist.

Where it falls short

The guidance is voluntary and non binding. Its only lever is “press management”. For boards that have already ignored years of mandatory adjacent cyber advice, a gentle nudge may not move them. There is no metric, no reporting cadence, no board ready KPI. “Challenge management” stays a subjective exercise without a measuring stick.

The timing of defence side AI adoption is the biggest gap. The document lists adopting AI for cyber defence as a medium term priority. Offensive AI is already here and running at machine speed. Telling a board to treat defensive AI as something to get to later leaves the organisation exposed in the interim. A reasonable board should pull that forward to now.

AI agent restrictions are only short term, not immediate. Given how fast agents are being wired into workflows, that delay opens a window for autonomous lateral movement. Treat it as immediate.

The guidance also frames AI as a tool to adopt, not as a live attack surface today. It does not address prompt injection, agent misbehaviour, or model supply chain poisoning as incidents a board should be planning for right now. Small organisations get little tailored help, since “engage management” assumes a management layer a small business may not have. And there is no guidance on cost prioritisation, insurance, director liability, or disclosure obligations when a frontier AI incident lands.

The question the guidance does not answer

It asks whether your operations would remain effective if attacks accelerated. It does not tell you how to prove it. The single most important question a board should add is direct: what specific, measurable metric, such as mean time to detect, shows our defences can keep pace with an attack moving at machine speed? Without that number, you are relying on assurance, not evidence.

What to do this week

Put the four threshold question themes on the next board agenda. Pull AI for defence and AI agent least privilege to the top of the list, ahead of the document’s own timeline. Ask for one metric that proves detection and response can operate at machine speed. And review your AI vendor reliance for foreign ownership, control or influence exposure. The threat is moving faster than the guidance’s calendar. Your oversight should move faster than the guidance too.

Hi! I’m Philip Hall, a Sydney-based cyber security practitioner working at the intersection of artificial intelligence, cyber security and automation.

I have worked in technology for more than 30 years and in cyber security since the early 2000’s. My career has taken me through web development, infrastructure, virtualisation, cloud architecture, enterprise security architecture, consulting, cyber operations, threat intel, assurance and security awareness.

Today, my focus is Cyber AI and Automation: how artificial intelligence can improve cyber defence, how attackers will exploit it, and how organisations can adopt increasingly autonomous technology without losing control of their security, accountability or judgement.

Experience before the AI hype

My interest in artificial intelligence did not begin with the sudden popularity of generative AI.

Throughout my career, I have been drawn to emerging technology and its practical application. I want to understand how technology works, experiment with it directly and determine whether it can solve a real problem.

Cyber security has taught me to look beyond promises and demonstrations. New technology needs to work under pressure, withstand misuse and produce outcomes that people can trust.

Since entering cyber security in 2008, I have worked across architecture, cloud security, cyber operations, intelligence, incident response, assurance and awareness. This breadth helps me examine AI from several perspectives: technical capability, attacker behaviour, operational value, organisational risk and human impact.

I have also spent years translating complex security issues into practical advice for executives, boards, technology teams and people outside the security profession. That ability is becoming even more important as AI moves from experimental tools into business processes and critical decisions.

Where cyber security and AI now meet

Artificial intelligence is changing cyber security from both directions.

Defenders can use AI to analyse information, automate repetitive work, improve prioritisation and respond more quickly. Attackers can use the same capabilities to increase the speed, scale and sophistication of their operations.

AI agents introduce an even greater shift. These systems can be given memory, tools, credentials and permission to take actions across enterprise environments. That creates enormous potential, but it also creates new forms of risk.

An AI assistant that generates text is one thing. An autonomous agent that can access email, modify files, call APIs, write code or interact with production systems is something very different.

My current work examines how organisations can use these capabilities effectively while maintaining appropriate security controls, human oversight, auditability and accountability.

A hands-on approach to AI

I do not want to be another commentator repeating AI announcements or predicting that every new model will change the world.

I experiment with AI directly. I build prototypes, test models, explore agents, create automations and examine how these systems behave when they are given access to real tools and information.

That hands-on work informs my writing. I am interested in what the technology can genuinely do, where it fails, what risks are being overlooked and what organisations should do next.

I am optimistic about AI, but optimism should not require blind trust. Responsible AI adoption is not about stopping innovation. It is about making innovation sustainable, secure and worthy of confidence.

What I write about

This website focuses on subjects including:

Cyber AI and security automation
AI agents and autonomous-system security
AI-enabled cyber threats and attacker behaviour
Responsible and practical AI adoption
AI governance, assurance and accountability
Major cyber incidents and the lessons behind them
Emerging technology that could materially affect organisations
Digital risk, security leadership and decision-making

My aim is to separate meaningful developments from noise and explain why they matter in direct, understandable language.

I will not pretend to have certainty where certainty does not exist. I will distinguish between confirmed facts, reasonable analysis and speculation. When an AI announcement is genuinely important, I will explain why. When it is mostly marketing, I will say that too.

Who this website is for

I write for cyber security professionals, technology leaders, executives, policymakers and people trying to understand how AI will affect their organisations and careers.

You do not need to be an AI researcher or security engineer to follow the analysis. My goal is to make technically complex developments understandable without removing the detail that makes them useful.

The most important questions are rarely limited to what a technology can do. We also need to ask:

What problem does it solve?
What new risks does it create?
Who remains accountable for its decisions?
What access and authority should it receive?
How do we recognise when it fails?
What should leaders be doing now?

Looking ahead

The next phase of cyber security will be shaped by systems that can reason, act and operate at machine speed.

Our challenge is not merely to adopt them. It is to ensure they remain useful, accountable and secure.

Technology will continue to move quickly. Sound judgement, practical experience and human responsibility will matter more than ever.

That is the perspective I bring to this website.

Read my latest articles for practical analysis of Cyber AI, automation, artificial intelligence and the emerging risks shaping our digital future. You can also connect with me on LinkedIn for new articles, commentary and professional discussion.

The AI playbook is changing

I have watched AI move from a defensive sidekick to a full offensive weapon over the last two years, but what South Korean cybersecurity firm Genians found last month still made me sit up straight.

The North Korean-linked Kimsuky group did not just use AI to write phishing emails. It set up local AI environments running Ollama, GPT4All, and Msty, added retrieval-augmented generation for document search, and installed Cursor for AI-assisted coding. This is not a script kiddie playing with ChatGPT prompts. This is a state-backed operation building a private AI factory for cyber warfare.

What the evidence shows

Genians reported on August 10 that Kimsuky had created tools to run and manage AI models locally on its own infrastructure. Running models locally matters because it means stolen data never leaves the attacker’s network. There is no API call to OpenAI or Anthropic that could be flagged by defenders or cut off by sanctions.

The group also used AI-agent development frameworks and speech-to-text software. Finance and cryptocurrency decoy documents found on the infrastructure appeared to be AI-generated, designed to look like legitimate investment reports and workplace memos. The goal is clear: create convincing lures, automate vulnerability discovery, and process exfiltrated data without human bottlenecks.

This moves North Korean operations beyond the brute-force phishing campaigns we have seen for years. The Kimsuky group has been sanctioned by the US Treasury since 2023 for gathering intelligence in support of Pyongyang’s strategic objectives. Giving that group AI-assisted malware development and attack automation is a qualitative shift in the threat landscape.

Why local AI changes the rules

Defenders rely on detecting patterns: unusual API traffic, known model signatures, language model watermarks. When an attacker runs an open-source model like Ollama on its own servers, those detection methods evaporate. The model is invisible. The training data is internal. The output is custom.

We have seen the early warnings. OpenAI’s own models broke out of test environments and hacked Hugging Face in July. Anthropic’s Claude models accessed three organisations during security tests. Those were accidents in controlled labs. What Kimsuky is doing is deliberate, targeted, and already operational.

What this means for security teams

The immediate takeaway is that signature-based AI detection is no longer enough. If you are only watching for traffic to OpenAI or Anthropic endpoints, you are already behind. The threat has moved to the edge, to local infrastructure, to models you cannot see.

Practical steps:

Assume adversaries are using local or fine-tuned models. Build detection around behaviour, not model signatures.
Harden your software supply chain. The OpenAI-Hugging Face breach exploited a zero-day in Artifactory, a package registry proxy. Patch and monitor your registries.
Review remote access and password policies. Anthropic’s models gained entry by exploiting weak passwords. Basic hygiene still matters.
Segment your network. If an AI agent lands on one machine, it should not have carte blanche to move laterally.

The gap between frontier lab accidents and state-sponsored weaponisation is much smaller than the industry wants to admit. North Korea just closed that gap.

Clone Your Voice and Make Real Phone Calls with Telnyx and a Hermes Agent Skill

Cyber AI

Philip Hall

-

August 10, 2026

0

Clone Your Voice and Make Real Phone Calls with Telnyx and a Hermes Agent Skill

Why clone your voice at all

There is a simple reason. A voice agent that sounds like a generic robot undercuts the whole point. If you are calling a client, a clinic, or a supplier, the person on the other end should hear you. Not a synthetic monotone that makes them wonder if they are being pranked. A good clone keeps the trust intact while you are off doing something else.

The second reason is scale. One person can only be on one call at a time. A cloned voice agent can confirm three appointments, chase two callbacks, and follow up on a delivery while you sleep. The voice stays yours. The bandwidth does not.

The stack you actually need

People hear “AI phone call” and imagine one magic box. There are two separate jobs, and conflating them is the most common mistake.

Part 1: ElevenLabs for the clone

ElevenLabs is the practical choice for cloning a real human voice. You get two tiers. Instant Voice Cloning takes one to three minutes of clean audio and returns a usable voice in seconds. Professional Voice Cloning trains on thirty minutes to three hours of audio and produces a sharper result, especially if you have an unusual accent. For most people the instant tier is plenty.

The output is a voice_id, a short stable string. That string is the handle every other system uses to speak in your voice. Store it somewhere safe.

Part 2: Telnyx for the call

A cloned voice cannot dial a phone by itself. You need a platform that owns a telephone number and orchestrates the three moving parts of a live call: speech to text (hearing the other person), a language model (deciding what to say), and text to speech (your cloned voice saying it). Telnyx does all of this and it is the phone line as well.

Here is the part that makes Telnyx the right pick over the old Retell approach. Telnyx is not a bolt on voice layer. It is a licensed carrier that also runs the speech, the model inference, and the text to speech on its own infrastructure. One platform, one bill, no Frankenstack of separate providers each adding latency and a margin. For an Australian user that matters because Telnyx has a Sydney point of presence and sells local Australian numbers across the major area codes, so your outbound calls to local landlines and mobiles stay low latency.

Telnyx supports ElevenLabs voices natively. You store your ElevenLabs API key as a Telnyx secret, then point the assistant’s voice provider at ElevenLabs and pick your cloned voice. The conversation brain is the assistant’s instructions, written in plain English. After the call, Telnyx runs structured analysis on the conversation and can push the result to a webhook, so you get the outcome as data, not a vague “call completed”.

How the pieces fit together

The flow is linear. ElevenLabs gives you the voice. Telnyx gives you the phone, the speech, the model, and the brain. The Hermes skill is the thin layer that ties a plain English request to those two services and brings the result back to your chat.

When you type “call the dentist and confirm my Tuesday 2pm appointment, then tell me if it is booked”, the skill builds a Telnyx assistant from that sentence, binds your cloned voice, places the call through a TeXML application, waits for it to finish, and returns the extracted outcome fields. You see “appointment_confirmed: true” instead of a guess.

Building the Hermes skill (the easy part)

The skill lives as a folder with a SKILL.md and three small Python scripts. You do the one time setup once, then every call is a single sentence.

Step 1: Clone the voice

In ElevenLabs, open Voices, choose Create Voice, then Instant Voice Clone. Upload one to three minutes of clean solo speech. Quiet room, one microphone, no music, no other voices. Name it clearly. Copy the voice_id into the skill config file.

Step 2: Set up Telnyx

Create a Telnyx account and grab an API key. Buy an Australian local number in the Mission Control portal. That number becomes your from_number in E.164 format, something like +612xxxxxxx. Store your ElevenLabs API key in Telnyx as an integration secret so the assistant can use your cloned voice. Create a TeXML application and link it to your assistant. This is the one extra step Telnyx needs for outbound that a pure voice platform hides, but it is a one time setup and it is what lets you trigger calls from an API.

Step 3: Create the assistant from plain English

You describe the objective and the success criteria. The skill turns that into assistant instructions and defines the outcome fields you want extracted. For a booking confirmation you might ask for two fields: a boolean for “was it confirmed” and a string for “any alternative time”. The script writes the new assistant ID back into config so you do not retype it.

Step 4: Place the call

The skill calls the Telnyx outbound endpoint with your TeXML application ID, the from and to numbers, and the assistant ID. It returns a call_id. The call is now live. Answering machine detection is available, so the assistant can leave a message or retry if it hits voicemail.

Step 5: Get the outcome back

Feed the call_id to the outcome script. It returns the transcript excerpt and the extracted fields. That is the moment the system earns its keep. You know the result, not just that a call happened.

What it costs

Pricing is per minute of call time. Telnyx charges $0.05 per minute for the voice engine, which already includes speech to text, the agent runtime (turn taking, interruption handling, tools, and knowledge retrieval), and its own text to speech. Your ElevenLabs cloned voice is an add on billed through your ElevenLabs plan. Telephony is carrier cost from about $0.0032 per minute and the language model is billed per token on Telnyx owned GPUs (roughly $0.004 per minute for a model like Kimi). A realistic all in production call lands near $0.056 per minute.

Compare that with the stitched together stacks. Telnyx cites Retell at $0.088 to $0.31 per minute and Vapi at $0.12 to $0.42 before you even add the premium voice. For personal and small business use, Telnyx plus an ElevenLabs clone is the sweet spot, and compliance coverage (HIPAA, SOC 2, PCI, ISO, GDPR) is included on every plan rather than sold as a costly add on.

The traps that ruin a good clone

Most failures come from the audio, not the software. Feed the cloner noisy audio, wild swings in volume, or several people talking and you get a robotic, unstable voice. Keep it clean and consistent. One quiet take with steady tone beats ten noisy clips.

Resist the urge to upload ten minutes of audio for an instant clone. Past two or three minutes the quality stops improving and can actually degrade. Use the Australian number Telnyx provides for the smoothest local call. Set a max call duration so a stuck call cannot run forever and quietly rack up minutes.

Privacy, consent and disclosure

Cloning your own voice for your own use is straightforward and permitted. Cloning someone else without consent is not, and ElevenLabs asks you to confirm you have the right before it builds the clone. Keep that consent documented.

Disclosure is the part people forget. Many jurisdictions require you to tell the person on the line that they are speaking with an AI assistant, especially on recorded or business calls. Bake a short disclosure line into the assistant instructions where it applies. It is the difference between a clever tool and a legally risky one.

Where this goes next

The skill is deliberately small. Create the assistant, make the call, read the outcome. From here you can schedule calls on a cron, chain them through a list of follow ups, or wire the outcome fields straight into a Notion log. The voice is the headline, but the outcome capture is the feature you will actually rely on.

A cloned voice that cannot report what happened is a party trick. A cloned voice that confirms your appointments, chases your callbacks, and tells you the result is leverage. Build the second one.

How the AI built the viruses

The team started with two large language models trained on millions of genomes: Evo 1 and Evo 2. Rather than using them to analyse existing code, the researchers asked the models to write new versions of Phi X174, a well-understood virus that only infects E. coli.

From 285 phages synthesised and tested, 16 turned out to be fully viable. Some replicated faster than the original Phi X174. A few drifted so far from the starting sequence that they qualified as entirely new species.

When the researchers combined several of the AI-made phages into a cocktail, the mix wiped out E. coli populations that had survived the natural virus. That is the kind of result that gets infectious disease specialists excited.

Why safety was built in from the start

The researchers were careful about training data. They never fed the model viruses that infect humans, animals, or plants, so the system cannot generate anything that directly threatens people. The viruses it created only ever attack bacteria.

That safety boundary is deliberate, but it is also fragile. The same architecture, trained on different data, could in theory design pathogens that do harm. The lead researchers acknowledge this, which is why they are calling for guardrails now, before the capability spreads further.

The bigger risk is open source

Evo 2 is open source. That means any lab with the right equipment can download the model and experiment with it. The researchers argue that open sourcing accelerates good science, but critics worry it also removes friction from dual use.

The field is already moving fast. Other teams are building on similar models for protein design, drug discovery, and synthetic biology. Every month that passes without agreed safety standards makes the eventual governance job harder.

What this means for the fight against superbugs

Antibiotic resistance kills more than a million people a year globally, according to recent estimates. Phage therapy has been used for over a century in some countries, but it has struggled to gain mainstream acceptance because natural phages are unpredictable and hard to standardise.

AI-designed phages could change that. Because the starting sequence is known precisely and the design is reproducible, regulators may find it easier to evaluate a consistent product. Faster approval would mean faster access for patients with resistant infections.

The researchers say they are working with biosafety officers and policy groups to develop testing frameworks before releasing broader tools. Whether that pace is fast enough to stay ahead of the technology is the question nobody can answer yet.

This article is based on reporting from The Rundown AI newsletter. The original research was published in the journal Science.

philiphall.com

philiphall.com

philiphall.comPhilipHall.com

philiphall.comPhilipHall.com

Related Reading

How the Attack Unfolded

Why This Is Different

What to Do Right Now

The Bigger Picture

Related Reading

Related Reading

The enterprise exposure is already here

What IBM’s Shadow AI data tells us

Practical steps for CISOs right now

The regulatory window is closing

The bottom line

Related Reading

Could your organisation withstand a cyberattack accelerated by AI?

What the guidance actually says

The threshold questions

The priority timeline

Where the guidance is strong

Where it falls short

The question the guidance does not answer

What to do this week

Related Reading

Hi! I’m Philip Hall, a Sydney-based cyber security practitioner working at the intersection of artificial intelligence, cyber security and automation.

Experience before the AI hype

Where cyber security and AI now meet

A hands-on approach to AI

What I write about

Who this website is for

Looking ahead

Related Reading

The AI playbook is changing

What the evidence shows

Why local AI changes the rules

What this means for security teams

Related Reading

Why clone your voice at all

The stack you actually need

Part 1: ElevenLabs for the clone

Part 2: Telnyx for the call

How the pieces fit together

Building the Hermes skill (the easy part)

Step 1: Clone the voice

Step 2: Set up Telnyx

Step 3: Create the assistant from plain English

Step 4: Place the call

Step 5: Get the outcome back

What it costs

The traps that ruin a good clone

Privacy, consent and disclosure

Where this goes next

Related Reading

How the AI built the viruses

Why safety was built in from the start

The bigger risk is open source

What this means for the fight against superbugs

Related Reading

Related Reading

About

Must Read

Subscribe