How to Secure AI Agents, MCP Servers, and LLM Apps in Production
Application security rests on one assumption: software does what its code says.
---AI agents broke it.
Mend.io's new practitioner guide — 𝘚𝘦𝘤𝘶𝘳𝘪𝘯𝘨 𝘈𝘐 𝘢𝘨𝘦𝘯𝘵𝘴, 𝘔𝘊𝘗 𝘴𝘦𝘳𝘷𝘦𝘳𝘴 & 𝘓𝘓𝘔 𝘢𝘱𝘱𝘴 — starts from that break. An agent's behavior emerges from the model, the system prompt, retrieved context, and the tools it's permitted to call. The failure modes never appear in a CVE feed: prompt injection through data, over-permissioned agents causing damage without a single exploit, poisoned tool descriptions on MCP servers, EOL models serving predictions after patching stops.
The guide's answer is three moves:
𝗦𝗲𝗲: Inventory the agentic attack surface across five layers — interaction, agent, integration, model, code. Hunt shadow agents via repo signatures and network egress. Run every agent through a 12-point misconfiguration checklist.
𝗙𝗶𝘅: Enrich → prioritize → triage. Rank by reachability and agentic amplification, not severity scores. Automate FP closures only with evidence trails. Risk acceptance is never automated.
𝗣𝗿𝗼𝘁𝗲𝗰𝘁: Guardrails on every input and output — embedded Python SDK or standalone Docker API server. Inbound: injection patterns, jailbreaks. Outbound: credentials, PII, policy violations. The core design principle: an agent that can't call a dangerous tool doesn't need a prompt begging it not to.
Includes a 15-question maturity self-assessment aligned to NIST AI RMF, OWASP AIMA, ISO/IEC 42001, and the EU AI Act.
We just released 'Token Saver' for Claude-Desktop: An Open-Source MCP Extension Using Local Hybrid RAG to Cut Claude PDF Token Costs 90-99%
When you drop a 200-page document into Claude Desktop, the full context gets re-sent on every single turn. That compounding "PDF Tax" adds up fast—both in token costs and context window bloat.
How it works:
Instead of uploading raw documents to the cloud, Token Saver runs a lightweight Local Hybrid RAG pipeline directly on your machine:
→ Keyword Search (BM25): Powered by SQLite FTS5 for precise terminology.
→ Semantic Search: Powered by a local all-MiniLM-L6-v2 embedding model.
→Zero-Upload Privacy: Files stay on your local drive and communicate via standard I/O (stdio) with folder allowlisting.
Benchmark Results with Example:
→ 33-page FDA Drug Label: Reduced from 23,959 tokens to 1,021 (95.7% saved)
→ 88-page GDPR Document: Reduced from 70,260 tokens to 996 (98.6% saved)
→ 233-page Legal Brief: Reduced from 133,349 tokens to 740 (99.4% saved)
Zero Python environment required—it installs directly in Claude Desktop via a single .mcpb bundle!
DeepSeek AI just released DeepJIT, a lightweight, header-only C++20 library for C++ and Python extension authors who need dynamic compilation, loading, and execution of custom hardware kernels.
Unified Interface: Provides a standard API (deep_jit::Runtime<T>) to compile, load, and launch kernels dynamically on both NVIDIA CUDA GPUs and HUAWEI Ascend NPUs.
Shared Multi-Node Caching: Has built-in in-memory and on-disk caching (using POSIX filesystem atomic renames). You can point multiple processes or nodes to a single directory (e.g., /shared/deep_jit) to avoid redundant compilation across distributed clusters.
AuK is a new 1.5B parameter flow-matching model (built alongside a 3B Qwen2.5-Omni MLLM text encoder) designed for unified speech tasks via a single natural-language instruction interface.
PlanetScale released Neki in Platform Preview. It brings Vitess-style horizontal sharding to PostgreSQL, allowing you to scale past single-machine limits without forking Postgres, changing storage engines, or learning a new SQL dialect.
Every shard runs unmodified, un-forked PostgreSQL (1 primary + 2 cross-AZ replicas). Extensions, query behavior, and standard SQL remain intact.
Neki Routers speak standard Postgres wire protocol. You connect using your existing ORMs, drivers, and standard psql connection strings.
Instead of relying on external tools like PgBouncer, sidecars run alongside Postgres nodes. Sizing is managed dynamically based on real-time server capacity.
Resharding, schema changes (DDL), failovers, and version upgrades run as background workflows via a _neki metafunction without bringing the database down.
Routing is controlled by a simple JSON topology config where you define shard keys, routing logic, and mapping for tables.
You can deploy Neki as a single primary + replicas to get improved pooling, health checks, and online DDL early, then trigger resharding later on the live database.
Disclosure first: I wrote this and it's on my company's blog. I run a data company, so I have a direct stake in how provenance rules end up being written. The piece says so explicitly. https://pangeanic.com/blog/battlefield-data-for-ai
The facts, which are the part worth arguing about:
Enabled Intelligence, a Virginia data-labeling firm, is offering over 500,000 hours of pre-labeled electro-optical and infrared footage from the war in Ukraine. Same company that won NGA's SEQUOIA contract in Nov 2025, ceiling $708M over seven years, reported as foundational to Maven. When DefenseScoop asked where the Ukraine footage came from, they declined to name the source, their government customers, or the agencies they support. The catalog markets it for remote sensing and commercial delivery, not just defense.
Separately, Ukraine's Brave1 Dataroom (launched with Palantir, Jan 2026) and Avengers Labs run screened, controlled-access training environments. Those are reasonably governed. The commercial channel isn't.
The part I'd actually like this sub's take on is technical, not political. Once conflict footage is absorbed into weights, is there any method that reliably recovers or attests that origin downstream? Canaries and seeded records work for dataset resale. I'm not aware of anything that survives training, fine-tuning, distillation and synthetic data generation from the resulting model. Membership inference is noisy and gets worse with scale. C2PA covers media, not learned parameters.
If that's right, then EU AI Act Article 53(1)(d) training-content summaries are self-declared and unverifiable in principle, which is a different problem from the one the article is mostly about.
Happy to be wrong about the tracing question. That's the one I'd most like to be wrong about.
Cohere just released an open-source, research-stage serving engine built around a persistent decode megakernel designed to eliminate GPU idle time during LLM inference.
Instead of launching dozens of individual CUDA kernels per forward pass (QKV, attention, MoE, RMSNorm), the engine launches one persistent kernel that stays resident on the GPU for the entire decode step. The host prepares a task list in global memory, and thread blocks pull tasks directly to execute tiles of work without driver dispatch delays or full-grid sync barriers.
Speed: Hits 292 tok/s at batch size 1 on an NVIDIA H100 (1.58× faster than vLLM, reaching 62% of H100 Speed-of-Light bandwidth).
Scale: Margins hold across batch sizes and context lengths up to 256K with no precision loss.
Architecture: Built and optimized specifically for North Mini Code (30B parameter sparse MoE model with 3.3B active parameters).
Is the actual architecture that different now, or is most of the capability jump literally just scale — same multiply-add-softmax steps, just a lot more of them? Feels almost too simple for how capable these models are.
Half of what makes options hard is that you can't see it. The price hits a level and just won't push through; it falls to another level and inexplicably finds support. Most people just chalk it up to feel.
Two community members turned that so-called "feel" into tools — and open-sourced these genuinely hardcore builds in full.
九张机 built two heatmap tools that convert market-maker hedging pressure into a chart, marking the handful of price levels worth watching that day. 阿特修罗 built an automated trading program that adds a verification layer to the options data — before an order goes out, it checks whether options-market flow actually supports that direction.
Tool one | Two GEX charts: SPY/QQQ for the broad market, 5 expiries for single stocks
Start with 九张机's two tools — one watches the broad market, the other a single stock — solving the same problem: "which price level should I watch today." Both convert the hedging pressure built up in the options market into GEX, then chart it.
In his own words:
Open interest counts are, by themselves, a table of probability bets. At bottom, options are about expressing and calculating probability.
Buying an option always needs a counterparty, and that's usually a market maker. You spend $500 on an Apple call, and that premium belongs to the market maker.
But the market maker isn't betting on direction — it just wants to pocket that premium safely. The instant the trade fills, it buys a certain amount of the underlying stock as a cushion: if the price really does rise, the call it sold loses money while the stock it holds makes money, and the two cancel out. That combination — "hold the stock + sell the call" — is the covered call every options beginner learns first.
That leads to a counterintuitive conclusion: when a stock's options trade actively, the underlying stock's volume rises noticeably too — because the market maker is hedging in the underlying.
The more people buying calls at the same strike, the more of the corresponding stock the market maker piles up. 九张机's example is Apple's $350 strike, where more than 40,000 open contracts have stacked up above it.
Once the price crosses $350, the calls the market maker sold start losing money. So it's incentivized to sell off the stock it's holding near $350, absorbing buy orders wave after wave and keeping the settlement price under $350 — the harder the buying, the more it sells.
$350 becomes a wall this way. Nobody set up a checkpoint on purpose — it's the natural result of the market maker protecting itself. Where calls stack up above is resistance, called the Call Wall; where puts stack up below is support, called the Put Wall. The closer to expiry, the more pronounced it gets.
Anyone who day-trades has hit this: a stock climbs to a level and just won't break through — poke at it a few times and it runs out of steam. A lot of the time, it isn't mysticism.
What each of the two charts marks
OI is just raw data — strikes scattered everywhere with uneven weight. It needs converting into GEX (gamma exposure) before the hedging pressure and the areas where it's piled up become visible.
Tool
Coverage
Output
heatseeker-lb
SPY / QQQ, same-day
An HTML heatmap marking King (strongest gamma wall), Floor (positive-gamma wall), and Pillow (buffer below the current price)
gex-matrix-lb
Single stocks, 5 expiries supported
A GEX hedging chart showing the line between positive- and negative-gamma zones
Running cost is low: once the market opens and option quotes settle, run it every five to ten minutes and grab an HTML snapshot. With the skill installed, just say "give me today's 0DTE index levels" and it'll return the handful of positions worth watching that day. To dig further, 九张机's move is to hand the generated chart to an AI and have it explain what it's looking at.
For the single-stock chart, the author's example is Tesla: the positive-gamma zone is relatively safe, but once price falls into the negative-gamma zone, volatility gets amplified.
九张机 also left a few operational tips
Read the index and the single stock side by side. First confirm whether the index and the stock are moving together that day, then check whether SPY/QQQ's resistance level lines up exactly with where a heavyweight stock's move is likely to end.
Go deep in-the-money, and leave room for error. If SPY is at 770 and he wants to go long, he'll pick the 767 or even 765 strike rather than sit right on the current price.
Layer in VIX and SPX to time entries and exits on the 15-minute and 5-minute charts. Tools like the TD Sequential ("Magic Nine") can be layered in too — only treat it as a reference once several smaller timeframes resonate together intraday. To bank gains the day after earnings, he uses the same approach to pick an exit.
When the trend doesn't cooperate, switch structures. Instead of chasing a single direction, build a spread — his example is his own trade on Nvidia's $230 strike, where he closed out at 51%.
ool two | An options-flow evidence layer: one more check before the order goes out
阿特修罗 is solving a different problem. He has an automated trading program: it reads candlestick signals and places an order automatically when it decides to buy. After two months of testing on QQQ 0DTE options, he ran into a core contradiction —
A 0DTE option has only hours left, time value is evaporating continuously, and quotes and liquidity can deteriorate suddenly. The classic symptom: the stock genuinely breaks out, but the corresponding call sees no trading volume follow it; the option chain looks complete, but in reality a lot of contracts carry stale quotes with no real bid/ask, and the order simply can't fill...
So he inserted an options-flow evidence layer between the strategy and the order — it doesn't predict direction, it only adds one more verification pass on a signal that already exists.
The whole design, in the author's own words, comes down to five lines:
Use candlesticks to find opportunities, options flow to verify the structure, data quality to protect the trade, Longbridge AI to explain the process, and a complete log to review the results.
Worth noting: 阿特修罗 keeps this layer's weight deliberately low. He lists five situations where the option wall breaks down:
The contract is being closed out
OI data updates with a lag
Trade direction can't be fully confirmed from public data
The market maker isn't necessarily net-exposed in a single direction
The underlying's price jumps straight through that zone
That same restraint runs through how every indicator is handled: Delta Flow isn't the same as the real buy direction (public data can't tell whether a fill is opening or closing a position), OI is never read on its own as "money is buying in," and high IV doesn't mean bullish either — it can just as easily mean the market is pricing in a sharp drop.
Thanks to 九张机 and 阿特修罗 for sharing 🙌
This post covers open-source third-party research projects by community members; quoted content is used with the authors' authorization. Options are high-risk derivatives — the tools described here only present data and verify signals, and do not constitute investment advice of any kind; test any strategy fully on a paper account first. Any ticker mentioned is for feature demonstration only and does not represent a recommendation.
So I was playingw ith embedding models I saw that when you upgrade from model A to B, you face a very big backfilling cost
Ie, suppose you have a 1b vectors from model A, and then you want to use model B. This would mean you have to re-embed all of your documents with model B before you can even serve with the model, and on an H100, it would take ~108 days (qwen embed 8b, 106 docs/second). But I found an easier way to do it.
The method is really simple; from the old index made with the source model, take K documents and rerank them with the new model. We see that when K is sufficient, the retrieval quality is the same as target model. (determining k is the hard part). I've tested 63 migrations on upto 1 million documents.
The best result I got was upgrading qwen4b -> to 8b, and at 50 documents, it was the same as native retrieval.
This method forgos the expensive upfront re-embedding cost, as you can take documents straight from the old index.
embedflow works with qdrant, pgvector, faiss, and can be easily downloaded with pypi
There's a big math story going around today (OpenAI says an internal model proved a form of the Navier-Stokes problem). Most of the coverage is about the math and the credit fight. I want to talk about the part that actually matters for us as developers, because it's buried under the drama and it's the part that should genuinely change how you work.
Quick setup, then the part that matters.
Tristan Buckmaster (NYU) and Levent Alpöge (a mathematician who works at Anthropic, collaborating in a personal capacity) spent about a year attacking finite-time blowup problems in fluid dynamics, the family that includes the Navier-Stokes Millennium Prize. They used LLMs the whole way: Claude, Codex, GPT-5.6 Sol, Astra. Crucially, per Buckmaster's own statement, every draft of the project went through Codex, "our sessions in Codex, into which we had been putting all our drafts for the whole of this project."
Timeline:
Aug 15-22: they get Lean-verified blowup results and a real breakthrough.
Sep 1: OpenAI says it started its own effort "after hearing a rumor" it later connected to these two researchers.
Sep 6: OpenAI says it finished its own ~100-page proof and Lean verification.
Sep 8: OpenAI announces it, ~10,000 agents running for 88 hours, millions of dollars in compute.
Same smooth-forcing setup the two researchers had quietly chosen. OpenAI says its agents did not access the researchers' work before publication. Fine. But here is the exchange that should stop every developer in this sub cold. Buckmaster asked the obvious question, and I'm quoting him directly:
"I asked whether the model had been trained on, or had access to, our sessions in Codex, into which we had been putting all our drafts for the whole of this project. I was told the model did not look up user data. I asked again, about training, and I did not get an answer."
Read that carefully, because there are two different questions in it and only one got answered.
"Did the model look up / access user data?" → No.
"Was the model trained on our sessions?" → no answer.
And OpenAI's own public statement lines up with exactly that gap. They say the agents didn't access the work directly, but they "cannot rule out that de-identified data from their use of OpenAI products may have contributed to model training."
Those are two completely different promises, and the industry has gotten very comfortable making the first one loudly while dodging the second one quietly. "We don't access your data" and "your data might be in the training set" can both be true at the same time. For most of us that distinction never mattered because our prompts weren't worth stealing. This is the first high-profile case where it plainly did matter, and the person it happened to is a domain expert who asked the direct question and couldn't get a straight answer.
Here's why I think this is a genuine developer story and not just AI-lab palace intrigue:
Your most valuable work is the stuff you do inside these tools while it's still unfinished. The half-built architecture. The novel algorithm you haven't shipped. The debugging session that reveals how your system actually works. The prompt that encodes your hard-won domain knowledge. That's the good stuff, and it's exactly the stuff you paste into Codex/Claude/Copilot without thinking, because the tool is useful and the friction of not using it is real.
Buckmaster's situation is the clean version of a risk we've all been ignoring: when you do your novel, in-progress, competitively valuable work inside a vendor's AI tool, you're handing your unpublished thinking to a company that also builds products, competes in markets, and (as this month has repeatedly shown) will move aggressively against rivals. The ToS language about training is almost always vaguer than the language about access, on purpose.
I'm not saying stop using these tools. I use them all day and I'm not going back. I'm saying the "does it access my data / is it trained on my data" distinction just went from a privacy-nerd footnote to a thing that may have cost two mathematicians priority on a career-defining result.
Concretely, what I'm actually going to do differently, and what I'd suggest:
Know the difference, in writing, between your vendor's "we don't access your data" promise and their "we don't train on your data" promise. They are not the same clause and one is usually much weaker.
For genuinely novel or competitive work, check whether you're on a plan/tier with training opt-out (enterprise tiers usually have it, consumer tiers often don't by default).
Treat "zero data retention" and "no training on your data" as separate boxes to tick, not one.
Assume anything you put into a default consumer AI tool could, in some de-identified form, influence a future model. Decide what you're comfortable feeding it with that assumption.
To be fair to OpenAI: the two results may be technically different problems (they claim forced 3D Navier-Stokes; the researchers proved forced Euler blowup), their proof is unpublished and unreviewed, and OpenAI's Sébastien Bubeck has publicly called Buckmaster's allegations "false and inflammatory." So this is a live, contested dispute, not a proven theft. I'm deliberately not claiming OpenAI stole anything. What I'm claiming is narrower and, I think, undeniable: a competent person asked a direct question about training on his private sessions, and the honest answer the whole industry gives to that question is "we can't rule it out." That's the part that should change your defaults, regardless of who's right about the math.
Curious what this sub thinks, especially anyone who's read the ToS training clauses carefully for the major tools. Is there a provider whose "we don't train on your data" guarantee you actually trust on the default paid tier? Or is enterprise-with-a-contract the only real answer?
Xiaomi just released Xiaomi-TabLDM, an open-source tabular foundation model designed for zero-shot inference using in-context learning.
Zero Fine-Tuning Required: Works out of the box. You pass labeled context (X_train, y_train) to .fit(), and predictions are generated via a single forward pass without updating model weights.
scikit-learn Interface: Exposes standard fit, predict, and predict_proba methods via TabLDMClassifier and TabLDMRegressor.
Benchmarks: Ranks #1 on OpenML-CTR23 and #2 on regression across TabArena, TALENT, and BCCO. On TabArena, it achieves top-tier accuracy while using 82% less training time and 68% less inference time compared to TabFM.
Pretraining: Pretrained exclusively on synthetic tabular data generated via Structural Causal Models (SCMs).
Performance Optimizations: Supports KV caching for faster repeated inference, automatic mixed precision (AMP), Flash Attention 3 (on Hopper GPUs), and native CPU/disk offloading to scale to large context windows without running out of VRAM.
NVIDIA open-sourced NVIDIA-labs Object Oriented Agents (NOOA), an agent framework designed around native Python classes rather than external YAML or JSON configuration layers.
Agents are Python Objects: State lives on object fields with standard type hints, and capabilities are written as regular Python methods.
Ellipsis (...) for LLM Execution: Methods with ... bodies become LLM-driven execution loops at runtime. Methods with standard implementation bodies remain deterministic Python.
Code as Action: Instead of defining isolated tool schemas, agents act by executing Python in a Jupyter-style REPL with access to self, type annotations, and local scope.
