|
|
|
|
|
|
by kxbnb
142 days 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 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? |
|
|
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.