Show HN: Nucleus – enforced permission envelopes for AI agents (Firecracker) | Hacker News Reader

Show HN: Nucleus – enforced permission envelopes for AI agents (Firecracker)

github.com

3 pointsdifc3 comments

I’ve been building Nucleus because most “agent security” is still policy-only: a config file that says “don’t do bad things,” while the agent can still do them.

Nucleus is an OSS experiment that pairs a small, compositional permission model with runtime enforcement: *side effects are only reachable through an enforcing tool proxy*, inside a Firecracker microVM. The envelope is *non-escalating*: it can only tighten or terminate, never silently relax.

What works today:

* MCP tool proxy with *read / write / run* (enforced inside the microVM) * default-deny egress + DNS allowlist + iptables drift detection (fail-closed) on Linux * time + budget caps enforced * hash-chained audit log + HMAC approval tokens (scoped, expiring) for gated ops

What’s missing (being upfront):

* web/search tools exist in the model but aren’t wired to MCP yet * remote append-only audit storage + attestation are still roadmap * early/rough; targeting “safe to run against sensitive codebases,” not “replace your local terminal”

Most of the code was written with Anthropic tools; I’ve been leaning on tests/fuzzing/proptests to keep it honest.

Would love feedback on: (1) dangerous capability combinations beyond the lethal trifecta, (2) what enforcement gaps you’d want closed first, (3) how you’d evaluate this vs gateway-only approaches.

Open articleView on HN

The non-escalating envelope approach in Firecracker is a great way to handle agent drift. I noticed you’re using HMAC approval tokens for gated ops—how are you handling the entropy source for those secrets?

One edge case in agent security is 'Entropy Exhaustion' or prediction if the microVM environment is compromised. I’ve been looking at anchoring HMAC generation to decentralized randomness beacons (like Drand) to ensure that even if an agent compromises the local environment, it can't predict or pre-mine the next set of 'valid' tokens because the entropy hasn't been released by the network yet.

Have you thought about moving the 'Root of Trust' for your HMAC tokens outside the local microVM entirely?The non-escalating envelope approach in Firecracker is a great way to handle agent drift. I noticed you’re using HMAC approval tokens for gated ops—how are you handling the entropy source for those secrets?

One edge case in agent security is 'Entropy Exhaustion' or prediction if the microVM environment is compromised. I’ve been looking at anchoring HMAC generation to decentralized randomness beacons (like Drand) to ensure that even if an agent compromises the local environment, it can't predict or pre-mine the next set of 'valid' tokens because the entropy hasn't been released by the network yet.

Have you thought about moving the 'Root of Trust' for your HMAC tokens outside the local microVM entirely?

Very interesting use of Firecracker for agent isolation.

How do you handle network identity for the agents themselves? Are you using something like mTLS/SPIFFE to identify the workload inside the VM, or is it purely network-policy based at the host level? Can you explain the "runtime enforcement" and the "enforcing tool proxy?

Thanks! Currently network identity is host-based, but in the middle of introducing SPIFFE based on ZTunnel. Should be done in the next couple of days.

Runtime enforcement means that any side effects are routed through a proxy (nucleus-tool-proxy) that does realtime checks on permissions and gates the behavior.

SPIFFE for MicroVM agents is a compelling idea and I'll update when this is ready.

Reply on news.ycombinator.com