We can't be blocked here. Seems silly what we settled on this, but for a long time GitHub had been reliable enough for many years, but things are sliding down the pan as of late.

Comments URL: https://news.ycombinator.com/item?id=48197321

Points: 2

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47934494

Points: 2

# Comments: 1

We have roles open for a principal software engineer:

We're looking for a Principal Software Engineer to join as a founding engineer. You'll work directly with the founders to build the core of our agent security runtime. This is a high-autonomy role - you'll shape architecture, engage with early customers, and make the trade-offs that define the product.

You will build the layer between agentic reasoning and system execution — intercepting, classifying, and validating every agent intent against security policy before it runs. Design systems that capture and cryptographically verify every instruction and action, maintaining ground truth in environments prone to hallucination and injection. Architect fine-grained, time-scoped primitives that allow least-privilege permissions, with the ability to escalate under controlled, auditable conditions. Work with research to stress-test our security primitives at scale. Turn emerging threat vectors (prompt injection, tool misuse, privilege escalation) into adaptive defences.

https://www.alwaysfurther.ai/careers/principal-swe

Staff solutions engineer:

We're looking for a Solutions Engineer join as a founding engineer and to sit at the intersection of our open source community and our growing base of enterprise design partners. You'll spend your time contributing to Nono, helping shape its architecture, and working directly with customers who are integrating it into proof-of-concept and pilot programmes. This is a hands-on role - early on you'll be deep in the code, reviewing pull requests, triaging issues, and experimenting with deployment architectures, all while being a trusted technical voice for both community members and enterprise stakeholders. Over time, the role will evolve toward solutions architecture and customer-facing engagement, as you build the domain expertise and relationships that make you the go-to person for designing how Nono fits into complex enterprise environments.

What You'll Do" Contribute directly to the Nono open source project - code, documentation, and architectural proposals. Experiment with different deployment architectures for Nono across cloud environments, on-premise infrastructure, and hybrid setups and share your findings with others at Always Further, and often with the community, via our blogging platforms or YouTube channel. Work closely with early design partners to integrate Nono into proof-of-concept and pilot programmes, gathering feedback and translating it into engineering priorities. Produce technical content - blog posts, architecture guides, demos.

Comments URL: https://news.ycombinator.com/item?id=47519494

Points: 2

# Comments: 0

import nono_py as nono

# Define capabilities caps = nono.CapabilitySet() caps.allow_path("/project", nono.AccessMode.READ_WRITE) caps.allow_file("/home/user/.gitconfig", nono.AccessMode.READ)

# Apply sandbox (irrevocable) nono.apply(caps)

# Your agent code runs here, fully sandboxed agent.run()

example using pydantic and fast API:

https://github.com/always-further/pydantic-ai-fastapi-nono

For what it's worth, it's not just whipped up in claude, a lot of us have a long background in security - I originally created sigstore.dev and was a distinguished engineer at red hat where I built and contributed to a lot of open source security work.

Comes and check it out, any support is appreciated as there is a lot of noise around with all these projects going through weekly hype cycles.

One thing that's been bugging me: we give agents our API keys as environment variables, and a single prompt injection can exfiltrate them via env, /proc/PID/environ, or just an outbound HTTP call. The blast radius is the full scope of that key.

So we built what we're calling the "phantom token pattern" — a credential injection proxy that sits outside the sandbox. The agent never sees real credentials. It gets a per-session token that only works only with the session bound localhost proxy. The proxy validates the token (constant-time), strips it, injects the real credential, and forwards upstream over TLS. If the agent is fully compromised, there's nothing worth stealing.

Real credentials live in the system keystore (macOS Keychain / Linux Secret Service), memory is zeroized on drop, and DNS resolution is pinned to prevent rebinding attacks. It works transparently with OpenAI, Anthropic, and Gemini SDKs — they just follow the *_BASE_URL env vars to the proxy.

Blog post walks through the architecture, the token swap flow, and how to set it up. Would love feedback from anyone thinking about agent credential security.

https://nono.sh/blog/blog-credential-injection

We also have other features we have shipped, such as atomic rollbacks, Sigstore based SKILL attestation.

https://github.com/always-further/nono

Comments URL: https://news.ycombinator.com/item?id=47237327

Points: 3

# Comments: 2

Luke here.

I wanted to introduce a project I have building for the past few weeks in response to events such as openclaw and the glaring security issues at hand. Prior to nono, I created Sigstore , a project used for software supply chain security now used by pypi, npm, brew and GitHub for release attestation and provence.

The problem: Protecting the host from the agent is largely solved, microVMs (kata, firecracker), containers , nono is more focused on protecting the environment or workspace itself - having said that, the isolation controls from the host are pretty solid as we use landlock and seatbelt.

nono uses OS-level isolation, atomic snapshots, and command auditing, secret / token protections (using keychain on linux and the secure enclave chip on apple)

Linux: Landlock LSM (kernel 5.13+) macOS: Seatbelt (sandbox_init) After sandbox + exec(), there's no syscall to expand permissions. The kernel says no.

Filesystem: read/write/allow per directory or file Network: block entirely (per-host filtering planned)

Atomic Rollbacks: Content-addressable storage — Files are stored by SHA-256 hash. Identical content is never duplicated, keeping storage efficient even across long sessions with many reverts — Every snapshot is committed to a Merkle tree. Tampering or corruption becomes more easily detectable

Audit trail of commands: nono automatically generates a cryptographically verifiable audit trail of every file change made by a sandboxed AI agent.

SDKs. We have two SDKs releasing soon using FFI bindings, python and typescript to allow uses to easily implement nono features into their own code base.

Technical details:

Written in Rust. Uses the landlock crate on Linux, raw FFI to sandbox_init() on macOS. Secrets via keyring crate. All paths canonicalized at grant time to prevent symlink escapes.

Landlock ABI v4+ gives us TCP port filtering. Older kernels fall back to full network allow/deny. macOS Seatbelt profiles are generated dynamically as Scheme-like DSL strings.

Limitations:

Network is binary, on or off - plans are in place to introduce IP filtering.

GitHub: https://github.com/always-further/nono Docs: https://docs.nono.dev Site: https://noto.sh

Apache 2.0. Would love feedback!

Comments URL: https://news.ycombinator.com/item?id=47066574

Points: 2

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=46879315

Points: 2

# Comments: 0

I have been around security for a long old time now (i started something called sigstore a few years back) and have seen this pattern so many times before.

nono uses OS-level isolation that userspace can't escape:

Linux: Landlock LSM (kernel 5.13+) macOS: Seatbelt (sandbox_init) After sandbox + exec(), there's no syscall to expand permissions. The kernel says no.

What it does:

nono run --profile openclaw -- openclaw gatewa nono run --allow . --net-block -- npm install nono run --secrets api_key -- ./my-agent

Filesystem: read/write/allow per directory or file Network: block entirely (per-host filtering planned) Secrets: loads from macOS Keychain / Linux Secret Service, injects as env vars, zeroizes after exec

Technical details:

Written in Rust. ~2k LOC. Uses the landlock crate on Linux, raw FFI to sandbox_init() on macOS. Secrets via keyring crate. All paths canonicalized at grant time to prevent symlink escapes.

Landlock ABI v4+ gives us TCP port filtering. Older kernels fall back to full network allow/deny. macOS Seatbelt profiles are generated dynamically as Scheme-like DSL strings.

Limitations:

macOS: Currently allows all reads to make executables work. Tightening in next release. Linux: Landlock doesn't cover everything (no UDP filtering until recent kernels, no syscall filtering - that's seccomp territory) No Windows support (yet?)

GitHub: https://github.com/lukehinds/nono Docs: https://docs.nono.dev Site: https://noto.sh

Apache 2.0. Would love feedback on the security model, especially from folks who've worked with Landlock or Seatbelt. Having said that, the code needs a good tidy and I am not exactly proud of it, so go easy on me!

Comments URL: https://news.ycombinator.com/item?id=46863963

Points: 1

# Comments: 0

All child processes inherit the restrictions - if the agent spawns Python, Bash, or compiles and runs a binary, that process is equally sandboxed There is no API to remove or expand the sandbox - once restrict_self() (Landlock) or sandbox_init() (Seatbelt) is called, the restrictions are permanent for that process tree.

Luke here.

I built nono and got it out quick then I expected, in response to the openclaw carnage, but its use is beyond openclaw.

The problem: AI agents execute code on your machine. Prompt injections, hallucinations, or compromised tools can read ~/.ssh, exfiltrate credentials, or worse. Application-level sandboxes can be bypassed by the code they're sandboxing.

I have been around security for a long old time now (i started something called sigstore a few years back) and have seen this pattern so many times before.

The solution pitch: nono uses OS-level isolation that userspace can't escape:

Linux: Landlock LSM (kernel 5.13+) macOS: Seatbelt (sandbox_init) After sandbox + exec(), there's no syscall to expand permissions. The kernel says no.

What it does:

nono run --read ./src --allow ./output -- cargo build nono run --profile claude-code -- claude nono run --allow . --net-block -- npm install nono run --secrets api_key -- ./my-agent

Filesystem: read/write/allow per directory or file Network: block entirely (per-host filtering planned) Secrets: loads from macOS Keychain / Linux Secret Service, injects as env vars, zeroizes after exec

Technical details:

Written in Rust. ~2k LOC. Uses the landlock crate on Linux, raw FFI to sandbox_init() on macOS. Secrets via keyring crate. All paths canonicalized at grant time to prevent symlink escapes.

Landlock ABI v4+ gives us TCP port filtering. Older kernels fall back to full network allow/deny. macOS Seatbelt profiles are generated dynamically as Scheme-like DSL strings.

Limitations:

macOS: Currently allows all reads to make executables work. Tightening in next release. Linux: Landlock doesn't cover everything (no UDP filtering until recent kernels, no syscall filtering - that's seccomp territory) No Windows support (yet?)

Origin:

Built this for OpenClaw (AI agent platform handling Telegram/WhatsApp messages). Needed real isolation, not "please don't read this file" isolation. Generalized it because every agent runner has this problem.

GitHub: https://github.com/lukehinds/nono Docs: https://docs.nono.dev Site: https://noto.sh

Apache 2.0. Would love feedback on the security model, especially from folks who've worked with Landlock or Seatbelt. Having said that, the code needs a good tidy and I am not exactly proud of it, so go easy on me!

Comments URL: https://news.ycombinator.com/item?id=46849615

Points: 4

# Comments: 5