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.
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.
Good question - and the answer is no, they cannot escape.
nono uses Landlock (Linux) and Seatbelt (macOS) - these are kernel-level security mechanisms. When a sandbox is created:
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.
Hmm, I don't know about better, more convenient I guess. But if it floats your boat you could write out everything in the sb format and call sandbox_exec()!
lol thanks! seriously, I have been running the tool over and over while testing and I kept typing 'nano' and opening binaries in the text editor. Next minute I swearing my head off trying to close nano (and not vim!)
I rushed out nono.sh (the opposite of yolo!) in response to this and its already negated a few gateway attacks.
It uses kernel-level security primitives (Landlock on Linux, Seatbelt on macOS) to create sandboxes where unauthorized operations are structurally impossible. API keys are also stored in apples secure enclave (or the kernel keyring in linux) , and injected at run time and zeroized from memory after use. There is also some blocking of destructive actions (rm -rf ~/)
its as simple to run as: nono run --profile openclaw -- openclaw gateway
You can also use it to sandbox things like npm install:
nono run --allow node_modules
--allow-file package.json package.lock npm install pkg
Its early in, there will be bugs! PR's welcome and all that!
What sets DeepFabric apart from other dataset generation tools is its ability to ensure high diversity yet domain-anchored relevance through unique topic graph generation algorithms. This guides sample creation to cover all necessary subtopics while avoiding redundancy, which is where other tools often fall short, resulting in model overfit.
Constrained decoding and response validation, along with real tool executions within isolated webassembly environments, ensure that generated samples strictly adhere to structured schema, variable constraints, and execution correctness, ensuring datasets have exact syntax and structure for use in model training pipelines. Tool definitions can be directly imported from MCP server schemas and then mocked, or rans as real life tool functions. Using real tools means the model has to adapt and correct when it makes the wrong choice or hallucinationates which makes for much better training data.
Once your dataset is generated, it can be automatically uploaded to Hugging Face and directly imported into popular training frameworks like TRL, Unsloth, and Axolotl.
Post-training, DeepFabric's built-in evaluation engine assesses model performance, whereby models prove their capabilities on unseen tasks derived from training splits—covering evaluation-only questions, answers, and tool traces.
Hey There, this thread is getting derailed. Could you please create a separate post for your project and we let this one be for discussion of deepfabric, thanks!