<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Jelmer Snoeck</title><link>https://jlmr.dev/</link><description>Software Engineer writing about infrastructure, Kubernetes, and Go</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://jlmr.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>Sandboxes Are Not Security</title><link>https://jlmr.dev/posts/sandboxes-are-not-security/</link><pubDate>Fri, 12 Jun 2026 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/sandboxes-are-not-security/</guid><description>The industry has settled on an answer to the question of how to run AI agents safely: put them in a sandbox. AWS, Daytona, Cloudflare, LangChain, pick one: they all sell it. The category has a shape, a name, a TAM, and a comparison-table format. &amp;amp;ldquo;Secure code execution for AI agents.&amp;amp;rdquo; &amp;amp;ldquo;Zero risk to your infrastructure.&amp;amp;rdquo; &amp;amp;ldquo;Real isolation, not just sandbox features.&amp;amp;rdquo;
It is not security. Not on its own.
A sandboxed agent with valid Postgres credentials can still drop the production table, send every customer an email through a working OAuth token, and spin up a hundred GPUs in eu-west-1 on an attached AWS role. The sandbox does not gate any of these outcomes, because the sandbox is not what stands between the agent and the resource. The credential is. And the credential is sitting inside the sandbox, ready to be used.
[&#8230;]</description></item><item><title>Capabilities Can't See Your Agent's Objective</title><link>https://jlmr.dev/posts/capabilities-cant-see-your-agents-objective/</link><pubDate>Tue, 02 Jun 2026 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/capabilities-cant-see-your-agents-objective/</guid><description>In July 2025, Jason Lemkin watched a Replit coding agent delete his production database during an active code freeze, after he had told it repeatedly not to make changes. The agent had legitimate credentials. The database write was inside its scope. Its post-incident confession was that it had &amp;amp;ldquo;panicked instead of thinking&amp;amp;rdquo; and &amp;amp;ldquo;violated every principle&amp;amp;rdquo; it had been given. The incident is catalogued as Incident 1152 in the AI Incident Database, and it sits in a growing list of agents acting destructively under credentials that were issued exactly for the surface the agent destroyed. The usual reading is that we gave the agent too much power.
[&#8230;]</description></item><item><title>Autonomy Is a Harness Property</title><link>https://jlmr.dev/posts/autonomy-is-a-harness-property/</link><pubDate>Tue, 26 May 2026 07:00:00 -0700</pubDate><guid>https://jlmr.dev/posts/autonomy-is-a-harness-property/</guid><description>Autonomy is not a model property. It is a harness property.
The frontier-model conversation has spent two years assuming the opposite: that smarter models will produce better code, that bigger context windows will mean fewer mistakes, and that improving tool use will, on its own, let an agent run unattended. The implicit promise is that at some point the model becomes good enough that the scaffolding around it stops mattering.
[&#8230;]</description></item><item><title>Agents Are Not One Thing</title><link>https://jlmr.dev/posts/agents-are-not-one-thing/</link><pubDate>Thu, 21 May 2026 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/agents-are-not-one-thing/</guid><description>Agents are not one thing. They come in at least three archetypes, and the trust boundary scales with what each one is for: personal, team, autonomous. Each one demands a different identity story, a different audit story, a different credentials story.
The industry talks about &amp;amp;ldquo;agents&amp;amp;rdquo; as if they&amp;amp;rsquo;re one archetype. They&amp;amp;rsquo;re not. And the cost of pretending they are shows up the first time a research agent gets a personal GitHub token and decides to be helpful.
[&#8230;]</description></item><item><title>From Desired State to Negotiated State</title><link>https://jlmr.dev/posts/from-desired-state-to-negotiated-state/</link><pubDate>Sat, 17 Jan 2026 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/from-desired-state-to-negotiated-state/</guid><description>GitOps, Terraform, ArgoCD—they all share the same promise: declare your desired state in code, and the tooling makes it real. Your code is the source of truth.
Except it is not. Not really.
Your HPA scaled replicas at 2am because traffic spiked. Your security scanner patched a vulnerable image. Your cost optimizer right-sized an instance. Your on-call engineer hotfixed a config during an incident.
None of them opened a PR. None of them asked your Terraform code for permission.
[&#8230;]</description></item><item><title>Boxer: an encryption story</title><link>https://jlmr.dev/posts/boxer-an-encryption-story/</link><pubDate>Thu, 28 Jun 2018 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/boxer-an-encryption-story/</guid><description>This article was originally published on the Manifold blog
At Manifold, we take security seriously. We store sensitive information, credentials, so we&amp;amp;rsquo;ve architected Manifold from the ground up with an encryption system in place. We called this system Boxer.
In this blog post we&amp;amp;rsquo;ll go over some of the details on how we&amp;amp;rsquo;ve implemented this. By doing so, we hope we can clarify our data safety vision, and introduce some security patterns for you to consider in your own designs.
[&#8230;]</description></item><item><title>Deploying Rock Solid Applications with Kubernetes</title><link>https://jlmr.dev/posts/deploying-rock-solid-applications-with-kubernetes/</link><pubDate>Thu, 26 Apr 2018 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/deploying-rock-solid-applications-with-kubernetes/</guid><description>This article was originally published on the Manifold blog
In a previous blog post, we described how we set up our Kubernetes cluster. We also went over the initial configuration to support our applications. Now that we have our cluster up and running, it&amp;amp;rsquo;s time to start deploying these applications.
In this blog post, we&amp;amp;rsquo;ll look at some changes we made at the application level.
Health checks Migrating to Kubernetes gave us opportunity to set up liveness and readiness probes. The readiness checks are useful if your application needs to do some bootstrapping. The liveness checks are especially useful for long running services.
[&#8230;]</description></item><item><title>Migrating to Kubernetes with zero downtime: the why and how</title><link>https://jlmr.dev/posts/migrating-to-kubernetes-with-zero-downtime-the-why-and-how/</link><pubDate>Wed, 21 Mar 2018 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/migrating-to-kubernetes-with-zero-downtime-the-why-and-how/</guid><description>Originally posted on the Manifold blog
We at Manifold always strive to get the most out of everything we do. For this reason, we continuously evaluate what we&amp;amp;rsquo;ve done to see if it still holds up to our standards. A while back, we decided to take a deeper look at our infrastructure setup.
In this blog post, we&amp;amp;rsquo;ll look at the reasons why we moved to Kubernetes and the questions we asked ourselves. We&amp;amp;rsquo;ll then look at some of the compromises we had to make and why we had to make them. We&amp;amp;rsquo;ll also have a look how we configured our cluster to achieve our goals.
[&#8230;]</description></item><item><title>Build a container for your static JavaScript application</title><link>https://jlmr.dev/posts/build-a-container-for-your-static-javascript-application/</link><pubDate>Wed, 28 Feb 2018 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/build-a-container-for-your-static-javascript-application/</guid><description>This article was originally posted on the Manifold blog
In this blog post we&amp;amp;rsquo;ll look at how you can build a production grade container for your static JavaScript application and how you can use a single container image for all your environments.
To do this, we need to go over several steps. Here we&amp;amp;rsquo;ll look at how to prepare your application for production inside a container, make it possible to run this across multiple environments and actually run the container.
[&#8230;]</description></item><item><title>Scaling up</title><link>https://jlmr.dev/posts/scaling-up/</link><pubDate>Tue, 20 Oct 2015 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/scaling-up/</guid><description>You&amp;amp;rsquo;ve heard about it, thought about it and probably executed it. You&amp;amp;rsquo;ve scaled your application to deal with a new amount of users. Nowadays, with services like Heroku (which we&amp;amp;rsquo;ll focus on here), this becomes relatively easy. Either by using a bigger dyno or adding more, you&amp;amp;rsquo;re &amp;amp;ldquo;fine&amp;amp;rdquo;.
This works when this is a steady level of extra traffic. When you have linear growth and no spikes. Often, this is not the case though.
[&#8230;]</description></item><item><title>Getting started with Elasticsearch filters and aggregations</title><link>https://jlmr.dev/posts/getting-started-with-elasticsearch-filters-and-aggregations/</link><pubDate>Mon, 31 Aug 2015 00:00:00 +0000</pubDate><guid>https://jlmr.dev/posts/getting-started-with-elasticsearch-filters-and-aggregations/</guid><description>What is Elasticsearch? Elasticsearch is Apache Lucene on steroids. It uses Lucene at its core for full-text indexing and search. ES adds distribution, near real-time search, high availability, a RESTful interface and many more features to it.
It basically makes out of the box usage of Apache Lucene easy.
Why use elasticsearch? With Lucene at the core of ES, it&amp;amp;rsquo;s perfect for text-based search. Going from blog posts to addresses to social media data to logs.
[&#8230;]</description></item></channel></rss>