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