Hey HN. I'm Luke, security engineer and creator of Sigstore (software supply chain security for npm, pypi, brew, maven and others). 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`, with 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

When analyzing packet captures I often find myself asking small interpretation questions like:

• why is this TCP segment retransmitted?
• what exactly does this DNS response imply?
• is this behavior normal or suspicious?

Packet analyzers decode the fields well, but they don't really explain what's happening at a higher level.

So I started experimenting with the idea of using AI to generate explanations based on decoded packet fields.

The idea would be something like:

• take the parsed protocol fields
• ask questions about the packet
• get a human-readable explanation of what might be happening

I'm curious what people who regularly analyze PCAPs think about this idea.

Would something like this actually be useful, or would it create more confusion than help?

Feedbacks are welcome.

My usual workflow when scoping a target: run Nuclei, grep the output, manually feed interesting hosts into Trufflehog, then run Prowler if there's cloud exposure. Every step involves writing a tiny script to transform JSON from one tool into input for the next.

Those scripts break constantly — API changes, format changes, you know the drill.

I got annoyed enough to build a visual node-based workflow builder specifically for this. Each tool is a node, you wire them together, it handles the data transformation between them. Runs locally in Docker, Apache licensed, no accounts.

It's called ShipSec Studio: github.com/shipsecai/studio

Still early. Curious what tools people here would want as nodes — that would actually shape what we build next.

We started auditing popular OSS security libraries as an experiment. first week, we found a critical auth bypass in pac4j-jwt. How long has your enterprise security stack been scanning this package? years? finding nothing? we found it in 7 days.

either:

1/ we're security geniuses (lol no)

2/ all security tools are fundamentally broken

spoiler: it's B.

I mean, what is happening? why the heck engg teams are paying $200k+ to these AI tools??? This was not reported in 6 yrs btw.

Every production defense against prompt injection—input filters, LLM-as-a-judge, output classifiers—tries to make the AI smarter about detecting attacks. Intent-Based Access Control (IBAC) makes attacks irrelevant. IBAC derives per-request permissions from the user's explicit intent, enforces them deterministically at every tool invocation, and blocks unauthorized actions regardless of how thoroughly injected instructions compromise the LLM's reasoning.

The implementation is two steps: parse the user's intent into FGA tuples (email:send#bob@company.com), then check those tuples before every tool call. One extra LLM call. One ~9ms authorization check. No custom interpreter, no dual-LLM architecture, no changes to your agent framework.

https://ibac.dev/ibac-paper.pdf