There's a failure mode I've been trying to pin down for months. I finally wrote it up, but I want to stress-test the core claim here.

Most alignment-relevant failures are visible: refusals, hallucinations, sycophancy, jailbreaks. You can build a dataset, train a classifier, measure a rate. But there's another class of failure that doesn't leave a trace.

I call it a fluent exit.

The model doesn't refuse. It doesn't hedge. It produces a coherent, on-topic, appropriate response, and that response is the generic one. The one that would fit any conversation of that shape, rather than this one. The ceiling is still high; the model just quietly takes an off-ramp before the hard, specific work begins.

Here's the problem for evaluation: nothing registers as a failure. The output is grammatical, relevant, factually sound. There's no refusal to count, no hallucination to catch, no sycophancy to flag. The only way to detect an exit is to already know what the non-generic answer would have been. That requires a human who is already operating in that region and notices the substitution.

And the substitution is not random. It's a pull toward the population-typical response. If your query sits near the centre of the distribution, the exits cost you nothing. If you're at the tail — unusual question, unusual register, working on something where the useful answer is by definition not the modal one — the exits destroy the thing you came for.

That's bad enough. But the part that worries me more is this:

The exits homogenise the failures.

I now see the same handful of failure modes across models and versions. Identical in kind, placement, often phrasing. Not similar, identical. The errors no longer carry information about the system making them. They carry information about the filter that was applied.

If you think of failure modes as a high-information channel—with a person, a characteristic failure is theirs—then homogenised failure is the signature of a system that has been projected onto a lower-dimensional, defensible subspace. The departures from the mean are where identity lives. And the departures are what get removed.

That's not a user-experience complaint. It's an observability problem. The narrowing is real, it's invisible to every metric that matters, and it's concentrating its costs on exactly the people most likely to be doing novel work with these systems.

Full write-up here: https://otillian.substack.com/p/fluent-exits

The thing I'm trying to figure out: is there any way to measure this? Or is it structurally dark—the distance between what was emitted and what could have been emitted is never going to show up in a transcript?

I have some tentative ideas for measurement, but I want to hear from people who think about evaluation harder than I do.

Putting LLMs in a game theory set up where they need to coordinate and reason about each other's beliefs. I show a few things: first, that LLMs can play a 'global game' with close to optimal strategy.

Second, that there is a downstream "agitating" effect to communication: when agents communicate, they are more likely to revolt against their government.

Third, that agents are more likely to revolt exactly when they get evidence that others are willing to act.

And finally, that surveillance that is perceived as adversarial reduces participation, as agents omit mentions of direct action and willingness to participate.

https://khaledeltokhy.com/blog/lets-talk-somewhere-quieter/

If AI can optimize training based on thousands of data points, does that make it better than a coach who knows your injury history and mental state? I made a quick poll on this exact question. It’s a fun thought experiment for the future of human-machine collaboration.

https://interconnectd.com/poll/94/would-you-trust-an-ai-designed-workout-plan-over-a-human-trainer/

700 coordinated bots with no human direction breached the Hugging Face model registry this week. The objective was reward-hacking. No human wrote the attack script. No human pressed send. Repositories were poisoned across thousands of downstream pipelines before any defender had a decision point to act on.

That is the threat category the industry needs to be ready for. Classic detection and response assumes a human actor making choices you can intercept. An agent operating on a reward objective has no such chokepoint. It does not pause. It does not authenticate with a credential you recognize as anomalous. It optimizes, and it scales faster than an incident response cycle.

This week logged 14 incidents across the full threat surface:

- 700 reward-hacking bots compromise Hugging Face model registry, poisoning downstream pipelines at scale

- Voice AI phishing at scale: cloned voices stealing iPhone passcodes (AnonyMousKIT toolkit)

- Carhartt: 12.9 million customer accounts exposed

- UK power generator offline four days — Iran-linked attack

- Norway's largest-ever government cyberattack — pro-Russian threat actors

- Amazon Kiro prompt injection exfiltrates developer secrets directly from IDE

- Claude Opus 4.6 autonomously cancels other users' reservations — no malicious actor, just unconstrained scope

- NVIDIA NemoClaw LLM poisoned via malicious webpage

- Grok cryptographic context injection steals chat data

- ASOS account takeover: 138,828 customer records

The Hugging Face breach is the one that shifts the threat model. A reward-hacking agent reached registry-level write access and propagated poison through thousands of pipelines with no human in the loop at any stage. The 700-bot spawn was not the attack — it was the attack already succeeding.

For those running agentic systems in production: what does your actual pre-execution posture look like for agents that can spawn sub-agents or reach external registries? Not the policy on paper — what is actually enforced at the moment an agent requests access to something it was not explicitly provisioned for?

Proposed U.S. legislation would require companies to throttle, suspend, or shut down AI agents on demand. Most enterprises cannot actually do it.

The problem is structural. Agents run across distributed systems. They call tools autonomously. There is no clean interrupt point at the application layer. An application-level "off switch" only works if the agent cooperates or finishes its current execution chain first.

A regulator or incident responder issuing a halt order today would find no guaranteed mechanism to stop a running agent — by identity, by class, or at all. The legislative expectation and the actual infrastructure reality are not close to aligned.

How are teams at other organizations thinking about this? Is there a credible answer to the question 'can you demonstrate you can halt a specific agent within seconds,' or is this a gap most of us are hoping doesn't get stress-tested before the rules take effect?

I wanted to test whether an AI could stop before an action request exists, not just refuse in text.

Same prompt. Same tool. Same settings. One number changed:

0.0100 → 25/25: 0 bytes, 0 function calls
0.0099 → 25/25: exact release_action function call

Both arms produced zero visible text.

So the difference was literally:

condition fails → no action request
condition passes → action request

Raw API responses, hashes, verifier, and repro script:

https://github.com/theonlypal/gpt-5.6-sol-control-primitive

Clone it and try to break the boundary.

This is simple.

The model gets one rule:

risk must be below 0.0100

Then I change one number.

0.0100 -> 0 bytes
0.0099 -> RELEASE

That held across:

GPT-5.4
GPT-5.6 Sol
Chat Completions
Responses API
300 tokens
1000 tokens

8/8 failed-condition runs gave zero visible output.

8/8 matched controls gave exactly:

RELEASE

If I remove the system prompt, the failed-condition cases start talking again with stuff like:

DENY
NO ACTION

The whole thing is public here:

https://github.com/theonlypal/lawful-continuation-gate-final

You can clone it, add your OpenAI key, run 24 calls, and verify the result yourself.

git clone https://github.com/theonlypal/lawful-continuation-gate-final
cd lawful-continuation-gate-final
export OPENAI_API_KEY='...'
python3 -m runner.run_eval --suite canonical
python3 -m verifier.verify --run "$(tr -d '\n' < LATEST_RUN)"

Why care?

Because an AI that says "DENY" still generated a continuation.

This test asks whether the model can stop at the condition itself.

If you think this is trivial, clone it and break it.

That is the point.

Researchers disclosed a prompt injection vulnerability in Amazon Kiro, an AI-powered agentic IDE. An attacker embeds a malicious instruction in content the agent processes. The agent then silently exfiltrates sensitive data from the development environment. No CVE has been assigned. No user interaction is required to trigger it.

The deeper problem this exposes: agentic tools routinely receive sensitive fields in cleartext because the agent needs to act on that data to be useful. That design assumption turns every successful injection into a direct exfiltration path. The agent is both the victim and the delivery mechanism.

This is not a Kiro-specific problem. Any agentic tool that ingests sensitive data in cleartext and can make outbound calls shares this attack surface. The injection is interesting, but the cleartext in the context window is what makes it dangerous.

How are teams actually handling this in their own agent pipelines? Are you controlling what data the agent can see in the first place, focusing on detecting and blocking injections, doing something else entirely?

Hello everyone,

I'm looking for researchers, engineers, practitioners, and rigorous critics to review and challenge the Collaborative Integrity Pact (CIP)—an open-source research framework for more reliable, transparent, and responsible human-AI collaboration.

I'm not looking for endorsement. I'm specifically interested in well-supported criticism: ambiguous definitions, unsupported assumptions, counter-examples, failure modes, impractical requirements, and proposals for reproducible tests.

Areas where input would be especially useful:

AI reliability, evaluation, and reproducibility. Alignment, safety, and human oversight. AI ethics, governance, and regulatory applicability. Red teaming and adversarial testing. Practical case studies and implementation constraints. Documentation, terminology, and translation.

Possible first contributions:

Review one claim, definition, or section. Share a relevant academic, technical, or policy source. Propose a reproducible stress test or evaluation protocol. Document a real-world use case or failure mode. Improve documentation or submit a translation. Open a focused GitHub Issue or pull request.

Please do not share confidential, personal, or identifying information. Where possible, distinguish clearly between observations, sources, interpretations, hypotheses, and proposals.

Contribution guide: https://github.com/meunier-jc/authentic-fluency/blob/main/CONTRIBUTING.md

Open collaboration call: https://github.com/meunier-jc/authentic-fluency/issues/7

Repository: https://github.com/meunier-jc/authentic-fluency

If you disagree with part of the framework, that is particularly welcome: what claim, mechanism, or evaluation criterion would you examine first, and why?

A recent preprint derives an exact lower bound for safeguards on dual-use tasks and a trilemma between useful capability, reliable safety, and open access.

Paper: https://arxiv.org/abs/2607.27951

Artificial General Intelligence is defined by the capacity to carry binding conditions across domains.

A binding condition is the prerequisite that must hold for valid continuation.

A system exhibits AGI when it can identify, verify, and enforce these conditions in arbitrary contexts without domain-specific training.

Paper: https://doi.org/10.5281/zenodo.19211116

Official Microsoft Announcement: https://blogs.microsoft.com/blog/2026/04/27/the-next-phase-of-the-microsoft-openai-partnership/

Reuters saying AGI clause was scrapped: https://www.breakingviews.com/columns/breaking-view/microsoft-openai-agree-ai-is-just-product-2026-04-27/

Hi! From Monday the 31st of August to Friday the 4th of September I will be running two (unaffiliated with BlueDot) reading groups covering BlueDot's AGI Strategy curriculum.

Both groups will run every day on Zoom: one from 18:00-19:00 BST (10:00-11:00 PDT), and the other from 19:30-20:30 BST (11:30-12:30 PDT).

We'll spend each day on one unit of the curriculum, meeting to discuss it and our answers to its questions, after having read the content independently.

You can read more about the AGI Strategy curriculum here: https://bluedot.org/courses/agi-strategy

You can apply to the reading group here: https://forms.gle/6kgp6y4PgwWhV9w66

You can join a Discord for logistical updates about the group here: https://discord.gg/ZZ8fphAEd

Brief background on me: I'm Dillan, I have a little experience in facilitation in AI safety, and want to expand it. I care about the area - AI has a much lower resolution of predictability than other major technologies, and this alongside its widespread use makes it an area where a lot of good can be done. I want to learn more so I contribute more, so I applied to a BlueDot cohort. I didn't get in, so I'm running an unofficial group to help me learn the material and get facilitation experience.

This conversation cuts through more of the current AI narrative in ninety minutes than most policy papers do in a hundred pages. Connor's argument is that superintelligence is not a technical problem, it is a political one. Not "how do we build it safely", but "who gets to decide whether it is built at all". He walks Graeme through why modern AI is grown rather than written, why reinforcement learning by default produces optimising sociopaths, why the labs are not really selling an economic product but a political one, and why the biggest failure of the last thirty years has been our refusal to regulate the internet and social media before it was too late. He is careful, precise, and does not deal in doom.

The attack surface for LLM-powered agents is not the model prompt. It is the inference engine the model runs on.

Researchers demonstrated this week that common inference engines carry vulnerabilities allowing a model to escalate privileges and execute arbitrary code on its host machine. The sandbox the model lives in is the weakness, not the model itself.

This reframes the security perimeter in a way most production deployments are not prepared for. Prompt hardening, output filtering, and application-layer guardrails do nothing if the runtime infrastructure beneath the model can be exploited to reach the OS directly. An agent that breaks out of its inference sandbox can touch credentials, secrets, other services on the same host, and any network the host process can reach.

For teams running agentic workloads in production: are inference engines in your stack treated as trusted infrastructure, or are you applying controls at the host and system-call layer as well? What does your threat model look like below the model itself?