Security

TL;DR Plan‑then‑Execute (P‑t‑E) agents separate strategy from action: a Planner writes a machine‑readable plan; an Executor carries it out. This simple split dramatically improves predictability, cost control, and—crucially—security. Hardened correctly (least‑privilege tools, sandboxed code, human sign‑offs), P‑t‑E becomes an enterprise‑grade pattern rather than a lab demo. Why today’s agents need a spine, not vibes Reactive patterns like ReAct feel nimble because they “think, act, observe, repeat.” But that short‑horizon loop is exactly what makes them fragile in production: they meander, retry the same failing step, and are easy to hijack by indirect prompt injection embedded in web pages or PDFs. P‑t‑E locks the control‑flow before the agent ingests untrusted data. The plan becomes an auditable artifact and the execution stage can be cheap, parallel, and tightly permissioned. ...

LLM code assistants are now the default pair‑programmer. Many teams tried to make them safer by bolting on RAG—feeding official docs to keep generations on the rails. ImportSnare shows that the very doc pipeline we trusted can be weaponized to push malicious dependencies into your imports. Below, I unpack how the attack works, why it generalizes across languages, and what leaders should change this week vs. this quarter. The core idea in one sentence Attackers seed your doc corpus with retrieval‑friendly snippets and LLM‑friendly suggestions so that, when your assistant writes code, it confidently imports a look‑alike package (e.g., pandas_v2, matplotlib_safe) that you then dutifully install. ...

We’ve gotten good at spotting API misuse in crypto code (think “don’t use ECB,” “don’t hardcode IVs”). But many production failures don’t come from the obvious API call—they’re born in the logic that surrounds it: the parameter checks, corner-case math, and brittle “optimizations.” That’s where CryptoScope steps in: an LLM-powered framework that reads crypto code like a human auditor, guided by a domain corpus and structured prompts, to uncover logic-level vulnerabilities without executing the code. ...

When we talk about parameter-efficient fine-tuning, LoRA (Low-Rank Adaptation) is often celebrated as a silver bullet: cost-effective, memory-efficient, and—many assume—safe. After all, it modifies only a small fraction of model parameters, sideloaded as low-rank matrices, while leaving the massive pretrained model backbone untouched. The prevailing belief has been that such minimal intervention can’t possibly memorize or leak sensitive data. This belief is now decisively debunked by LoRA-Leak, a landmark framework introduced in a new paper by researchers from Tsinghua and HKUST. Their findings are a wake-up call for AI developers and policymakers alike: even LoRA-finetuned models are highly vulnerable to membership inference attacks (MIAs)—and ironically, the very presence of the frozen pretrained model amplifies this leakage risk. ...