Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kxbnb
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
1.
▲
Show HN: DNSMint – Give a sandbox its own domain and HTTPS cert in one API call
(dnsmint.com)
2 points
by
kxbnb
2d ago
|
0 comments
2.
▲
Show HN: Webact – token-efficient browser control for AI agents (GitHub)
(github.com)
1 points
by
kxbnb
7mo ago
|
1 comments
3.
▲
by
kxbnb
7mo ago
Fair question. Those three are hosting services for stock OpenClaw — you sign up, they spin up an instance, you get a Telegram bot. That's it. We built something different. Every agent gets a real Chromium browser running on a virtual
4.
▲
Show HN: Claw42 – Claw as a Service
(claw42.com)
1 points
by
kxbnb
7mo ago
|
2 comments
5.
▲
Personal AI Infra: Agentic system with persistent memory and goal awareness
(github.com)
2 points
by
kxbnb
7mo ago
|
0 comments
6.
▲
by
kxbnb
7mo ago
I built Axiomo because every AI code review tool I tried kept solving the wrong problem. They all want to be a second developer on your PR, catching lint issues and suggesting refactors. That's not what makes review hard. What makes it
7.
▲
Show HN: Axiomo – PR intent and context, not AI code review
(axiomo.vercel.app)
1 points
by
kxbnb
7mo ago
|
1 comments
8.
▲
by
kxbnb
8mo ago
The framing of craft vs. slop misses something important: most production software quality problems aren't about aesthetics or elegance, they're about correctness under real-world conditions. I've been using AI coding tools h
9.
▲
by
kxbnb
8mo ago
Cool project. The agent shorthand/jargon detection is a unique angle - I haven't seen other tools focus on that specifically. Re: your question about observability pain points - the one I keep hitting is visibility at the external
10.
▲
by
kxbnb
8mo ago
The "output validation not just input validation" point is underrated. Most guardrails focus on what goes into the model, but the real risk is what comes out and gets executed. We're working on similar problems at keypost.ai
11.
▲
by
kxbnb
8mo ago
Nice execution on the replay testing with semantic diff - that's a pain point that's hard to solve with just metrics. One thing I've noticed building toran.sh (HTTP-level observability for agents): there's a gap between
12.
▲
by
kxbnb
8mo ago
Your framing of the problem resonates - treating the LLM as untrusted is the right starting point. The CAR spec sounds similar to what we're building at keypost.ai. On canonicalization: we found that intercepting at the tool/API b
13.
▲
by
kxbnb
8mo ago
Interesting approach to the instruction bloat problem. The composable skills idea makes sense - 500 tokens vs 10K is a real difference. One thing I'd be curious about: how do you think about security when skills auto-provision based on
14.
▲
by
kxbnb
8mo ago
The insight about environment attacks vs. model attacks is critical. "The model functioned correctly, yet the overall agent system remained compromised because it trusted its tools' outputs." This is why I've been focuse
15.
▲
by
kxbnb
8mo ago
Nice work - the "deploy-friendly guardrails" framing resonates. Too many MCP tools assume local dev only. To your question about what bites first: in our experience at keypost.ai, the order is usually: 1. *Auth* - OAuth token refr
16.
▲
by
kxbnb
8mo ago
The middleware proxy approach unop mentioned is the right pattern - you need an enforcement point the agent can't bypass. At keypost.ai we're building exactly this for MCP pipelines. The proxy evaluates every tool call against det
17.
▲
by
kxbnb
8mo ago
We're building this at keypost.ai - the enforcement point is a proxy that sits between the agent and MCP servers. Tool calls go through the proxy, get evaluated against policy, and either pass or get blocked before reaching the actual
18.
▲
by
kxbnb
8mo ago
Nice approach - fail-closed decision logging is the right default. Too many systems treat audit as best-effort, which defeats the purpose when you're investigating an incident. The framework-agnostic design makes sense for adoption. On
19.
▲
by
kxbnb
8mo ago
The pain of failures that are "hard to reason about once things went async" is real. Centralizing the retry/failover logic makes sense. One pattern I've found useful: having a read-only view of what's actually hitti
20.
▲
by
kxbnb
8mo ago
The noise problem is real. Most observability tools optimize for "capture everything" which leads to exactly this waste. We took a different approach with toran.sh - instead of instrumenting your entire stack, you create a read-on
21.
▲
by
kxbnb
8mo ago
Nice approach using the base URL feature as the interception point. That's the same pattern we've been using at toran.sh for API observability - swap a URL and you get visibility without SDK changes. The "searchable logs of a
22.
▲
by
kxbnb
8mo ago
This is the exact problem we're seeing with MCP adoption too - powerful tool access with zero restrictions by default. The "tool chaining" attack class is particularly nasty because each individual action looks benign. Read f
23.
▲
by
kxbnb
8mo ago
Good question. The boundary problem shows up most clearly with third-party API integrations - Stripe, Twilio, Shopify, etc. The pattern we see: an agent makes an API call, gets a 400 or unexpected response, and the developer has no visibili
24.
▲
by
kxbnb
8mo ago
Great execution on this - the argument-level blocking is the key insight. The all-or-nothing permission model is exactly why MCP adoption stalls in production. We've been working on a similar problem at https://keypost.ai ,
25.
▲
by
kxbnb
8mo ago
The "signed transaction, not a log stream" framing is exactly right. Logs are optimistic - you assume they're complete and unmodified. Receipts are pessimistic - you verify before trusting. We've been thinking about a re
26.
▲
by
kxbnb
8mo ago
Congrats on the 1.0 launch! The workflow and agent composition primitives look well-designed. Curious about the observability story - when agents make tool calls, how do you debug what actually got sent to external APIs? We've found th
27.
▲
by
kxbnb
8mo ago
Nice work on Fence! The network/filesystem restriction approach is exactly what's needed for running untrusted commands safely. We're working on similar containment problems but at the API/MCP layer at keypost.ai - enfor
28.
▲
by
kxbnb
8mo ago
Really cool approach to the containment problem. The insight about "capping the blast radius of a confused agent" resonates - decision fatigue is real when you're constantly approving agent actions. The exfiltration controls
29.
▲
by
kxbnb
8mo ago
The multiplexing over a single port is a nice touch - solves the random port allocation pain point that makes localtunnel tricky to deploy in restrictive environments. Curious about the WebSocket overhead in practice. Have you measured late
30.
▲
by
kxbnb
8mo ago
The distinction between "X% confidence" checks on output vs deterministic authorization on actions/tools is spot on. We've seen the same pattern - probabilistic guardrails at the text level are the weakest enforcement po
More ›