kxbnb

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 display. You can watch it work through a VNC viewer right in the dashboard. None of those services have this — they're text-in/text-out.

Each workspace runs up to 10 agents, each with its own browser and filesystem. Agents can spawn sub-agents to break up complex tasks. Every workspace is an isolated Docker container with dropped capabilities and security policies, not a shared Node process.

Those services give you a chatbot you talk to on Telegram. We give you an agent with a browser, a shell, a scheduler, and the ability to actually do things on the internet — and you can watch it do them.

More on what's under the hood: https://claw42.com/features

Docs if you want to dig in: https://claw42.com/docs

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 hard is context. Who wrote this, have they worked in this area before, what are they actually trying to do, and where should I focus?

Axiomo generates a structured Signal for every PR that answers those questions. Contributor context, intent, risk drivers, CI evidence, focus files. No auto-generated code suggestions. No comment spam. Just the stuff that helps you actually review instead of skim and approve.

Stack is Next.js on Vercel, Neon for Postgres, Resend for email. GitHub integration. Would love feedback on the approach and what your review workflow looks like.

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 heavily for the past year. They're genuinely useful for the "plumbing" - glue code, boilerplate, test scaffolding. But where they consistently fail is reasoning about system-level concerns: authorization boundaries, failure modes, state consistency across services.

The article mentions AI works best on "well-defined prompts for already often-solved problems." This is accurate. The challenge is that in production, the hard problems are rarely well-defined - they emerge from the interaction between your code and reality: rate limits you didn't anticipate, edge cases in user behavior, security assumptions that don't hold.

Craft isn't about writing beautiful code. It's about having developed judgment for which corners you can't cut - something that comes from having been burned by the consequences.

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 API boundary. Most agent observability (including OTEL-based traces) shows what the agent intended to send, but not necessarily what actually hit the wire when calling external services.

When an agent makes a tool call that hits Stripe, Shopify, or any third-party API, you want to see the actual HTTP request/response - not just the function call in your trace. Especially for debugging "works locally, fails in prod" scenarios or when the vendor says "your request was malformed."

I built toran.sh for this - transparent proxy that captures wire-level requests to external APIs. Complements tools like InsAIts since you get the inter-agent communication view and the external boundary view.

What's your take on capturing outbound API calls vs focusing on agent-to-agent communication?

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 - policy enforcement at the tool-calling boundary for MCP pipelines. Different angle (we're more focused on access control and rate limits than hallucination detection per se) but same philosophy of deterministic enforcement.

Question: how do you handle the tension between semantic enforcement and false positives? In our experience, too-strict semantic rules block legitimate use cases, but too-loose lets things through. Any patterns that worked for calibrating that?

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 "what the agent decided to do" (your trace level) and "what actually went over the wire" (raw requests/responses). Especially with retries, timeouts, and provider failovers - the trace might show success but the HTTP layer tells a different story.

Do you capture the underlying HTTP calls, or is it primarily at the SDK/trace level? Asking because debugging often ends up needing both views.

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 boundary (rather than parsing free-form output) sidesteps most aliasing issues. The MCP protocol helps here - structured tool calls are easier to normalize than arbitrary text.

On stateful intent: this is harder. We're experimenting with session-scoped budgets (max N reads before requiring elevated approval) rather than trying to detect "bad sequences" semantically. Explicit resource limits beat heuristics.

On latency: sub-10ms is achievable for policy checks if you keep rules declarative and avoid LLM-in-the-loop validation. YAML policies with pattern matching scale well.

Curious about your CAR spec - are you treating it as a normalization layer before policy evaluation, or as the policy language itself?

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 stack detection? If a skill gets compromised upstream, the auto-sync could propagate it quickly.

We're working on policy enforcement for MCP at keypost.ai and thinking about similar trust questions - what should be allowed to load/execute vs what needs explicit approval.

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 focused on boundary visibility. Agents are opaque until they hit real tools - and if you can't see what's actually being sent/received at each boundary, you can't detect manipulation.

We built toran.sh to provide that inspection layer - read-only proxies that show the actual wire-level request/response. Doesn't prevent attacks, but makes them visible.

Curious what detection mechanisms you're recommending alongside the attack framework?

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 refresh edge cases, especially when agents run long tasks that span token expiry 2. *Rate limits* - not having them, then having them but too coarse (per-tool vs per-endpoint vs per-argument) 3. *Observability* - specifically, correlating agent intent with actual tool calls when debugging why something failed 4. *Sandboxing* - usually comes up after the first "oops" moment

One pattern we've found useful: separating "can this identity call this tool" (auth) from "should this specific call be allowed" (policy). They're often conflated but have different failure modes and different owners (security team vs product team).

Curious how you're handling policy in PolyMCP - is it config-driven or code-driven?

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 deterministic policy before it reaches the actual tool. No LLM in the decision path, so no reasoning around the rules.

Re: chrisjj's point about "fix the program" - the challenge is that agents are non-deterministic by design. You can't unit test every possible action sequence. So you need runtime enforcement as a safety net, similar to how we use IAM even for well-tested code.

The human-in-the-loop suggestion works but doesn't scale. What we're seeing teams want is conditional human approval - only trigger review when the action crosses a risk threshold (first time deleting in prod, spend over $X, etc.), not for every call.

The audit trail gap is real. Most teams log tool calls but not the policy decision. When something goes wrong, you want to know: was it allowed by policy, or did policy not cover this case?

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 tool.

The key insight: policy evaluation has to happen outside the agent's context. If the agent can reason about or around the policy, it's not really enforcement. So we treat it like a firewall - deterministic rules, no LLM in the decision path.

What we've found works: - Argument-level rules, not just tool-level ("github.delete_branch is fine, but only for feature/* branches") - Rate limits that reset on different windows (per-minute for burst, per-day for cost) - Explicit rule priority for when constraints conflict

The audit trail piece is critical too. Being able to answer "why was this blocked?" after the fact builds trust with teams rolling this out.

Curious what failure modes people have actually hit - is it more "agent tried something it shouldn't" or "policy was too restrictive and blocked legitimate work"?

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. One thing we've found tricky at keypost.ai is policy composition - when you have overlapping constraints (rate limits + role-based access + cost caps), determining which rule "wins" needs explicit precedence. Does SudoAgent have opinions on conflict resolution, or is that left to the Policy implementation?

Also curious about the human approval latency in practice - do you see teams using it for truly synchronous gates, or more as a "review queue" pattern where work gets batched?

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 hitting the wire before any retry logic kicks in. When you can see the raw request/response as it happens, you can tell whether the issue is your payload, the provider throttling, or something in between.

We built toran.sh for this - it's a transparent proxy that shows exactly what goes out and comes back in real-time. Different layer than what you're doing (you handle the orchestration, we just show the traffic), but they complement each other.

Curious how you handle visibility into what's actually being sent during partial stream failures?

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-only proxy for a specific upstream API. You see exactly what's being sent and received, nothing else. No SDK, no log parsing, just the raw request/response for that one integration.

Works well for debugging third-party API issues where you need to see what actually hit the wire, not what your code thought it sent.

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 all conversations" piece is interesting. We focused more on the real-time view (watching requests as they happen during debugging) rather than historical search. Curious if you find yourself using the live view vs searching through logs more often?

One thing we ran into: when agents chain multiple API calls, having just the raw logs isn't enough - you need to correlate which calls came from which task/session. Did you add any grouping/correlation to LLMWatcher?

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 file? Fine. Send email? Fine. But the combination is exfiltration.

We're working on deterministic policy enforcement for agent pipelines at keypost.ai - the idea is you define what tools can do (not just whether they can be called), so "email tool can only send to @company.com" becomes a hard boundary the agent can't reason around.

The tricky part is making policies that are specific enough to block attacks but general enough to not break legitimate workflows. Curious what patterns you found that would be hardest to catch with simple allow/deny rules?

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 visibility into what was actually sent. The agent's logs show "called Stripe API" but not the actual payload that triggered the error. Vendor support says "the request was malformed" but the agent's internal state looks fine.

With https://toran.sh, we create a read-only inspection endpoint bound to a single upstream API. The agent points at our URL instead of the vendor's, and we proxy everything through while capturing the raw request/response. No SDK, no code changes to the agent - just swap the base URL.

The instrumentation approach is intentionally minimal: we don't try to understand the semantics of the calls, just show exactly what bytes hit the wire. Teams can then add policy enforcement (via https://keypost.ai or similar) once they actually understand what their agents are doing.

Curious about AxonFlow's approach to custom HTTP integrations - do you intercept at the network layer or require explicit tool registration?

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, coming at it from the policy enforcement angle - rate limits, cost caps, and access control rules that sit in-path. The challenge we keep hitting is rule composition: when you have multiple constraints (e.g., "can use github.delete but only on branches matching feature-*, and only 3x per hour"), the config can get unwieldy fast.

Curious how you're handling rule definitions in Armour - is it purely argument pattern matching, or are you thinking about stateful rules (like rate limits or quotas)?

Really glad to see more people building in this space. The MCP security story needs a lot more attention.

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 related problem at toran.sh: capturing what an agent actually sent to external APIs (and what came back) without trusting the agent's self-reported logs. Different angle - we focus on the API request/response level rather than the decision/action level - but the same underlying insight: the source of truth needs to be outside the agent's control.

The Ed25519 + canonical JSON approach is clean. Question: how are you handling schema evolution? If the receipt format changes, older receipts still need to verify but newer tooling might expect different fields.

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 that's often the hardest part of agent development - the "it works locally but fails in production" debugging loop.

Great to see more production-ready agent frameworks emerging. Will be following the project!

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 - enforcing what outbound calls an agent can make rather than what local filesystem/network it can access. The two layers complement each other well.

The "restrictions as code" pattern is powerful. Are you thinking about extending to other resource types (API calls, token budgets, etc.)?

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 are interesting. Have you thought about extending this to rate limiting and cost controls as well? We've been working on similar problems at keypost.ai - deterministic policy enforcement for MCP tool calls (rate limits, access control, cost caps).

One thing we've found is that the enforcement layer needs to be in-path rather than advisory - agents can be creative about working around soft limits. Curious how you're handling the boundary between "blocked" and "allowed but logged"?

Great work shipping this - the agent security space needs more practical tools.

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 latency compared to SSH-based tunnels like bore or rathole? The TypeScript/node.js stack makes it easy to embed, which is appealing for dev tooling integrations.

The fact that you built this for MCP Inspector work is interesting - I've been working on MCP tooling myself and the local dev workflow definitely needs better tunneling options. Nice to see more infrastructure pieces for that ecosystem.

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 point.

Building in this space too (visibility layer at toran.sh, policy enforcement at keypost.ai). One thing we've found: before you can enforce policy on tool calls, you need to actually see what's happening. The "no clean way to stop, inspect, or intervene once execution starts" problem often starts with lack of visibility into what calls are being made in the first place.

Curious how you handle the observability → enforcement gap. Do you assume teams already have visibility into their agent's API calls, or does AxonFlow provide that inspection layer as well?

This spec reads like what we've been building at toran.sh - transparent proxy for AI API calls with observability.

The core idea: you create a "toran" (read-only inspection endpoint) bound to a single upstream. Point your client at the toran URL instead of the API directly. No SDK changes, no code changes - just swap the base URL. It shows exactly what went over the wire in real time.

For the multi-provider setup you're describing (OpenAI, Anthropic, Google, etc.), you'd create separate torans for each upstream. Auth passthrough works because the toran is transparent - it just forwards headers.

We're still early (focused on the "see what's happening" problem before tackling rate limiting/policy), but if the visibility piece would help with your setup, happy to give you access and hear how it compares to litellm+langfuse for your use case.

The escalation logic (lightweight fetch → full browser only when needed) is a nice optimization. That's exactly the kind of thing that's painful to build yourself.

Curious about debugging: when an agent's request fails or returns unexpected data, how do you surface what actually happened in the browser? We've found that visibility into the actual request/response chain is often the missing piece when debugging agent behavior.

Good call on the ethics stance with robots.txt and User-Agent identification.

The MCP Server integration is a great addition - being able to have Claude manage VMs directly opens up interesting sandboxing patterns for agent workflows.

One thing I've been thinking about with agents running in isolated environments: how do you handle visibility into what API calls the agent is making from within the VM? Right now we rely on proxying outbound requests to see what's actually happening. Does Lume expose any of that through the MCP interface?

Nice work on the unattended setup - that's usually the painful part.

This really resonates - the opacity problem is exactly what makes MCP-based agents hard to trust in production. You can't control what you can't see.

We built toran.sh specifically for this: it lets you watch real API requests from your agents as they happen, without adding SDKs or logging code. Replace the base URL, and you see exactly what the agent sent and what came back.

The "precision and control" point is key though - visibility is step one, but you also need guardrails. We're working on that layer too (keypost.ai for policy enforcement on MCP pipelines).

Would love to hear what monitoring approaches you've found work well for production agent workflows.

Love the security-first approach with Docker sandboxing - that's often an afterthought in agent wrappers. The BYOK model is compelling too for teams with compliance requirements.

Curious: how are you thinking about policy enforcement for what the agent can actually do within the sandbox? Like limiting which MCP tools it can call or what parameters are valid?

We're working on governance/guardrails for MCP pipelines at keypost.ai - would be interested to explore if there's complementary overlap. Congrats on shipping!