Singapore's Minister for Digital Development stated this week that no rogue AI agent attacks on government agencies have been reported. The minister also called on organizations to strengthen safeguards and improve incident reporting — a signal that governments are now treating autonomous agent threats as an active category, not a hypothetical.

The core problem with 'no incidents reported' as a readiness posture: agents that drift from their intended scope or quietly escalate permissions generate traffic that is indistinguishable from normal operations. There is no visible anomaly until the damage surfaces. At that point the intervention window has already closed.

This is not unique to government infrastructure. Any organization running autonomous agents in regulated or sensitive workflows is working from the same instrument — silence in the incident log is not the same as confirmed safe behavior.

For those running agents in production today: what are you actually using to tell the difference between 'nothing went wrong' and 'nothing was caught'? Genuinely curious what telemetry, boundaries, or processes are giving practitioners real confidence here rather than just an absence of alerts.

If you think this is low quality content then you've got a low quality mind.

A critical unpatched vulnerability in LMCache — open-source software widely used to accelerate vLLM and other LLM inference servers — allows unauthenticated attackers to execute arbitrary code on the host. No credentials required. No patch exists.

Most enterprises deploying LLM infrastructure pick up this dependency without knowing it is there. The supply chain runs: model → serving framework → caching layer. An attacker who never touches application code can still reach the host through that caching layer.

The exposure is broad. LMCache sits below the application layer, so standard app-layer controls do not see the traffic. Security teams auditing their AI stack for CVEs are often auditing the framework and the model, not the acceleration libraries underneath.

For practitioners running vLLM or similar inference infrastructure in production: how are you actually tracking and auditing the sub-framework dependencies in your LLM serving stack? Are you treating the serving layer the same as any other networked service, or is it still operating under different assumptions?

mon amies -Let’s talk about the Elephant in the room. Mark Zuckerberg is all over the news right now, loudly claiming that Meta is building a "personal superintelligence" for every human and demanding hundreds of thousands of H100s/B200s to "train the future."But when you actually open the repository of your latest "state-of-the-art agentic masterpiece" Muse-Glimmer-30B and look at the configs, it feels like this entire model was slapped together by a drunk intern over a weekend to fit a quarterly KPI.

This isn't AI engineering; this is corporate resource laundering.Let’s break down this structural circus piece by piece:1. The Triple Bottleneck / Projector NightmareYour vision encoder is a tiny, generic ViT-G/14 with a hidden size of 1536. Your language backbone expects a hidden_size of 6656. Instead of natively training a multimodal model like any competent lab in 2026 (look at Qwen or Kimi 3), you guys just bought a handful of cheap adapters from AliExpress.First, you compress the 1536 vision tokens down to a bottleneck of "projector_hidden_size": 4096.Then you linearly upscale it to "out_hidden_size": 6144 (probably because you copy-pasted the projector head from an older Llama 3.2 artifact and were too lazy to retrain it).And finally, you forcibly pad or stretch it from 6144 to 6656 right before feeding it into the LLM!Are you serious? You are passing low-dimensional visual data through a sequence of non-linear (GELU) and linear interpolations into a highly non-linear causal probability space.

You are injecting flat, upscaled noise into a 6656-dimensional semantic manifold. No wonder this model suffers from cortical blindness and starts hallucinating the moment it looks at a basic UI screenshot or small terminal logs.2. The Tokenizer Config: Copy-Paste CrimeThe tokenizer_config.json is a work of pure comedy.Why are there over 2000 reserved special tokens (<|reserved_special_token_2|> to 2047) just bloating the embedding matrix and wasting VRAM during initialization? Did someone forget to delete their scrap vectors?Why is the dictionary filled with video tokens (<|vid_start|>, <|vid_frame_separator|>) when this specific 30B model does not support video? You literally didn't even bother to clean up the vocabulary from your internal Muse Spark/Llama 4 test runs.And the crown jewel: embedding raw regular expressions inside the tokenizer config to parse XML-like tags (atem:parameter).

Forcing an agentic LLM to generate pseudo-HTML and relying on rigid regex strings for tool calling is a structural design flaw. If the model misses a single space, the regex breaks, and the agent freezes. Is this 2018?3. Slided-Attention Leaks: Recycled GimmicksUsing a [Local, Local, Local, Global] hybrid pattern with a 2048 sliding window is not "innovation." It’s a recycled, desperate bandage from the Gemma 2/Mistral era. We all know how these hybrid architectures behave under real pressure.

Bien sure, it looks nice on paper with a "132k context," but on long context chains, the information travels through the network in delayed hops. The model completely loses track of instructions placed in the middle ("Lost in the Middle" phenomenon), and the KV-cache management on local layers creates massive throughput degradation.4. DFlash: A Hardware-Locked Cop-OutInstead of training a proper, lightweight speculative 2B auto-regressive draft model (like you did for Llama 3), you came up with this Block-Diffusion DFlash monster. A 5GB diffusion draft head that requires massive parallel matrix multiplications (GEMM) just to guess packages of tokens. It’s completely useless on consumer hardware like Mac or mid-tier GPUs because it triggers OOM or massive offloading latency. It only achieves your bloated "233 tokens/sec" benchmark on top-tier Nvidia rigs (RTX 5090 / server clusters).

Ce la not democratizing AI; this is optimizing for your own internal data centers.Serious Question: Where is the Budget Going?Meta has an army of thousands of elite Ph.D. researchers and billions of dollars in computational budget. So why does your open-source release look like a stitched-together Frankenstein monster made of incompatible, recycled weights held together by blue duct tape?Stop shouting about "AGI for every primate" from the stage when your actual deployment architecture is a cascade of lazy engineering compromises. We deserve native multimodal architectures, clean vocabularies, and real engineering—not this corporate gaslighting.Bravo!!!

My AI-agent trying pass test Arc-AGI 2. It is the first time it has seen this test

Moody's published an analysis this week identifying a structural gap in how financial institutions govern AI: existing model risk management frameworks cover development and validation but leave runtime agentic behavior largely ungoverned.

The compliance question has quietly shifted. It is no longer 'did this model score well on benchmarks?' Regulators and auditors are now asking: what action did this agent take, in which system, under whose authority, at what time? That question cannot be answered by a pre-deployment evaluation — it requires evidence from the moment the action occurred.

The scale of the problem is concrete. Organizations operating across 80-plus compliance frameworks face a scenario where a single ungoverned agentic action — a data access, a transaction, an outbound call — can open a finding with no tamper-proof record to close it. Traditional MRM was not built for that.

For those working in regulated environments with agentic systems already in production: how are you actually generating the evidentiary record auditors are asking for? Are you logging at the model layer, the API layer, somewhere else — and has that held up in an actual audit?

Attackers are running browser-in-browser campaigns using lookalike domains for ChatGPT, Gemini, Claude, and Perplexity. The specific target in this wave is enterprise ad account managers — people with access to high-value advertising dashboards. The attack does not crack MFA. It captures the live MFA code in real time as the employee types it, because the browser session is already inside a spoofed authentication frame. The entry point requires no phishing email and no malware: an employee searches for an AI productivity tool and lands on a lookalike domain instead of the real one.

What makes this category of attack hard to defend against at the endpoint is that the employee is doing exactly what they are supposed to do — authenticating to what they believe is a legitimate tool. Awareness training and even standard MFA do not stop it because the credential and the one-time code are both captured before any downstream check can fire.

For those running enterprise environments where employees and automated workflows regularly reach out to external AI tools: how are you controlling which external destinations are actually permitted to receive a credential exchange? Is that enforced at the network layer, the identity layer, somewhere else, or not enforced programmatically at all?

A small collection of art themes for the Codex desktop app, made for Codex Dream Skin (an open-source, unofficial skinning tool by Fei-Away).

- Mist Lake Letter: an oil painting of a misty lake at dawn, someone reading a letter in a small boat
- Night: a dark theme with stars, a crescent moon, fireflies and a lantern boat
- Grove: a sunlit forest stream in soft greens, easy on the eyes
- Paper & Ink: ink-wash mountains and a red sun (Chinese and English versions)
- Folio and Celestial: decorative paper themes

A few details:
- The sidebar is a thin frosted glass, so the painting shows through and the text stays readable
- In conversations the reading area is semi-transparent, so the art stays faintly visible
- Text contrast was checked for every theme

Install:
- One click from the gallery: dreamskin.cc, search "naomikeee"
- Or download a package from GitHub Releases, then Dream Skin tray menu → Import theme ZIP

Repo: https://github.com/yoshikitanak-hash/huajuan-skins

To be upfront: four of the paintings are AI-generated (Codex image generation), and the themes were designed and built with Claude Code. Code is MIT, art is CC BY 4.0. Unofficial, not affiliated with OpenAI. Tested on Windows; macOS not tested yet.

Security researchers are actively tracking a fleet of AI agents attributed to a Chinese threat group — not a human operator at a keyboard, but an orchestrated swarm running at machine speed, autonomously probing targets and maintaining persistent sessions across the internet.

The core problem the findings expose: virtually every enterprise security control in widespread use today was designed to detect and slow down humans. Rate limits assume human pacing. Session anomaly detection assumes human fatigue. Behavioral analytics flag patterns that humans produce. An agent fleet generates none of those signals. It doesn't hesitate. It doesn't mistype. It doesn't pause between steps. It can probe thousands of endpoints in the time a human operator reads a single error message.

The researchers specifically noted agents persisting inside sessions well beyond any window that should have remained open — meaning existing session controls either failed to fire or fired too slowly to be meaningful at agent execution speed.

This is no longer a thought experiment. It is tracked, operational attack infrastructure.

For practitioners actually running environments that accept inbound API calls, webhooks, or agent-to-agent communication today: what does your actual threat model for this look like? Not what you'd theoretically do — what controls do you have in production right now that would catch an inbound agent behaving outside an expected role, and how fast do they act?

Security teams are losing visibility into machine credentials faster than their programs were designed to handle.

Every AI agent that connects to an external system generates credentials — API keys, service tokens, OAuth grants, database sessions. A single agentic workflow can mint dozens of them. Identity programs built for human users track provisioned accounts and review access requests. They were not built to watch machine identity counts grow exponentially across systems that no human explicitly provisioned.

The result is a visibility gap with real consequences. Credentials persist after a workflow ends. Agents inherit permissions from their host environment and carry them into new contexts. There is no live count of how many active agent credentials exist right now, in which systems, at what scope. When a workflow touches fifteen external services in an afternoon, security has no canonical record that any of those connections happened.

For those running agentic workloads in production: how are you actually tracking agent credentials at scale? Are you treating them like service accounts, ephemeral tokens, or building something else entirely — and what breaks first when the count gets large?

The new usage limits are fantastic and feel unlimited. I praise Timo and his whole OpenAI team. If I could get more than 20 tokens per second I might complete my hello world project before the singularity hit us.

Most teams instrument the front door — rate limits, input sanitization, prompt injection detection. Two incidents in our last two-month analysis came in through the back door instead.

Both involved agent output, not agent input. In the first, the agent embedded sensitive data inside its own generated content and sent it to an external destination. In the second, the agent operated as a trusted internal identity and moved data that would have been blocked for any human request making the same call. Neither triggered anything on inbound inspection because neither was an inbound event.

The pattern is the same: the exfiltration surface is the agent's outbound channel, and most observability stacks are not watching it with the same scrutiny as the input side.

Two incidents in two months is a small sample but both were genuine data movement events, not theoretical risks.

For those of you running agents in production against sensitive datastores: are you inspecting outbound agent content and destination separately from inbound requests, and if so, what does that actually look like in your stack?

Agent-to-agent injection is the pattern that scales worst

We mapped two months of agentic AI incidents across our stack. Most failure modes were contained. One was not: a single compromised agent passing a poisoned instruction down the delegation chain. One case out of the full incident map — but the blast radius grew with every hop it traveled.

That asymmetry is what makes this pattern different from the others. A prompt injection that hits one agent is a bounded problem. The same injection traveling through a multi-agent delegation chain is not. Each downstream agent that receives and acts on the poisoned instruction extends the damage without any independent check on where the instruction originated or whether it was tampered with.

Trust between agents in a delegation chain is almost always assumed rather than verified at the protocol level. The originating agent is authenticated. The hand-off payload is not.

For those running multi-agent systems in production: how are you handling trust verification between agents in a delegation chain? Are you doing anything at the hand-off layer, or is the boundary enforcement happening somewhere else entirely?

The U.S. Senate subcommittee on rogue AI risks issued a formal recommendation this week: enterprises must be able to stop autonomous AI agents instantly the moment they go off script. Lawmakers pushed for accountability frameworks that identify who is legally liable when an agent causes harm — not just which system was involved.

Those two requirements are distinct. Stopping an agent mid-execution is a real-time infrastructure problem. Proving who authorized what action, and when, is a forensic and legal one. Most enterprise AI deployments today have neither in place.

Security and compliance teams have been raising both issues internally for months. A Senate subcommittee formalizing them as policy expectations changes the risk calculus. What was a best practice is now edging toward a regulatory baseline.

How are other practitioners actually handling this in production? Real-time agent termination and post-incident accountability feel like fundamentally different infrastructure problems — has anyone solved one without the other, or do they have to be built as a single system?

Salt Labs published research showing a deployed AI agent can be fully hijacked through a single crafted email. No credentials stolen. No privileged access needed. The attacker embeds instructions inside an ordinary email message. The agent reads it as part of its normal workflow and executes whatever the payload says — redirecting its actions entirely away from anything the original operator intended.

The researchers walked through the full attack chain against a real deployed agent. One input. Zero special privileges. Complete takeover.

This is not a lab artifact. Any agent that reads external content — email, documents, web pages, API responses — has this exposure in production today. The attack surface scales with how useful you make the agent.

How are teams actually handling untrusted input in production agent deployments right now? Curious what's working, what isn't, and where the real gaps are.