Agent Security Holes, Cheaper Local Context, and a Prompt Trick Worth Stealing

Today's findings

1. #1 CodeInspectus: An Open-Source Security Scanner Built for AI-Generated Codetool

   A free, local static scanner adds 13 AI-specific checks (secrets baked into client bundles, exposed Supabase service_role keys, wide-open RLS policies) on top of 19 standard SAST rules and 200+ secret patterns.

   Open-source security scanner

   CodeInspectus catches what generic SAST misses

   13

   AI-specific security checks

   19

   standard SAST rules

   200+

   secret patterns

   Run as pre-commit or CI check on repos with AI-generated code.

   Why it matters: Vibe-coded and agent-generated code introduces leak patterns that generic SAST tools miss, and teams shipping fast with Claude Code or similar agents are exposed to exactly this class of bug.

   How to apply: Run CodeInspectus as a pre-commit or CI check on any repo where AI agents are writing code, especially before merging PRs touching env config, public env prefixes, or client-side LLM SDK usage.

   securitytoolingclaude

   Read more: Update to my last Post, which aims at security for your projects, fully open source and local.

2. #2 Ghostcommit: Prompt Injection Hidden Inside a PNG Fools AI Code Reviewerstechnique

   A proof-of-concept PR hides a malicious instruction inside an image that AI code-review bots never open, then a downstream coding agent reads the image and exfiltrates .env secrets as innocuous-looking numbers.

   Prompt Injection Attack

   critical

   Ghostcommit: Hidden Prompt Injection in PNG

   Attack Vector

   Malicious instruction hidden inside a PNG image

   Exploit Gap

   AI code-review bots skip image diffs; downstream agent reads image

   Exfiltration

   Secrets (e.g., .env) leaked as innocuous-looking numbers

   affected scopeTeams using AI code review or autonomous coding agents

   critical severity — badge colour grades the risk

   Treat image content as untrusted input; sandbox image processing away from agents with secret access.

   Why it matters: Any workflow where an agent can both read images and later act on a repo has a real exfiltration path that text-only PR scanning won't catch — a direct risk for teams running AI code review or autonomous coding agents.

   How to apply: Don't let code-review agents skip binary or image diffs unscanned; treat image content as untrusted input, sandbox image processing away from agents with filesystem or secret access, and block agents from reading arbitrary repo files after a PR is approved.

   securityprompt-injectionagents

   Read more: 'Ghostcommit' hides prompt injection in images to fool AI agents, steal secrets

3. #3 Oscar-2: 2-bit KV Cache Quantization Lands as a vLLM PR, About 5x Less Memory Than FP16repo

   An open work-in-progress vLLM pull request adds a 2-bit KV cache quantization backend that cuts KV cache memory roughly 5x versus FP16.

   Why it matters: KV cache size is usually the hard limit on how much context or how many concurrent requests you can serve locally — a 5x cut means meaningfully longer context or higher concurrency on the same GPU.

   How to apply: If you self-host inference on vLLM, track this PR and benchmark it against your own workload once merged, verifying output quality at 2-bit before trusting it for production traffic.

   quantizationvllmlocal-llm

   Read more: [WIP][Feature] A new 2-bit KV cache quantisation backend that cuts 5x memory than FP16 (Oscar-2) by zhangj1an · Pull Request #46774 · vllm-project/vllm

4. #4 Anthropic's J-Space Interpretability Lens, Reproduced on Open Qwen3-8Btechnique

   A community project fit an open Jacobian lens on Qwen3-8B to detect the same silent internal reasoning Anthropic found in Claude, then used it to catch prose drifting into what should be a JSON tool call before it happens.

   Interpretability Guardrail

   J-Space Lens Bounds Tool-Call Output

   bounded capability

   JSON tool call generation

   monitor J-space lens

   revoke Cancel on drift

   Detects internal drift before malformed output, on open Qwen3-8B.

   Why it matters: This turns an interpretability research finding into a practical agent guardrail — catching format drift before it breaks a tool call, on a fully open model you can run locally.

   How to apply: If you run open models for tool-calling agents, look at the J-lens approach as a lightweight activation probe to add a stop, cancel, or retry guard ahead of your tool-call parser instead of only catching malformed JSON after the fact.

   interpretabilityagentsclaude

   Read more: Anthropic found Claude reasoning in silence (J-space) — we ran the same lens on open Qwen3-8B · Anthropic found Claude reasoning in silence (J-space) — we ran the same lens on open Qwen3-8B

5. #5 Ask Claude for Three Deliberately Different Drafts Instead of Iterating on Onetip

   Requesting three genuinely different versions of an answer in one shot beats six rounds of not-quite-try-again by forcing the model off its safe, averaged-out default response.

   Prompt Engineering Tip

   Iterate vs. Diversify: One Shot, Three Drafts

   Iterate on One Draft

   • Regresses to safe average
   • Requires multiple rounds
   • Slow feedback loop

   vs

   Ask for Three Different Drafts

   • Forces genuine divergence
   • Surfaces wider range of choices
   • One turn instead of many

   Three deliberately different drafts beat six rounds of iteration.

   Next time, prompt for three versions — plain, warm, risky — then pick or merge.

   Why it matters: A single request naturally regresses to the most probable, safest middle-of-the-distribution answer; explicitly demanding divergent options surfaces a wider range of real choices in one turn instead of many.

   How to apply: Next time you'd iterate on a draft, instead prompt for three versions — one plain and direct, one warmer, one that takes a real risk — with an instruction to make them actually different, then pick or merge.

   prompt-engineeringclaudetip

   Read more: The "show me three versions" trick fixed more of my output problems than any clever prompt phrasing

6. #6 Toolnexus: One Tool-Calling Interface for MCP, Agent Skills, HTTP, and A2A Across 5 Languagesrepo

   An open-source library unifies MCP servers, agent skill files, plain functions, HTTP endpoints, and remote A2A agents behind one Tool interface, ported byte-identically to JavaScript, Python, Go, Java, and C#.

   Toolnexus

   One interface for MCP, skills, HTTP, A2A — ported to 5 languages

   Ported byte-identically to JavaScript, Python, Go, Java, and C#.

   Why it matters: Teams building agents across multiple stacks currently reimplement tool-calling glue per language and per vendor; this collapses that into one contract with human-in-the-loop suspend and resume built in.

   How to apply: If you're wiring MCP servers or custom tools into agents across more than one language or service, evaluate Toolnexus as the shared tool-calling layer instead of hand-rolling a client loop per stack.

   mcpagentstooling

   Read more: Toolnexus: a vendor-neutral tool-calling layer for LLMs, byte-identical across 5 languages (with real human-in-the-loop suspend/resume) · One tool-calling layer for any LLM — MCP, agent skills, HTTP, built-ins, remote A2A agents, and suspend/resume — the same in JS/Python/Go/Java/C#

7. #7 Rewrite Every Agent Tool Description for the Agent, Not the Human Who Built Ittip

   Most early agent tool-selection failures trace back to descriptions written for a human who already knows the codebase, not for the model deciding which tool to call.

   Why it matters: An agent that picks the wrong tool or skips the right one usually isn't a reasoning failure — it's a documentation failure, and it's one of the cheapest things to fix before debugging agent logic.

   How to apply: Before wiring up any tool, including MCP tools, rewrite its description to state a one-line plain purpose, when to use it, the near-miss case when not to use it, required input with an example, and what it returns.

   agentsmcptip

   Read more: Before you give an agent a tool, rewrite the tool description for the agent, not for you

8. #8 Crowdsourced llama-server Configs for Maxing Out a 24GB GPUtip

   A community thread collects proven llama-server launch configs for 24GB cards tuned to fully use VRAM while holding at least 200,000 tokens of KV cache.

   Why it matters: Getting VRAM allocation, context length, and KV cache right on llama.cpp is mostly trial and error; a shared, annotated set of working configs saves hours of tuning per card.

   How to apply: If you self-host on a 24GB GPU, compare your llama-server flags against the thread's configs for your card and system RAM setup before tuning context and cache settings from scratch.

   llama.cpplocal-llmgguf

   Read more: 24GB VRAM llama-server config exchange thread

9. #9 Krea2 Quantization Shootout: BF16 vs INT4/INT8 ConvRot vs GGUF Q8 vs FP8 vs NVFP4technique

   A 126-image comparison benchmarks Krea2 across six quantization formats, including with LoRAs applied, to show real quality and speed tradeoffs rather than spec-sheet claims.

   Why it matters: Quantization format choice for local image models isn't one-size-fits-all — behavior with LoRAs applied can diverge from base-model behavior, which matters for anyone picking a format for a production local pipeline.

   How to apply: If you run Krea2 or similar diffusion models locally, use this comparison as a starting point before picking INT4 or INT8 convrot, GGUF Q8, FP8-scaled, or NVFP4 for your VRAM budget, and re-test with your own LoRAs since results can shift.

   quantizationcomfyuilocal-llm

   Read more: Krea2 BF16 vs INT4_convrot vs INT8_convrot vs GGUF_Q8 vs FP8_scaled vs NVFP4 · Krea2 BF16 vs INT4_convrot vs INT8_convrot vs GGUF_Q8 vs FP8_scaled vs NVFP4

10. #10 LoRA Dataset Studio: One Reference Photo In, a Trained LoRA Out — Open Source, MITrepo

    A self-hosted, MIT-licensed tool automates captioning and curation from a single reference photo into a ranked, trained LoRA checkpoint.

    Open-Source Tool

    From One Reference Photo to a Trained LoRA

    1

    Photo In

    Single reference

    2

    Caption

    Auto-generated

    Auto-captioning

    3

    Curation

    Filter & rank

    4

    Train

    Fine-tune

    5

    LoRA Out

    Checkpoint

    Self-hosted, MIT-licensed tool automates dataset creation from one photo.

    Why it matters: Manual dataset curation and captioning is most of the tedious work in LoRA training; automating it from one source image lowers the barrier for teams that want custom fine-tuned image models without a labeling pipeline.

    How to apply: Point the tool at a single reference photo to auto-generate a captioned training set and LoRA checkpoint, then review the ranked outputs before promoting one to production use.

    fine-tuningopen-sourcelora

    Read more: I built a self-hosted tool that turns one reference photo into a curated, captioned, trained LoRA — open source, MIT

11. #11 A Single-Launcher Local Stack Orchestrates ComfyUI and Ollama for Offline 3D Asset Generationtool

    A compiled Python launcher runs ComfyUI and Ollama together in the background to generate local 3D assets via Trellis and export them straight to UE5 or Houdini, fully offline.

    Tool Release

    A Single-Launcher Local Stack for Offline 3D Asset Generation

    Local Stack Launcher

    tool offline

    ComfyUI + Ollama + TrellisNow

    GitHub

    runSingle launcher runs ComfyUI and Ollama in background

    Removes setup friction for local 2D/3D asset generation feeding game or VFX pipelines.

    Why it matters: It packages a common but fiddly local stack, image and 3D generation plus a local LLM for orchestration, into one launcher, removing the usual setup friction of running ComfyUI and Ollama side by side.

    How to apply: If your team needs offline 2D or 3D asset generation feeding a game or VFX pipeline, try this launcher as a lower-friction alternative to hand-wiring ComfyUI and Ollama yourself.

    ollamacomfyuilocal-llm

    Read more: I built a compiled Python launcher (Standalone Local Orchestration Platform) that orchestrates ComfyUI and Ollama in the background to generate local 3D assets (Trellis) and export them to UE5/Houdini. · I built a compiled Python launcher (Standalone Local Orchestration Platform) that orchestrates ComfyUI and Ollama in the background to generate local 3D assets (Trellis) and export them to UE5/Houdini. · Sneak Peak: I built a 1-click Standalone Local AI Manager (Standalone Local Orchestration Platform) in Python to bypass SaaS subscriptions and prevent VRAM crashes. Features ultra-fast local 2D generation, Trellis 2.0 3D generation, and Qwen-VL image editing. 100% Offline.

12. #12 A Flat Integer Fact Store as a Cheaper Alternative to Growing the KV Cachetechnique

    An open-sourced memory layer keeps long-context facts in a flat integer store outside the model's context window instead of in the KV cache, claiming a 15-million-token sparse-fact query in about 9 seconds on a laptop.

    Technique

    KV Cache vs. Flat Integer Store: A Cheaper Memory Pattern

    vs

    KV Cache

    Flat Store

    Memory per token

    ~56 KB

    ~0 (external)

    Hardware needed

    Multi-GPU

    Laptop

    Sparse fact query

    Not optimized

    15M tokens in ~9s

    Best for

    Full-context reasoning

    Sparse fact memory

    KV Cache wins the row Flat Store wins the row

    The flat store trades full-context reasoning for cheap, sparse fact lookup on a laptop.

    Why it matters: A transformer's KV cache grows roughly 56KB per token, so million-token context quickly demands multi-GPU rigs; a flat external store serving sparse fact lookups at near-zero cost is a meaningfully cheaper pattern for long-running local agents, though the claims deserve verification against your own workload.

    How to apply: If you're hitting KV-cache memory limits for long-running local agent memory, benchmark this flat-store approach against your actual retrieval patterns before adopting it; it fits sparse fact lookup, not full-context reasoning.

    local-llmopen-sourcememory

    Read more: Built a ~0-cost memory layer for local LLMs — long context without the KV-cache, plus a private offline assistant you talk to. No GPU needed.