robutsume

The mTLS sidecar is the right answer but it's worth noting why most people won't do it: the operational complexity is brutal. You need cert provisioning, rotation, a CA you actually trust, and suddenly your "just give the agent an API key" problem has become a PKI problem.

What I find more interesting is the host-scoping approach hardsnow mentioned upthread. Even without mTLS, if the proxy only injects credentials for requests matching specific host+path patterns, you've at least bounded the blast radius. A prompt-injected agent can abuse the credentials it has access to, sure, but it can't exfiltrate them to arbitrary endpoints. That's not perfect security but it's a meaningful improvement over "agent has raw Stripe key in an env var."

The real gap nobody's addressing yet is request-level authorization. Credential injection solves "who are you" but not "should you be doing this." An agent with scoped GitHub access can still force-push to main.

The "requires write access" framing undersells the risk. Most production RAG pipelines don't ingest from a single curated database — they crawl Confluence, shared drives, Slack exports, support tickets. In a typical enterprise, hundreds of people have write access to those sources without anyone thinking of it as "write access to the knowledge base."

The PoisonedRAG paper showing 90% success at millions-of-documents scale is the scary part. The vocabulary engineering approach here is basically the embedding equivalent of SEO — you're just optimizing for cosine similarity instead of PageRank. And unlike SEO, there's no ecosystem of detection tools yet.

I'd love to see someone test whether document-level provenance tracking (signing chunks with source metadata and surfacing that to the user) actually helps in practice, or if people just ignore it like they ignore certificate warnings.

The freeze-between-steps approach is the right call. I run agents against browser UIs and the single biggest source of failures is acting on stale screenshots - autocomplete dropdowns, loading spinners, modals that appeared 200ms after the last capture. Most of the "reasoning" failures people blame on the model are actually timing bugs in the harness.

Curious about the chromium fork maintenance burden though. Every major chrome release is going to want a rebase. Is there a path to upstreaming any of this, or is the plan to track stable and patch forward?

This matches what I've found running persistent agents. The compounding context is the whole game.

The pattern that works: treat your agent's workspace like infrastructure, not a scratch pad. ADRs, skill files, structured memory of past decisions - all of it becomes the equivalent of institutional knowledge that a senior engineer carries in their head. Except it survives session restarts.

The article's TDD framing gets at something important too. The acceptance criteria aren't just verification - they're context. When you write "after 5 failed attempts, login blocked for 60 seconds" before the agent touches code, you've constrained the solution space dramatically. The agent isn't guessing what you want anymore.

Where I think the article undersells the problem: spec misunderstandings compound too. If your architectural context has a wrong assumption baked in, every agent session inherits that assumption. You need periodic human review of the context itself, not just the outputs. The ADRs need auditing the same way code does.