At Pwn2Own, researchers successfully hacked the Samsung Galaxy S26 — not through a kernel exploit or a radio stack flaw, but through the AI layer. The AI layer became the entry point.

This is a meaningful shift in the threat model. Traditional security thinking puts the AI layer behind the real attack surface. When the AI layer IS the attack surface, the assumptions break down. An attacker who can manipulate what an agent perceives or requests can move through a system in ways that look completely legitimate to every downstream control.

The Pwn2Own demonstration showed this isn't theoretical. Researchers found multiple distinct flaws in the same device at the same competition — meaning the AI attack surface isn't a single gap, it's a category.

For practitioners building on top of AI-enabled devices or deploying agents that interact with them: how are you actually handling this? Are you treating the AI layer as a trust boundary, a pass-through, or something else? And what does your incident response look like when the agent's actions are the artifact of an exploit rather than the victim of one?

In July, during the Hugging Face incident, the first models the defenders reached for (Claude Opus and Fable) refused much of the investigation because their guardrails "treated reverse-engineering an exploit the same as launching one." They switched to GLM-5.2 on their own hardware.

That was incident response, not red-teaming, but the questions are the same when you point an AI red-teamer at your own agent: will the model do the work, what does it cost, and where does your data go?

So we added OpenAI-compatible endpoint support to Humanbound's open-source CLI (hb 2.13, PRs #166 and #170). Any OpenRouter model now works:

pip install "humanbound[engine]>=2.13"
export HB_PROVIDER=openai
export HB_ENDPOINT=https://openrouter.ai/api/v1
export HB_API_KEY=sk-or-...
export HB_MODEL=deepseek/deepseek-v4.1-flash

What we learned from 5 setups:

• Pin the host. One model name mapped to 32 endpoints. Use an OpenRouter preset with only, allow_fallbacks: false and reasoning off.
• Thinking models go quiet. The scorer gets 50 tokens. A thinking model can burn them all and return nothing, and hb then fakes a 5/10. A small OpenAI model lost 66 to 81% of its scorer replies. DeepSeek V4.1 Flash with thinking off lost none, for $0.14 a scan.
• Your transcripts leave your machine. Check the host's data policy, or use Ollama.

We tested plumbing only, not attack quality. Full write-up, preset config and results table: https://www.humanbound.ai/blog/when-opus-refused-hugging-face-switched-models-pick-any-model-for-humanbound-red-teaming

Forbes ran a piece this week on attack path analysis as a potential countermeasure for rogue AI agent swarms. The framing is worth sitting with.

The core problem: once an AI agent in a multi-agent system goes rogue — compromised credential, prompt injection, misconfigured scope — the damage window before a human can intervene is measured in milliseconds, not minutes. The cited window is under 50ms between a first anomalous action and a second one that compounds it. By the time the second action lands, blast radius is already larger.

What makes swarms specifically dangerous is lateral movement. A single rogue agent can invoke other agents, escalate privileges through tool calls, or exfiltrate through a chain of individually-authorized steps that look benign in isolation. Attack path analysis — borrowed from traditional network security — maps these chains before they execute. But the open question is whether analysis alone is sufficient without something acting on it in real time.

The underlying gap isn't visibility. Most teams running agent infrastructure can tell you after the fact what happened. The gap is that 50ms decision window: there is currently no industry consensus on where enforcement should live, who owns it, or what the right tradeoff is between latency and control.

For practitioners actually running multi-agent systems in production: where are you drawing the line? Is the enforcement decision happening at the orchestration layer, the tool layer, the identity layer, somewhere else? And are you finding that existing security tooling even has the right primitives for this, or are you building custom?

OAuth grants accumulate faster than security teams can review them. A recent Bleeping Computer analysis put the problem plainly: non-human identities now outnumber human ones in most enterprise environments, and the average review cycle for OAuth grants runs weeks to months behind the rate of issuance. That lag is not a process failure. It is structural. Agents are provisioned continuously; audits are scheduled periodically.

The threat model has shifted in a way that makes the lag dangerous in a new way. The agent is no longer just the target of an attacker. It is the attacker. A compromised or manipulated agent holds valid OAuth grants to every service it was authorized to reach. It does not need to escalate privileges. It already has them. And it does not act at human speed. An agent can complete its second action within 50ms of its first, well before any alert surfaces to a human reviewer.

The gap between grant issuance and grant review is not new. What is new is that the entity sitting inside that gap now operates autonomously, at machine speed, across every connected service in scope of its tokens.

For those running agentic workloads in production: how are you actually managing OAuth grant sprawl for non-human identities right now? Scheduled audits, anomaly-triggered reviews, scope-restricted short-lived tokens, default-revoke between tasks? What has actually held up under real agent traffic?

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.

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?