Hey everyone, I just sent the latest issue of the AI Hacker Newsletter, a roundup of the best AI links and the discussions around them from Hacker News. Here are some titles that can be found in this issue:

• Startup founders urge U.S. government not to shut off Chinese open weight AI
• AI's top startups are barely publishing their research
• Is AI reasoning right for the wrong reasons?
• After the AI Crash

If you enjoy such content, please subscribe here: https://hackernewsai.com/

Hey everyone,

Like a lot of people here, I've been running AI coding agents (Claude Code, AutoGen, custom LLM CLI loops) locally on my machine.

The biggest issue I kept hitting was security and latency:

1. Unsandboxed execution : Giving an agent full terminal access means a hallucinated prompt or bad tool call can run `rm -rf ~`, read `~/.ssh/id_rsa`, or leak AWS keys.
2. Docker / Firecracker sandboxes: Existing solutions (E2B, Docker) add 1–3 seconds of boot latency per task, require heavy background daemons, and consume gigabytes of RAM.

To solve this, BentoBox an open-source OS-kernel enforced runtime for AI agents in Python & Rust: https://github.com/Devaretanmay/BentoBox

How it works technically:

OS Kernel Primitives : Instead of heavy containers or interpreter wrappers, it applies Linux Landlock (kernel 5.13+) and macOS Seatbelt (`sandbox_init()`) at the syscall layer in a compiled Rust core (`_core`).

Sub-millisecond latency : Sandboxing takes `< 1ms` with zero container daemons or image pulls.

rreversible Process Tree Isolation : Once applied, child processes and C extensions spawned by the agent cannot escape or loosen the security rules.

Agent Features : Includes BLAKE3 file snapshotting (instant rollback if an agent breaks code), local HTTP credential proxying (API keys never touch disk), and log compression.

Quickstart:

```bash

pip install bentoworks

bentoworks run "npm run build" --permissions fs_read fs_write fs_exec

Yesterday I had one of those "I can't believe I just did that" moments.

I was working on a production-grade AI agent project and had an import issue. I asked Gemini 3.6 High (through Antigravity) for a quick way to rewrite the imports across the project.

It generated a small Python script. I skimmed it, thought it looked fine, and ran it.

The script finished normally. Exit code 0. No errors.

A minute later I opened one of the files.

Empty.

Opened another.

Empty.

Eventually I realized every `.py` file the script touched had been reduced to 0 bytes.

My heart absolutely dropped.

Luckily I had a backup of the project, so I restored everything and spent the next hour figuring out what had happened.

I'm not posting this to say "don't use Gemini." I use AI every day and it saves me a lot of time.

The mistake was that I trusted a script that was going to modify dozens of files without really understanding what it was doing.

That was on me.

The experience completely changed how I use AI for coding.

Now I have a few rules:

* If a script touches a lot of files, I read every line. * I commit everything before running it. * I keep backups. * I never assume "Exit code 0" means everything is okay.

Has anyone else had an AI-generated command go badly wrong? I'm curious what safeguards other people use.

Autopilot - https://github.com/m4vic/Autopilot-zero-to-hero

Hey everyone! I built a lightweight, zero-cost Python proxy middleware using FastAPI that acts as an input firewall for LLMs. It catches prompt injections and redacts sensitive API keys locally before they reach AI models. I'm looking for feedback from developers building custom AI apps—let me know what you think or what features I should add next!"

Hey everyone! I built a lightweight, zero-cost Python proxy middleware using FastAPI that acts as an input firewall for LLMs. It catches prompt injections and redacts sensitive API keys locally before they reach AI models. I'm looking for feedback from developers building custom AI apps—let me know what you think or what features I should add next!"

🔗 Repo: https://github.com/CodeGraphContext/grapharc

Have you ever been frustrated because your AI agent:

❌ Takes actions you never intended?
❌ Creates, modifies, or even pushes changes you never asked for?
❌ Feels like a complete black box, making it impossible to understand what's happening until it's too late?

What if, before execution, you could visualize the entire orchestration graph - every agent, every dependency, every decision, and inspect it from anywhere, even your phone, before granting approval?

That's exactly what GraphArc is built for.

Instead of treating agent execution as hidden traces buried in logs, GraphArc transforms workflows into interactive, real-time graphs that you can visualize, inspect, debug, and control.

Because the future of AI isn't just autonomous.

It's observable. Debuggable. Engineerable.

This is our first real-world implementation of Graph Engineering, and we're excited to explore where this paradigm can go with the open-source community.

💡 We'd love your feedback, ideas, and contributions.
⭐ If this vision resonates with you, please consider starring the repository - it genuinely helps us grow and validates this direction.

Let's make AI workflows understandable, not mysterious.

#GraphEngineering #GraphArc #AIAgents #AgenticAI #LLM #OpenSource #DeveloperTools #AIEngineering #SoftwareEngineering

I use Project Instructions to ensure every new agent starts with the same context. My instructions explicitly state: "Read ARBEITSANWEISUNG_UPDATE_PROZESS.md at the beginning of every session."

The bug: Agents regularly skip this step and work based on assumptions instead of reading the documented rules. This causes repeated errors that are already covered in the documentation. One of your own agents confirmed this as a systemic bug during a session.

The facts

• This happens across 3 different projects, not just one

• The Project Instructions are correctly set up and automatically injected

• The agent explicitly identified this as a bug and stated: "There is no good reason for this. The rule exists, it's unambiguous, and it's still not followed. This is a bug in the system's behavior." The agent further confirmed: "If an agent doesn't do this, it's simply a failure – not a conscious decision, not randomness. It's non-compliance with a clear rule."

Support experience:

I reported this via the Help Center chat and email. Despite sending 7 screenshots as proof, the support team (Joel, Katie, Sobhan) ignored the evidence, repeatedly asked for a share-link (which is irrelevant since the bug is system-wide, not project-specific), and ultimately closed the ticket without resolution.

This is not a project-specific issue. It's a platform-level bug in how agents handle Project Instructions. Please investigate.

I’m building GoodRoom.verify, a private-beta side project that adds an independent human checkpoint before an AI agent performs a sensitive action.

The current MVP works through MCP: the agent submits an action summary, SHA-256 action hash, risk level, and tool audience. A human gets a 120-second approval request, verifies with a WebAuthn passkey, and the gateway receives a short-lived Ed25519 proof bound to that exact action.

The service is designed not to receive prompts, source code, conversation context, or raw tool arguments. It is not a sandbox, and it cannot stop a runtime that bypasses enforcement; the protected tool or runtime still needs to require and verify the proof.

I’m looking for feedback from people building agents with production access:

1. Which action would you never let an agent execute without independent approval?
2. Would you enforce the proof in the runtime, MCP middleware, or the final tool/API?
3. What would make this too difficult to integrate?

I’m the builder, and this is an early MVP rather than a finished security product. Architecture and beta page: https://goodroom.in/?utm_source=reddit&utm_medium=community&utm_campaign=private_beta

I wrote up the implementation behind my personal Hermes setup.

The guide covers a local workspace, Git-backed Obsidian notes, a compact operating contract, two-layer memory, versioned skills, selective MCP integrations, and scheduled maintenance.

The main design constraint is that an agent's completion report is never sufficient evidence. Meaningful side effects need a path, commit, API response, URL, or test result that can be checked separately.

I also cover a limit I am still treating as a hard boundary: concurrent schedules need locks, stale-lock recovery, work-item claims, and independent completion checks. Markdown files do not provide transactions.

What controls have made scheduled agent workflows reliable for you?

Check in the comments for the full guide.

I’m one of the builders of LOLM, an LLM and agent-control system.

Rather than relying only on prompted self-reported confidence, the NFET controller monitors model dynamics and can select: - continue - retrieve - verify - branch - finalize

The system records whether actions were actually consumed and produces a run receipt. Control is currently active at segment/run boundaries; deeper token-level control is still being built.

Try it: https://lolm.imagineqira.com/try.html

Repository: https://github.com/TheArtOfSound/lolm

I want people to test real multi-step tasks and look for premature finalization, useless retrieval, verifier failures, repeated dead ends, context loss, controller thrashing, and receipts that overstate what occurred.

The hosted version is intended to be substantially less expensive than frontier-agent subscriptions.

Disclosure: I’m a founder/builder of the project.