Rust & AI Weekly #9: where the boundary is drawn
Welcome back to Rust & AI Weekly, the curated, vetted sweep of crates and tools showing up where Rust meets AI. Today's issue: a Rust sandbox whose manual names AI/ML workloads as the thing to contain, the maintainer of rustls publishes a memory-safe SSH server after 20 months and says plainly that it is not ready, and rama's release-train promise from issue #4 comes due. The theme this week is where the boundary is drawn: every entry below picks a line between two parts of a system and then puts a mechanism on it instead of a convention. Last week's genre was making the wrong thing unrepresentable inside your own code. This week's is drawing the edge of your code and deciding what is allowed to cross it, which turns out to be the question nobody asks before handing an agent a shell.
(Status lines reflect public signals as of August 24, 2026; stars and downloads are approximate and move fast.)
This week's radar: four new entries join the map, and rama moves from Assess to Trial. Explore the interactive version.
Pick of the week
syd 3.58.0 — Ali Polatel's "rock-solid application kernel" leads this issue for a reason that has nothing to do with novelty and everything to do with a question most teams are currently answering by accident. You gave a coding agent permission to run shell commands. What confines it? On most machines the honest answer is your user account, which is to say: your SSH keys, your cloud credentials, your ~/.aws, your whole home directory, and the network. Syd is the most developed Rust answer to that question that exists today, and it has been quietly shipping for years while the agent conversation was elsewhere. The architecture is the interesting part. Rather than trapping a syscall and then letting the sandboxed process continue it, Syd implements a subset of the Linux kernel interface in user space and executes the syscall on behalf of the process, which is what lets it sidestep the TOCTTOU race that has embarrassed a generation of interposition sandboxes (the project's own write-up on this, T☮CT☮U||GTF☮, is the best short tour of why Linux sandboxing is hard). It composes Seccomp-BPF and Seccomp-Notify with Landlock up to ABI 7 and optional namespaces, and it runs as an ordinary unprivileged user: no SETUID like Firejail, no privileged kernel context like the eBPF-based tools. The sandbox categories read like pledge(2) if pledge(2) had grown a filesystem policy, an application firewall with IP blocklists, path masking and hiding, append-only paths, trusted path execution, and transparent file encryption. The line that should stop an AI team mid-scroll is in the capability list: ioctl sandboxing exists to contain AI/ML workloads while still letting a process reach PTY, DRM and KVM safely. That is a maintainer who thought about GPU access as a permission rather than a given. Stewardship signals are real rather than hopeful: 195 releases, roughly 495k downloads a month, packaged in Alpine, Arch, Exherbo and Gentoo, an OpenSSF best-practices badge, CI across eight architectures, and a syd-oci build that slots under Docker, Podman and CRI-O. Two honest caveats. It is GPL-3.0, so it is a tool you run and not a library you link into a product, and it needs Linux 5.19 or newer, which rules out the older LTS kernels some fleets are still on. Go deeper with Polatel's FOSDEM 2026 talk, Syd: Writing an application kernel in Rust, which is the design rationale rather than the feature list.
Maintenance: actively developed, effectively solo but long-running (Ali Polatel; 195 releases; OpenSSF best-practices badge) · Latest: v3.58.0 (Aug 2026) · Adoption: Trial; distro-packaged and heavily downloaded, so the risk is not abandonment but policy authoring, and the way to start is Pandora learning mode against one agent workload rather than a hand-written profile
Security boundaries
OxiSH — Dirkjan Ochtman announced a memory-safe SSH server he has been building for 20 months, and the announcement is a small masterclass in how to publish infrastructure. Start with why the target is worth it: SSH servers hit all three of Prossimo's risk criteria at once, being nearly universal, sitting on a security boundary, and performing a critical function, and OpenSSH is decades of C that still ships memory-safety fixes. Then the credentials, which are not in doubt: Ochtman maintains rustls, Quinn and Hickory DNS, and he explains that he looked at russh first and started over because it carried old crypto primitives in a monolithic design. The build reflects a consistent taste for narrow surfaces: a sans-I/O protocol core with Tokio bolted on the outside (the same design that made webrtc-rs worth a Trial verdict back in issue #7), crypto behind a swappable backend so you pick graviola for an easy build or aws-lc-rs for portability and a FIPS mode, and a deliberately tiny algorithm set: hybrid post-quantum mlkem768x25519-sha256 key exchange, Ed25519 and ecdsa-sha2-nistp256 keys, AES-128-GCM, SHA-256, and nothing else, because every extra algorithm is attack surface. He reviewed historic OpenSSH vulnerabilities to check that the design avoids the non-memory-safety mistakes too. And then the part that earns the trust: he tells you it is not ready. No forwarding of any kind, no scp or sftp, no password authentication, no Windows, and no funded external audit. Full OpenSSH compatibility is explicitly not a goal. Bug-for-bug parity is how memory-safe rewrites die, so declining it is the right call, but it does mean the adoption question is not "is this good" but "which of my hosts only needs public-key login and a shell". Trifecta Tech Foundation contributed core platform work earlier this year on an investment from the Sovereign Tech Agency, which is worth noting on its own: the funding model for this kind of unglamorous, load-bearing software is finally producing code.
Maintenance: newly public after 20 months (Dirkjan Ochtman, of rustls/Quinn/Hickory DNS; Trifecta Tech Foundation contributed, Sovereign Tech Agency funded) · Latest: announced Aug 13, 2026; tested in CI on Linux and macOS against OpenSSH clients · Adoption: Assess; the author is about to dogfood it on his own server and is asking what would be needed to replace OpenSSH in your environment, so the highest-value move this week is filing that issue rather than deploying anything
Networking and proxies
rama 0.4.0 — this is the entry I have been waiting to write. When rama 0.3 landed in issue #4 I gave it Assess and said the thing that would move it up the radar was whether the newly promised two-to-eight-week release train actually held, because a five-year gestation followed by one big release tells you nothing about cadence. 0.4 shipped six weeks later. Assess to Trial. Release discipline is the cheapest stewardship signal to promise and the most expensive to fake, and Plabayo now has one data point that is a fact rather than an intention. The release itself is squarely on this week's theme. Rama gained system-proxy support and Proxy Auto Configuration, which means it has to execute PAC files, which are JavaScript, which means running untrusted code from your system configuration. Chrome solves that with a separate OS process. Glen's team put the JavaScript runtime inside a wasmtime sandbox instead, so a crashing or hostile PAC script cannot take down the process embedding it, and any Rama-based binary gets that isolation without shipping a second executable. That is a boundary drawn at the right place by someone who thought about the failure mode first. The rest is solid infrastructure work: rama-ttrpc for the lighter-weight TCP-based RPC that container runtimes use, a rama-grpc-macros crate that generates gRPC clients and servers from your own Serde-driven codecs with no .proto at all, full HTTP_PROXY/ALL_PROXY/NO_PROXY environment handling, protocol peekers that now fail fast instead of stalling to a timeout on things like PING, and a HAR exporter that streams to disk rather than buffering the whole conversation in memory. For anyone running an LLM gateway, that last pair matters more than it sounds: the traffic you most want to record is exactly the traffic too large to hold in RAM. Commercial partners already run rama for LLM harnesses and AI proxy gateways, and the Trial caveat is unchanged in kind: minor versions still break, connector service traits changed signature again in this one, so pin your version and read the changelog before you upgrade.
Maintenance: actively maintained (Plabayo, full-time; Glen De Cauwsemaecker writing the releases) · Latest: v0.4.0 (Aug 21, 2026), six weeks after 0.3, inside the promised window · Adoption: Trial, upgraded from Assess in issue #4 on the strength of the cadence holding; the partners in AI proxy gateways are the reference workload, and breaking minors remain the price of admission
Build and browser boundaries
tokio_with_wasm 0.9.0 — This Week in Rust 665's Crate of the Week, self-suggested by Dong-Hyun "Danny" Kim of Cunarist. The pitch is one sentence: a single tokio codebase that also runs in a browser. The browser is the most restrictive boundary in common use, with no threads to speak of, no filesystem, no sockets, and a different notion of time, so plain tokio does not work there. This crate provides the tokio module surface with web-API-backed implementations behind it, so spawn and spawn_blocking both do something sensible and your #[tokio::main] code compiles for wasm32. For anyone building AI tooling, this is the plumbing under a question that keeps coming up: can the same Rust that runs your inference glue or your agent loop on the server also run in the user's tab, for privacy, latency, or cost reasons. The honest framing is that this is a compatibility shim, not tokio. Where the browser's semantics differ from a native runtime, the shim's semantics differ too, and code that quietly depends on real thread parallelism or on blocking will behave differently rather than fail to compile. Treat the boundary as real and test on both sides of it. Roughly 1.6 million all-time downloads and a reference consumer in Cunarist's own Rinf, the Rust-in-Flutter bridge, so it is exercised rather than theoretical.
Maintenance: actively maintained, small team (Dong-Hyun "Danny" Kim / Cunarist; also maintains Rinf) · Latest: v0.9.0; surfaced as Crate of the Week in This Week in Rust 665 (Aug 19, 2026) · Adoption: Assess; a well-scoped shim with real usage, but the differences from native tokio are semantic rather than syntactic, so pilot it on a component you can test in a browser harness
cargo-pgo 0.2.9 — this one arrives sideways, from the Go side of the fence. Daniel Lemire published Profile-Guided Optimization in Go this month, measuring up to 4.7% more throughput on encoding/json parsing and, more usefully, training profiles on three different JSON documents and testing each build against all three to see how well a profile transfers to workloads it never saw. Go ships PGO in the toolchain. Rust's seat at that table is Jakub Beránek's cargo-pgo, which wraps the instrument-run-merge-rebuild dance, and BOLT on top of it, into a handful of subcommands instead of a research project. It is worth naming this week because the compiler just stabilized -Zprofile-sample-use for sample-based profiles, and because the Cargo hints.min-opt-level RFC approved in issue #8's language watch is the same instinct from the other direction. Beránek also runs the rustc performance triage that shows up in Language watch below, which is the kind of overlap that tells you the tool comes from someone who measures for a living. The gap is real and worth stating plainly: in Go this is a flag, in Rust it is a third-party subcommand, BOLT is Linux-only, and none of it does anything without a workload representative enough to profile. If your inference server or tokenizer is CPU-bound and you have never tried this, an afternoon is the whole cost of finding out.
Maintenance: maintained, solo (Jakub Beránek / Kobzol, who also runs rustc perf triage) · Latest: v0.2.9 · Adoption: Trial; the technique is proven (rustc itself is PGO-built) and the tool is thin enough to walk away from, but the profiling workload is the actual project, not the build config
Language watch
extern "custom"is stabilized in the compiler — PR 158504 landed this week, three weeks after the RFC was approved in issue #8's language watch. Calling conventions the compiler does not know about become an explicit, declared boundary rather than an inline-assembly guess.- Cargo's supply-chain pair is in final comment period —
min-publish-ageandcargo-lintsare both up for stabilization, which is the follow-through on the changes noted in issue #8. If you run a Rust supply chain, this is your window to object before the interface freezes. core::num::Complexlanded — PR 158885. A complex number type incoreis small news for most people and quietly useful for anyone doing signal processing or FFTs one crate below their model.- The perf picture flipped — this week's triage by Jakub Beránek reports zero regressions, six improvements, and secondary benchmarks down as much as 16% on the back of next-trait-solver work. Last issue's headline was a 3.0% Polonius regression; the same machinery is now paying it back.
In brief
GPU Offload in Rust: Portable, Safe, and Fast — an arXiv paper landing in the same week as the offload! macro in the standard library, which is a useful pair if you are arguing for Rust in an accelerator-adjacent codebase · A critical review of Xilem in 2026 — an unusually specific critique of the Rust GUI architecture everyone cites, worth reading before you bet a product on it · Four levels of in-place initialization — Yoshua Wuyts on the design space, and relevant to anyone allocating tensors they would rather not copy · Zero-copy wgpu rendering inside an Electron app — the Rust-under-JavaScript seam, done without a round trip through the CPU · The Lint That Would Have Caught It Is Off by Default — short, and the sequel to last week's argument about types over review · From Go to Rust — Roland, whose git-cache-proxy was in issue #8, writes the migration up from the practitioner's side · Zerocopy with Joshua Liebow-Feeser — a podcast on the crate that made "reinterpret these bytes" a safe operation · sysknife — asking for help exposing its read-only actions as MCP tools without exposing AptUpdate, which is a well-drawn permission boundary and an unusually clear first issue · Reducing target directory size on nightly — -Zembed-metadata=no is on by default on nightly Cargo now; if your CI cache is the bottleneck, watch this one.
Elsewhere
- Daniel Lemire's Profile-Guided Optimization in Go is the most useful PGO write-up I have read this year, mostly because he tests whether a profile transfers to documents it was not trained on, which is the question that decides whether PGO survives contact with production. The Rust pairing is above: cargo-pgo, plus this week's
-Zprofile-sample-usestabilization. The gap is that Go made this a toolchain flag and Rust has not. Verdict on the Rust side: Trial. - Go 1.27 is one release candidate away, bringing generic methods and a goroutine leak detector in
runtime/pprof(rednafi has the tour of what it can and cannot do). Rust has no equivalent in the standard profiler: the nearest thing is tokio-console, a separate tool you attach to an instrumented binary, and it tells you about tasks rather than leaks. No first-class Rust answer yet, and given how many agent loops are long-lived spawned tasks that nobody ever joins, it is a real gap rather than a nice-to-have. - Appwrite rewrote its CLI from TypeScript to Go and published why Go and not Rust, by Chirag Aggarwal. Worth reading straight rather than defensively. Their distribution constraint (still shipping on npm as per-platform binaries) is one Rust handles fine, so the decision came down to team familiarity and iteration speed, which is a legitimate reason and one that no amount of benchmark wins overrides. Note it for the next time someone in your org argues language choice purely on merits.
A thought for the week
A boundary nobody can enforce is just a naming convention. That is the sentence I would write on the whiteboard after reading this week's releases together. Syd draws the line at the syscall and executes on your behalf, so "the agent may not read ~/.ssh" becomes a mechanism instead of a hope. OxiSH draws it at the protocol and shrinks the algorithm list on purpose, because every option you support is a boundary you have to defend. Rama draws it around a JavaScript interpreter, because the PAC file your IT department ships is code you did not write. extern "custom" draws it at the ABI and makes you declare it. In each case the same thing happened: somebody found a place where two parts of a system met on trust, and replaced the trust with a check.
Most engineering organizations have the opposite pattern, and it is invisible until it isn't. The boundaries are drawn in documents. The service that "shouldn't" write to that table. The script that "only" runs read-only queries. The agent that has your credentials because provisioning it a scoped set was going to take a sprint. None of those is enforced; all of them are conventions with good intentions attached, and they hold exactly until someone new, or something automated, does the obvious thing. Coding agents did not create this problem, they just industrialized it, because an agent is a very fast, very literal new hire who has read none of your documents and has all of your permissions.
So here is the question worth taking to your next planning session: name the three boundaries your system depends on most, and for each one, say what would physically stop a violation. If the answer is "code review", "the runbook", or "everyone knows", you do not have a boundary. You have a naming convention, and this week four different maintainers showed you what the upgrade looks like.
Before I go
Rust Bytes led its August 18 issue with Polonius, which was in this radar's language watch last week, so I will point you at the other thing they surfaced instead: Predrag Gruevski's Protecting the Rust standard library from accidental breakage. It is nominally about std, and it is really about the fact that your library's public surface is a promise you make whether or not you meant to make it. If you maintain anything other teams depend on, the tooling argument in there applies to you at a smaller scale.
Also: RustConf is two weeks out in Montreal, September 8 to 11, with the Rust Teams Health Summit alongside it, and Oxidize follows in Berlin on September 14. And fearless_simd's 1.0, flagged in issue #8, is still booked for early September. If you had an API objection, this is the last quiet week to raise it.
That's the issue. Got a Rust+AI crate or tool I should feature next week? Reply and tell me; reader picks shape the list.
Keep shipping, Decebal
