Cannot even merge code, this is the limit for me. We are prioritising migration to a different platform and this time going to decouple CI - right now we have too many points of failure on one vendor.
Same thoughts - we use an action to ship to production, its builds an image, pushes it to ECS which triggers a deployment.
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.
Always Further, founded by team who created https://sigstore.dev , used to secure npm, pypi, brew, and provide attestations for github releases, nvidia and google for AI model signing - we and are now building https://nono.sh agent security tooling.
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.
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.
If anyone happens to be interested in sandboxing, a community of us are building https://nono.sh
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.
It’s sad that it’s come to this, but your addendum with credentials and a non-slop declaration worked. Three years ago it would have seemed unnecessarily self-aggrandizing. Today I wouldn’t have clicked the link without it.
Hey HN. I'm Luke, security engineer and creator of Sigstore and other open source security projects. I've been building nono, an open source sandbox for AI coding agents that uses kernel-level enforcement (Landlock/Seatbelt) to restrict what agents can do on your machine.
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.
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.
