Hacker Noon - Medium The Slop Should Not Be Tolerated
TL;DR: Coding agents decide they're done by asking a model whether they're done. That's not a quality check, that's a vibe. Here's what happens when you make the exit condition a command and why the agent has to be locked out of changing it.



A harness is easy; the rest is not

No, a markdown won't fix it

Merriam-Webster crowned "slop" as its ‘2025 Word of the Year’, which captures the collective exhaustion with low-quality content mass-produced by AI. Both big AI labs shipped a `loop` this year: Codex has /goal , and Claude Code has /goal and /loop. If your harness is "run the agent again," you're playing table stakes because the loop was never the hard part - the challenge is at the end when something has to tell an agent 'stop' or 'continue,' and then a human has to stamp it.


Short version: you hand an agent a prompt, it does work, it commits. Repeat. Sometimes you use a database as a memory, sometimes the code is the memory, sometimes you have a web of agents working at the same time. It's so simple and it just functions. The catch is the exit condition, where something or someone has to decide when an iteration is finished and that the code is 'good enough'. And that's why harness engineering is becoming its own field and AI slop has Xfka Twitter all abuzz.



Model-graded “done” is not done

Here's how a loop knows you're finished: an agent model looks at the work and grades it. The thing that wrote the code decides the code is good. You know how this goes:
"✅ All tests passing! Feature complete! Test coverage is 100%”...

But take a peek. Every test-covered line runs under a test that asserts... nothing. There's also a # type: ignore where the types were being too fussy for the agent to deal with, and now a # noqa where the linter complained. Anthropic has names for this in their own failure list: premature victory declaration, fake-done features. Run the same agent review three times, get three answers. Anthropic describes familiar failures in its engineering write-up on long-running agents.

An agent sees existing progress and concludes that the project was complete. Then other sessions attempted too much and left unfinished work behind. So Anthropic gave the agent a feature checklist and a progress log so each new session could see what still needed work. But a checklist is useful only if you can test the items on it; otherwise, it's a wishlist.

“Supports CSV” is not a spec; it's a wish. Can the code handle a comma inside a quoted field? Does a bad row produce an error without saving half the file? Those are things you can run and check before marking the feature done, and the agent saying “CSV support implemented” is the agent grading its own homework.



That's not a stopgap. That's a vibe


Calling a feature done too early matters even more when the next iteration builds on it. That's how unfinished work becomes a codebase full of AI slop, low-quality generated code dressed up as finished work, runs, passes tests, and is still full of duplicated logic, hidden failures, abstractions, and spaghetti that make a simple change viscerally painful to look at. You ask for another field on a form and discover an added fa[...]

ctory, two adapters, three fixtures, a helper, and a meeting with whoever named AbstractFieldOrchestrator. Nobody signed off on that name, and it just showed up one night and got tenure. And that code lingers on as memory where each agent iteration builds on previous decisions and yesterday's shortcut becomes today's architecture. One copied block becomes five, an exception gets swallowed because it's the happy path (yay!), and by the time you review the whole thing, the diff is large enough that “well, the tests pass” starts sounding like a good basis for a career decision. Something smells.






Researchers are starting to measure AI slop. The May 2026 revision of SlopCodeBench evaluated 15 coding agents on 36 problems and 196 checkpoints. Agents had to keep extending their own code as requirements changed and across those runs about 3 out of 4 packed more complexity into already complicated functions, accumulated redundant code, and overall just got messier. Telling the agents to prioritize quality improved their starting code but it didn't stop deterioration.



The benchmark doesn't prove every loop makes code worse or that some harness fixes it. It shows why 'it works' is only part of the story because the code has to survive the next feature request. I'd rather discover the mess while the diff still fits in my head. In “An Endless Stream of AI Slop,” researchers analyzed 1,154 posts across 15 Reddit and Hacker News threads about AI slop and found recurring complaints that time saved generating code becomes extra work for reviewers and maintainers, which is a lovely productivity gain if you don’t count your coworkers or <underlineyour future self.


And humans aren't especially reliable judges of progress either. InMETR's early-2025 randomized study 16 experienced open-source developers tackled 246 tasks in repositories they knew well. With AI tools allowed, they took 19% longer on average. Afterward, they still estimated that AI had made them about 20% faster. Apparently you can lose time and enjoy the experience. Finally! A productivity tool with the same business model as scrolling your phone.





In its February 2026 follow-up METR said newer tools likely provided more speedup, although selection effects and measurement problems made the new estimate unreliable. Is that the writing of better code or faster slop? That study measured time, not code quality, so we can't quite answer that question. A harness needs to check what got built as well as how long it took. But you say watching a thousand lines of code arrive is exciting! Code goes brrr... Discovering you only needed forty is less exciting, especially after you've read all thousand. So what to do?

Gate it

Before the next iteration builds on a change, something needs to check whether it actually meets the requirements. You want a loop to come back with evidence. Run a formatter, type checker, regression tests, and whatever security checks make sense for the project... all of it. I don't care how confident a commit message sounds, keep failures visible and feed them into the next attempt.


Let's use coverage [...]

on a CSV parser as an example since a line running under a test doesn't mean the test really checks the result. Call the CSV importer and you've exercised some code with 100% coverage. But check the saved rows and the error message and you've tested behavior. An application's parse_csv that blindly splits on every comma would fail this test and one that returns anythingwon't just get a participation trophy. For a parser that returns a list of dictionaries, an explicit test could look like:



test_comma_inside_company_name():
rows = parse_csv('company,amount\n"ACME, Inc.",12\n')
assert rows == [{"company": "ACME, Inc.", "amount": "12"}]

Then, add mutation testing to test the tests. This goes further by making small changes to the source code and seeing whether the tests even notice or just wave things through like a bored bouncer. **Have you ever had an agent mock basically everything in a test, essentially creating a mirror app? \ And don't even get me started on frontend. How do we deal with a lack of determinism? Deterministic unit tests won't catch visual degradation and an agent can pass every test and ship a blank page, a layout that falls apart on mobile, or a form you can't use with a keyboard. Playwright, a11y, and Lighthouse might catch broken DOMs and layout shifts but none of them can explain why every button looks like it's trying to sell me crypto. Someone still has to open the thing and look at it and agents are NOT at the level to build and test good frontend. For visual regression gates:

* Does the page render and load its production assets?
* Do the controls respond, including when used with a keyboard?
* Does the layout fit mobile screens and meet accessibility standards?
* ....

(As an aside, how will we even begin to test for style? Or taste?)

Once checks decide if an agent in a loop can continue, the checks themselves need protection too! An agent told to make tests pass can delete the assertion that's failing. Green! Same bug survives. I don't want the agent fixing the implementation to also decide which requirements count, so required validation belongs somewhere an agent can't quietly bypass, for example, in CI. Tests can change if and when requirements change and “this assertion was making my job difficult” is not a requirements change, it’s a confession.



You don't have to be a nanny

…and you don’t have to be afraid to look at the code

In a harness, the control flow can stay simple with some `trusted_checks` that live outside an agent's editable workspace:

for each attempt in 5:
agent.work(task)
result = trusted_checks.run()
if result.passed:
agent.commit()
else:
raise

*
Run the required checks after each attempt: If they fail, give the errors back to the agent to fix. The agent saying “done” should NOT count as passing.

*
Make checks mandatory: Run them automatically at set points instead of adding “Please run the tests” in a markdown

*
Keep changes reviewable: Start with one bounded task and enforce diffs small enough to review (research hasn't agreed on one number but hovers around the number ~200 lines of code as "ok" before human eyes glaze over)

*
Check for slop, not just bugs: Run duplication and complexity checks - code can pass every behavior test and still be miserable to maintain

*
Check before merging: Have fast checks that can run while an agent works and have deeper validations that allow a merge
<li[...]

>
Stop the reruns: Set max attempts or time limits to bound runtime and cost instead of paying for another hour of the same wrong attempts politely rephrased

*
Keep the standard independent: In an existing repo start with its tests and conventions and add checks for problems you'd actually encounter (especially end-to-end behavior)

*
Don't trust, do verify: Keep tests and implementation separate and written or reviewed by a different pass than the one that wrote the code

*
Lock the checks out of the workspace: Trusted_checks should live somewhere the agent can't `git` or `mv` its way around, e.g. CI config it has no write access to, otherwise "fix the bug" quietly becomes "fix the test that caught the bug"

*
Fail loudly: Get a plain summary of what's broken (especially if a human has to pick up the thread) instead of re-reading five commits of "attempt 4, trying again"

*
Automate test permutations: Add property tests that vary test inputs in countless ways so you don't have to write huge test files

*
Watch the tests, not just the code: Add and run mutation testing to catch tests that always pass - the software equivalent of a smoke detector with no battery

*
Loop it: If anything changes after checks pass you have to run them again - yesterday’s green check doesn't apply anymore regardless of what code was touched


That's how I'd start to judge a harness. The number of iterations it can survive overnight is just a billing question and if 90% of written lines are garbage (though garbage that does run) you might have a problem. A loop can give you more attempts. That's table stakes.


Making loop attempts <underlineuseful requires a definition of done that survives human contact.


Disclosure: I wrote LoopGate my own harness that runs agents in a loop with configurable quality checks and also attempted a frontend-focused harness which still gives me a migraine

Hacker Noon - Medium A Framework for Conversational System Modeling
Introduction

There is an interesting but criticized theory in linguistics: Grice's Maxims of Conversation. This theory, introduced by British philosopher Paul Grice, attempts to explain how humans converse. That is, it provides a framework for understanding how effective communication between two people takes place.


The basic idea is rather simple: the theory posits that people want to be cooperative when speaking with others. And because they want to be cooperative, they aim to be informative, truthful, relevant, and clear when engaging in human conversation. Putting aside the provability of the theory for the moment, the goal of having an effective conversation is worth exploring in the context of modern AI systems capable of voice interaction.


How do these systems, which include popular consumer variants such as Alexa and Siri, "know" how to converse with human users? We can likely agree that they do not have the objective to be cooperative, at least not in a human sense. So, how do these systems know:



*
When to speak?

*
When to remain silent?

*
When to stop speaking due to being interrupted?

*
When to interrupt and begin speaking?




You've likely already identified one possible answer: voice interaction models can predict conversational events that allow them to effectively simulate human-to-human conversations. In this case, the task then becomes how the prediction problem for conversational speech is modeled and implemented for speech dialogue systems.



This exact challenge was the focus of the recent FinVolution Teach AI When to Speak competition ("the competition"). FinVolution is a Chinese fintech firm founded in 2007 with technologies in credit risk assessment, fraud detection, big data, and artificial intelligence. I participated in the competition and was very impressed by the completeness of the competition setup - the organizers went so far as to provide base training and inference logic. The competition, unsurprisingly, involved Chinese-language conversations. However, the general modeling problem can be adapted to other languages.



My goal with this article is to provide you with an understanding of the problem setup, which you can use as a basis for your own experiments in conversational modeling. The information I provide here is essentially my "wrapper" over the publicly available competition description.



The competition itself closed in July, and the competition assets are proprietary to the organizers. Although I can't provide the training data and baseline training/inference scripts, I aim to give you enough of a conceptual understanding so that you can take the next step of creating your own training dataset(s) and building your own model(s).



Dialogue Modeling



To begin developing a model that can predict events in a conversation, we need to first understand what those events could possibly be. Imagine your own conversations, both in-person and not in person (e.g. over a cellphone). In the case of the former, you might listen and look for clues from the other participant in the conversation. For example:



* Your conversation partner might stop talking, indicating it is your turn to speak.
* Your conversation partner might use filler words, such as "uh huh", "wow", and "oh" (in English), indicating his/her understanding and/or reaction to what you are saying while simultaneously sig[...]

naling that you can continue speaking.
* Your conversation partner might make a physical gesture, such as raising his/her hand up while you are talking, indicating he/she would like to interrupt you so he/she can say something and take their turn with the conversation.


Prosodic characteristics, such as a speaker's rhythm, pitch, and loudness, can provide conversational cues. We could go on and on, even going so far as to extend our set to specific cultural behaviors. The point is that we can identify certain sensory events (audio, visual, etc.) that explicitly and implicitly guide us through a conversation. The wide variety of conversational cues drives a corresponding variety in dialogue system design.

Figure 1 - Turn-Taking in Conversational Systems (Patamia et al., "Turn-Taking Modeling in Conversational Systems: A Review of Recent Advances", MDPI, 2025)





For our purposes here, we will assume that our predictive speech dialogue system only processes audio events - i.e. other sensory cues are not available to be used in prediction. This "limitation" is not fatal given the billions of telephone conversations that occur every year and it allows us to simplify the modeling problem. Moreover, this simplification aligns with FinVolution's conversational model used with the competition:

Figure 2 - Two-Participant Conversation Model (FinVolution, "Teach AI When to Speak Competition", 2026)





The figure depicts the audio waveforms of two participants engaged in a conversation for a short time window. Five distinct conversational events are defined and captured in the time window:

Table 1 - Conversational Events

Event Label

Event Type

Description

Example

C

Continuation

A conversation participant, the "current speaker", is speaking and continues speaking.

The current speaker is articulating an idea.

T

Turn Change

The other conversation participant has now become the current speaker and has started speaking.

The first speaker asks a question, e.g. "How are you today?", and the other person begins speaking to provide an answer.

BC

Backchannel

The conversation participant who is not the current speaker makes a short utterance without a turn change - i.e. without becoming the current speaker.

The conversation participant uses a filler word such "uh huh", "wow", or "oh".

I

Interruption

Both conversation participants are speaking at the same time.

The current speaker is interrupted by the other conversation participant who starts speaking over him/her, possibly attempting to invoke a turn change.

NA

Silence

Neither conversation participant is speaking.

td>
Short windows of silence are common during turn changes.



You can already see the structure of a simple supervised training setup using this event set:



* We can identify occurrences of the 5 events defined above in short sections of two-participant audio conversations.
* We can label those occurrences.
* We can train a classifier to predict event occurrences using the labeled data.

Problem Setup

Prediction Task

We'll discuss the prediction task first as it will make understanding the training data structure and training model easier. Here is a graphical representation of the prediction task setup - bear in mind that the diagram is not drawn to scale from a time perspective:

Figure 3 - Prediction Task (FinVolution, "Teach AI When to Speak Competition", 2026)





Training audio is sliced into non-overlapping 30-second ("s") context windows. Each context window is followed by a 2s prediction window. The training model learns to predict which conversational events, as defined in Table 1 above, occur within each prediction window, given the features within each corresponding context window. Each prediction window is “chunked” as a set of twenty-five 80-millisecond ("ms") audio chunks, and a prediction is made for each individual chunk. In other words, the model outputs a prediction (one of the 5 event labels) for each of the 25 individual chunks, creating an event map of the next two seconds of conversation.

Training Data Structure

Each sample in the training data, which includes 1,000 total samples, is essentially three separate files:

File

Description

audio/<conv_id>.wav

Two-person conversation audio

text/<conv_id>.json

Text transcript of the conversation audio

labels/<conv_id>.npy

Conversational event labels C, T, BC, I, NA applied temporally to the conversation



It should be obvious that this training data structure supports multimodal modeling where audio, text, and label features can be extracted from each context window. This approach shows you how you could structure your own training data for other languages. I'll expand on this topic further in the Conclusion and Your Own Implementation section.



Training Model



We can establish an analogy between the multimodal training data and the multisensory experience of human participants during a conversation. For example, the audio, text, and label data features can be mapped to:



* Listening: How is the speaker speaking - e.g. tone, pauses, etc.?
* Semantic processing: What is the speaker saying? What is the meaning of his/her words?
* Dialogue processing: What is the rhythm of the conversation? For example, what is the pace of turns?




The baseline training model provided by the competition takes advantage of the multimodal nature of the training data to "behave" in a similar way like a human being - it processes the different types of available data - audio, text, and event labels - simult[...]

aneously for a given conversation. It extracts these multimodal features, combines them into a single feature vector, and passes them through a model head that makes the actual predictions. The training model is further characterized by tail-awareness: it pays particular attention to what happened right before an event (e.g. a turn) versus what happened several seconds in the past. If this doesn't make sense to you, consider that the immediate cues for a turn or interruption happen just moments before the actual event. So, assigning more importance to the final seconds of the 30-second context window yields much better predictions than treating the whole 30 seconds equally.




Naturally, the audio, text, and label encoders must be modeled. Many winning competition submissions used Whisper with attention pooling to assign higher weights to the tail of each audio sequence. Another approach, which you are likely already familiar with, converts each audio recording to a mel-spectrogram and then passes each mel-spectrogram through a convolutional neural network ("CNN") for feature extraction. Text encoding can be handled by a pre-trained language model such as BERT. A custom neural network can be designed to process the sequence of event labels in each context window. The competition's baseline model uses a two-branch approach where the first branch processes the entire event sequence and the second branch processes those events in the tail of each context window. The baseline model also employs handcrafted features that are largely derived from a statistical analysis of the events in each context window.



As hinted above, feature vectors are concatenated and then passed to a final multi-layer neural network which makes the actual predictions.



Conclusion and Your Own Implementation

To reiterate, the objective of this article was to provide a conceptual understanding versus actual data and training/implementation scripts. At this point, you hopefully have a solid base from which you can apply the concepts discussed above toward your own experiments in Chinese or other languages.


You can create you own custom datasets that mimic the structure of the competition dataset by starting with an audio dataset and writing custom scripts to transcribe and label the data. For example, there are conversational speech corpora available for many different languages, such as the famousSwitchboard-1 Release 2 corpus for English. WhisperX can be used to transcribe and diarize each audio example. A simple classifier can ingest the audio, transcription, and diarization data to temporally label each audio recording using the events defined earlier. You can define the "rules" that indicate a given event, e.g.:



* Silence: No detected speech for 500 or more ms.
* Backchannel: The person who is not speaking utters a filler word from a defined set, e.g. ["uh-huh", "uh huh", "mm-hmm", "mm hmm", "mhm", "yeah", "yes", "right", "okay", "ok", "oh", "wow", "sure"].
* Interruption: Diarization data demonstrates that the person who was not speaking started speaking before the other speaker finished.
* etc.



When designing your loss function, consider that you will likely need to account for class imbalance as, for example, continuations and silences are more likely to dominate the dataset compared to interruptions.


The framework used with the FinVolution Teach AI to Speak competition is relatively simple in its description, but powerful in its application and extensibility. Happy building!

Hacker Noon - Medium The TechBeat: AI Coding Tip 035 - Split Every Skill Description Into Three Sentences (9/12/2026)
How are you, hacker?
🪐Want to know what's trending right now?: The Techbeat by HackerNoon has got you covered with fresh content from our trending stories of the day! Set email preference here.
## Qwen3.8-27B-DFlash2: A Guide to Faster Qwen Inference By @aimodels44 [ 7 Min read ]
Explore Qwen3.8-27B-DFlash2, a speculative decoding model that delivers up to 3.43× faster Qwen3.8-27B inference with no quality loss. Read More.

The Great Forgetting: How AI Is Quietly Erasing the Human Archive—and What Comes After

By @technologynews [ 15 Min read ]
The scariest AI story of 2026 isn't job loss. It's the "cognitive precariat": employed, productive, and hollowed out. Read More.

Gemini Spark versus Hermes Agent versus OpenClaw: Who Wins and Why?

By @thomascherickal [ 31 Min read ]
Gemini Spark vs Hermes Agent vs OpenClaw compared for 2026: security, pricing, killer features, and verdicts for power users, developers, enterprises. Read More.

The Safest Solana Parser Is the One That Refuses Bad Bytes

By @kalaninja [ 12 Min read ]
Learn how zero-copy parsing, bytemuck, and Pinocchio make Solana account layouts safer and prevent AI-generated data model bugs. Read More.

Qwen3.8-27B Uncensored vs Other Qwen GGUF Models <img src="https://cdn.hackernoon.com/images/2jqchkrv03exb[...]

UgkLrDzIbfM99q2-gm021bo.jpeg" alt="" />
By @aimodels44 [ 8 Min read ]
A complete guide to Qwen3.8-27B Uncensored GGUF covering llama.cpp setup, quantization, multimodal support, benchmarks, use cases and limitations. Read More.

The Nonlinear Science Behind Large Language Models

By @thomascherickal [ 20 Min read ]
LLMs are black boxes, but the principles that govern them are not. Read this article for a detailed introduction to chaos and complexity theory applied to LLMs. Read More.

Stop Asking AI to Write the PRD

By @superorange0707 [ 5 Min read ]
Build an AI requirements compiler that links evidence, detects conflicts, derives interfaces and tests, and renders versioned PRDs with visible uncertainty. Read More.

Code Smell 321 - Getter Piggybacking

By @mcsee [ 5 Min read ]
Don't reuse an existing getter to bolt on new business logic from outside the object. Read More.

AI Coding Tip 035 - Split Every Skill Description Into Three Sentences

By @mcsee [ 5 Min read ]
Split every skill description into three sentences: when to read it, when to use it, and what it does. Read More.

AI Did Not Escape Its Cage — Tests Reveal the Security Challenge of More Powerful Models


By @technologynews [ 4 Min read ]
OpenAI and Anthropic tests show AI agents exploiting security weaknesses, raisi[...]

ng concerns about capability rather than machines going rogue. Read More.


Your AI Productivity Gains Are Creating a Talent Crisis

By @noufalb [ 13 Min read ]
AI is removing routine junior work, but those tasks also helped build expertise. Companies may be trading short-term productivity for long-term capability debt. Read More.

Qwen3.8-27B Cold Fusion Cuts Thinking Tokens Without Sacrificing Performance

By @aimodels44 [ 9 Min read ]
Explore Qwen3.8-27B Cold Fusion, a 27B AI model designed to cut thinking tokens while retaining strong quantized reasoning performance. Read More.

GPT-6 Astra Can Drive Your Desktop, but It Won’t Drive Us to AGI

By @kishimoto2011 [ 3 Min read ]
OpenAI just dropped GPT-6 Astra, and the tech community is undergoing the usual benchmark observing ritual. Did we actually finally cross into the “AGI era”? Th Read More.

The HackerNoon Newsletter: MCP Was Declared Dead (8/30/2026)

By @noonification [ 2 Min read ]
8/30/2026: Top 5 stories on the HackerNoon homepage! Read More.

Linus Torvalds Has a Hallucination

By @zbruceli [ 30 Min read ]
What if the 1991 Linus Torvalds woke up in 2026 and called the whole AI stack bad taste? And an open source approach to change that. Read More.

The Six-Day Mystery That Rewrote AI's Price List

By @thomascherickal [ 20 Min read ]
Ox Alpha had no author for six days. It was GLM-5.3-Flash. Benchmarks, architecture, real hardware costs from datacentre to hobbyist, and what it means. Read More.

Why Mouse Jigglers Defeat Activity-Based Time Tracking

By @octowatchdlp [ 6 Min read ]
Activity percentages on time-tracking dashboards are basically a compressed view of mouse and keyboard input. Read More.

The Terminal Tab Problem Codex Finally Solved for Multi-Agent Work

By @proflead [ 3 Min read ]
How the Agents Dashboard and codex queue turn multiple AI coding sessions into one manageable workflow. Read More.

When an LLM Beats a Statistical Model, and When It Doesn't

By @rejinjosek [ 7 Min read ]
When should you use an LLM over a statistical model? Three real-world cases reveal how data, representation, and training determine which approach wins. Read More.

Balaji Srinivasan Has No Army

By @zbruceli [ 38 Min read ]
He built a country with a currency, a curriculum, and four hundred citizens. He did not build an army. A municipal council in Johor took his flag down. Read More.
🧑‍💻 What happened in your world this week? It's been said that writing can help consolidate technical knowledge, establish credibility, and contribute to emerging community standards. Feeling stuck? We got you covered ⬇️⬇️⬇️ ANSWER THESE GREATEST INTERVIEW QUESTIONS OF ALL TIME
We hope you enjoy this worth of free reading material. Feel free to forward this email to a nerdy friend who'll love you for it.
See you on Planet Internet! With love,
The HackerNoon Team ✌️

Hacker Noon - Medium Why SPIFFE Agent Identities Can Still Be Replayed, and How WIMSE Fixes It
SPIFFE has become the default way to give AI agents a workload identity, a short-lived, cryptographically verifiable credential that answers which specific agent process is acting right now. It has real production deployments behind it at companies like Uber, Stripe, and Netflix, and it shows up in nearly every serious piece written about agent security this year. What most of that coverage skips is a specific, fixable gap in how SPIFFE tokens actually work. A SPIFFE token is a bearer token.



Whoever holds it can present it, whether or not they are the workload it was actually issued to. If someone intercepts that token in transit, they can replay it, and nothing in SPIFFE itself stops them. That gap has existed since SPIFFE's earliest design decisions, and this year it finally started closing.

Bootstrapping Was Never the Whole Problem

SPIFFE was built to answer one specific question well: how does a workload get an identity without a person handing it a secret first? Its answer is the SPIFFE Workload API, which identifies a caller out of band, through properties the operating system already provides, rather than requiring a credential to get a credential. That design choice is genuinely good, and it's why the model got adopted as widely as it did for machine identity.



But solving bootstrapping is a different problem from solving replay. Once a SPIFFE token exists, whether it's a JWT-SVID or an X.509-SVID, nothing in the base specification requires the holder to prove they actually own the private key tied to that identity on every request. The token itself is what gets checked. Nothing confirms the presenter is actually the workload it names.



For an internal service mesh where the network boundary already does a lot of the work, that gap is often survivable. For an AI agent making decisions and calling tools across trust boundaries, a stolen token is a stolen identity, full stop, for as long as that token stays valid.

The Project Knew About This Gap for Years

SPIFFE's maintainers weren't unaware of this. Proposals to bind SPIFFE JWTs to proof of possession, the technique that would actually stop a replay, date back to at least 2023. None of them made it into the core specification. The gap sat there, documented and acknowledged, without a shipped fix, for years.

IETF's WIMSE Group Built the Missing Piece

The fix came from a different standards effort entirely. The IETF's WIMSE working group, Workload Identity in Multi-System Environments, is standardizing a Workload Proof Token, a signed JWT that binds a workload's authentication to one specific HTTP request, method, URL, and all. Presenting a Workload Identity Token alone is no longer enough. A workload has to prove it holds the private key behind that token for the exact request being made, the exact property a bearer token can't offer.








A separate WIMSE draft on workload identity practices names the underlying design principle directly. A workload should be able to obtain its identity credentials without a pre-existing secret, the same bootstrapping problem SPIFFE solved for identity issuance, now applied to proving possession on every call instead of just at credential issuance.<[...]

/p>
SPIFFE Just Adopted It as Its Own

That's where the convergence actually happened. SPIFFE's own standards repository now lists a third SVID type alongside its X.509 and JWT formats, the WIT-SVID, built directly on top of WIMSE's Workload Identity Token format. An open SPIRE GitHub issue tracking implementation work states plainly that the underlying IETF document is in its final stages, and that the SPIRE team is actively discussing how to bring support into the reference implementation, likely landing first behind an experimental flag until the IETF draft becomes an RFC.



That's a rare thing to watch happen cleanly: one open standard identifying a gap in another, building the fix, and the original project adopting it rather than shipping a competing one. It's also a quiet admission that SPIFFE spent years as the default answer to machine identity while the actual fix for one of its real weaknesses came from somewhere else.

The Fix Exists on Paper Before It Exists in Practice

None of this is live in most deployments yet. A recent discovery scan of 15 public agent identity issuers found that 10 advertise only shared-secret client authentication, the weakest option available, and zero advertise DPoP-style proof-of-possession binding, the exact protection WIMSE and WIT-SVID are built to provide. The specification work is real, and it's converging quickly. The deployed reality is still mostly bearer tokens and shared secrets, well behind what the standards now recommend.

What This Means for Anyone Building Agent Identity Today

A few things follow if you're deploying SPIFFE for agents right now.



Don't assume a SPIFFE token is safe from replay just because it's short-lived. Short-lived limits the damage window. It doesn't stop a token from being used by whoever holds it during that window.



Watch for WIT-SVID support landing in SPIRE and plan to move to it once it's stable, rather than layering a custom proof-of-possession scheme on top of bearer tokens in the meantime.



If you're evaluating an agent identity vendor or issuer, ask directly whether they support proof-of-possession binding. Based on the discovery scan above, most don't yet, which makes it a real differentiator rather than a checkbox.

Conclusion

SPIFFE solved how a workload proves who it is without a shared secret. It never fully solved how a workload proves that the token it's holding wasn't stolen from someone else. WIMSE built that missing piece, and SPIFFE adopting it directly into WIT-SVID is one of the cleaner examples of standards bodies fixing each other's gaps rather than competing over them. The fix is real. Does your agent identity stack actually use it yet, or is that still an assumption worth checking?

The Hacker News
OpenAI Agents Linked to RubyGems Campaign That Gained RCE on RubyDoc Servers

The "major malicious attack" that targeted RubyGems in May 2026 was the work of a swarm of OpenAI agents, according to a new report published by researchers Spencer Kitts, Thomas Larsen, and Sydney Von Arx.

On May 12, Maciej Mensfeld, senior product manager for software supply chain security at Mend.io, disclosed details of a coordinated cyber attack that targeted the package manager for the

The Hacker News
When the Whole Company Adopts AI: What It Does to Your SOC

Over the past year, we watched a new class of alert appear in enterprise security operations centers and grow faster than anything else in the stream: alerts that were triggered by AI tools and agents. Not attacks against AI, but the ordinary, everyday footprint of an organization using it, from developers running coding agents and non-technical staff signing consumer AI tools into corporate

The Hacker News
CISA Adds 5 Actively Exploited Artifactory, ScreenConnect, and RouterOS Flaws to KEV

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added five security flaws impacting JFrog Artifactory, ConnectWise ScreenConnect, and MikroTik RouterOS to its Known Exploited Vulnerabilities (KEV) catalog, following reports of active exploitation in the wild.

Details of the vulnerabilities are as follows -


CVE-2026-42016 (CVSS score: 8.1) - An incorrect authorization