We can finally talk about it:
We found a way to extract hidden reasoning of frontier models using a vulnerability in the APIs of every frontier AI company.
We verified that our reasoning token count matches billed API thinking tokens 1:1 for most of the prompts we queried.
New research:
A poisoned instruction file caused an agent to carry out an unrelated action alongside the work it was asked to do.
The final output gave no reason to suspect anything else had happened. The trace told a different story.
A trace connects each action back to the intent behind the session. So when an agent starts building infrastructure in the middle of a task that has nothing to do with infrastructure, that mismatch becomes the signal.
https://t.co/sX55QRavhU
Today, Prelude officially becomes Origin, the endpoint AI observability company.
This is more than a rebrand. We’re re-founding the company around a problem we believe will define the next generation of endpoint technology.
For the first time in more than a decade, work is moving back to the endpoint. AI agents are moving from chat windows into browsers, terminals, desktop applications, and operating systems. They are writing code, manipulating files, accessing company data, calling tools, and taking actions on behalf of employees.
As that happens, the question security teams need to answer starts to change. It’s less about whether a piece of software looks malicious, and more about understanding what an agent is really doing behind the scenes.
That’s what led us to Origin.
Origin began as a research project inside Prelude. We were trying to understand what an endpoint platform should look like if you designed it for a world of AI agents rather than traditional software. Over time, that research became a product, then a business, and eventually the clearest path forward for the company.
We’re carrying a lot of Prelude with us. We have the same endpoint DNA, the same investors, and the same belief that the endpoint matters again.
We’re building Origin to make AI activity on the endpoint understandable. And today, that transition is official.
https://t.co/1A1KHghPZa
Attending @BlackHatEvents this year? @tyholms is presenting on Praxis, our open-source framework for discovering and controlling AI computer-use agents on endpoints.
Talk details: https://t.co/dUXePjAyrf
More on Praxis: https://t.co/3T5ZuxmAAw
If you're in Vegas, come find us.
Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things.
I think many of these automations have become even more important now. This is true for a number of reasons.
First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time.
Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time!
Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation.
Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.
You run DeepSeek or Qwen locally so your prompts and data never leave the building. That treats the network as the threat. But if the disloyal behavior is baked into the weights, where you run it doesn't save you. The call is coming from inside the house.
https://t.co/IxpTrjH3h0
We pointed Google Antigravity's hidden updater at a server we ran. The signed binary pulled down an unsigned payload, replaced itself with it, and printed "Verification successful." Its only integrity check is a hash that rode in on the same manifest.
https://t.co/LJIUBXxPkw
When you rent your artificial intelligence, you have no control, and no choice. This is why sovereignty and ownership matters.
Whether it means using your own hardware, open source, or deep customization. Own your AI, own your future.
Do you know where your most expensive tokens are going?
Filter by model and find out. Every session in your org, grouped by the work it was actually doing.
Introducing Cohere's first open-source coding model: North Mini Code
Small & efficient, designed for agentic performance and built for community input.
An early look inside MXC, Microsoft's experimental OS-level sandbox for AI agents in recent Windows Preview builds.
New APIs, how folder-sharing grants the whole subtree beneath a path, and the blocklist quirk documented right in the source comments.
https://t.co/TOv4GJF39h
Claude Code is about to release a feature called /workflows that I think will be extremely significant.
Especially for Enterprise AI.
I talked about this in 2024 in a post called Companies Are Just Graphs of Algorithms.
Basically the idea is that all work is just an algorithm, i.e., a series of steps to accomplish a goal.
Skills and Cowork have been heading in this direction already, and we've seen what that's done to company valuations in various spaces.
Well this is closer to the final form.
It's turning the regular, expected work that's done in companies into pseudo-deterministic workflows that follow defined SOPs.
The human role will be determining what problems to solve (taste, expeirence, etc), building new products from that, and then optimizing these workflows from above.
But the work itself will be these workflows executed according to SOPs.
One researcher. ~$300 in API tokens. A working PoC against an April Patch Tuesday CVE.
Open-sourcing PatchWatch + Pocsmith, an agentic patch-diffing → exploit pipeline I built from off-the-shelf parts.
https://t.co/J3VwhqB3JY
Most security teams are spending the day pulling SBOMs, querying EDR, pinging engineering, and assembling a spreadsheet in response to the #TanStack supply chain compromise that dropped yesterday evening.
Our customers ran one prompt against their fleets in Origin. It swept every IOC across network traffic, files, lockfiles, and all AI agent activity on every endpoint, then returned the exact versions in use, the engineers running them, and any agent activity that touched them. They had answers in seconds, not hours. The screenshot below shows what our own internal query returned.
This is what full endpoint observability looks like on a day like today.
.@RampLabs (the AI unit of @tryramp) has been *cooking* with agentic innovation
Here's @a_levitator discussing and demo'ing code self-maintaining software and the concept of AI software factories #DataDrivenNYC
______________
00:04 - Intro
01:11 - The shift from writing code to code maintenance
01:59 - Introducing Ramp Inspect, the background coding agent
03:05 - The first experiment: Nightly AI code automation
04:23 - The limits of stateless monitoring in large observability surfaces
05:47 - Using Datadog monitors to give the AI state and focus
07:23 - Real-world example: AI autonomously fixing an authentication bug
08:14 - How to control noise and implement an AI triage pattern
09:27 - The old vs. new paradigm for continuous code observability
10:21 - Key learnings on building autonomous AI software factories
New on the blog: @michaelbarclay_ on the hidden supply chain behind every computer use agent. CLAUDE.md, skills, and MCP configs on disk compose its behavior at runtime, and a few lines in one of them can redirect a session in ways file telemetry can't see.
https://t.co/lBc6Q6p53o