[saurabhjain1592]

This is a very accurate framing. We see the same failure mode in practice.

You are right that enforcement is hard if you cannot first see what is actually happening at runtime.

How we think about the observability to enforcement gap:

In practice, most teams start with visibility and only add enforcement once they trust the signal.

AxonFlow is designed to collapse that loop by providing both in the same system. The same instrumentation that produces the audit trail can also gate execution.

What AxonFlow provides today:

- Full request-level capture for LLM calls and tool calls that flow through AxonFlow, including inputs, outputs, policy decisions, latencies, tokens, and cost. - A complete audit log with step boundaries, policy evaluation results, and decision context, so teams can answer what happened and why it was allowed or blocked. Critical violations such as blocks and policy triggers are logged synchronously, while successful calls are queued asynchronously for performance.

- Operational controls like timeouts, approval gates, and the ability to block or require human review at a specific step.

- Two integration modes: Proxy Mode, where AxonFlow sits inline in the request path, and Gateway Mode, where it acts as a policy check before and an audit capture layer after existing LLM calls.

What we do not assume: - We do not assume teams already have clean visibility into all agent calls.

- We do assume that for enforcement to be meaningful, the calls you want to govern must traverse AxonFlow. If some calls bypass it, you end up with fragmented audit trails and inconsistent policy enforcement.

How teams adopt it:

- Many teams start by routing a single workflow or a subset of tools through AxonFlow to get an end-to-end trace and audit. Once that is stable, they expand coverage and enable stricter enforcement policies.

- Interesting that you are separating visibility (toran.sh) and policy (keypost.ai). We took a combined approach, but I can see the rationale for decoupling.

If you have a concrete example of the invisible tool call problem you are seeing, such as custom HTTP tools, internal RPC, or database calls, I would be interested in how you are instrumenting it today. That boundary is where many systems break down.

[kxbnb]

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?

[saurabhjain1592]

We intentionally require explicit tool and connector registration rather than doing blind network layer interception.

The reason is deliberate: we want semantic understanding of what a call represents, not just raw HTTP payloads. When a connector is registered, AxonFlow knows the operation type (database, external API, internal service), can parse the intent, and apply phase aware policies such as blocking dangerous operations before execution, redacting sensitive fields from responses, or enforcing connector specific rate limits.

For arbitrary HTTP integrations, we provide a generic HTTP connector (platform/connectors/http/) that can be configured against any REST endpoint. You register the base URL, auth mechanism (bearer, basic, API key, OAuth2), and headers. From that point on, all requests flow through the same policy engine used for database and first class connectors.

Trade offs versus a pure proxy approach: - Our approach requires explicit setup. In return, governance is richer: semantic policy enforcement, field level redaction, connector scoped rate limits, and clearer audit trails.

- A proxy based approach has near zero setup and full payload visibility, but enforcement has to reason over raw HTTP without understanding what the call actually does.

On the Stripe or Twilio “what was actually sent?” debugging problem you mentioned: with our model, the connector captures request, response, status, latency, and policy decisions in the audit log. You can see exactly what payload caused a failure, as long as the call was routed through AxonFlow.

The boundary issue you raised is real. Calls that bypass the connector layer (direct SDK usage, internal RPCs) are invisible to us. We are explicit with teams about this: if you want governance and auditability, the call needs to traverse the control plane. Anything outside that path is outside enforcement.

If helpful for additional context, this is discussed in more detail in our recent Show HN thread: https://news.ycombinator.com/item?id=46692499

Curious whether you are seeing teams combine both patterns in practice: raw visibility layers for debugging, plus a semantic enforcement layer for policy. They seem to solve adjacent but distinct problems.