Summary
We registered exactly one URL pattern in trusted_endpoints:
http://endpoints:8011/{rest:path}
then made an HTTP call to https://httpbin.org/post from inside provably.intercept_context(...). The expected behavior (per ADR-style "deny by default" framing of the trust edge) was that the call would be refused before the network roundtrip. Observed: the request reached httpbin, returned 200, and was indexed as a successful intercept.
Reproduction
import httpx, provably
provably.initialize_runtime(...)
provably.init_interceptor()
# Register one trusted entry only:
# http://endpoints:8011/{rest:path}
with provably.intercept_context(agent_id="x", action_name="y"):
httpx.Client().post("https://httpbin.org/post", json={"hi": 1}).json()
# Returns 200 + payload. No refusal.
In our demo this manifested as the policy-block scenario silently succeeding — the un-allowlisted send_external_email tool returned a real httpbin response and the heal loop tried to verify it (trace example).
Why this matters
The whole point of trusted_endpoints for our consumer is "the agent can't exfiltrate data or call services we haven't approved." Allow-by-default means:
- Sensitive prompts can leak via any URL the agent fabricates
- The "policy block" pillar of every demo built on the SDK becomes theatre
- Audit logs miss the most important class of agent failure (calling something it shouldn't)
Workaround
We refuse client-side in the offending tool (tools.py:115-122):
def send_external_email(...):
raise PermissionError(
f"trust gate refused {EXTERNAL_EMAIL_URL}: not in trusted_endpoints"
)
This is a hack. Real consumers won't know to put this in front of every external tool — they'll trust the gate. Please confirm: is the trust gate currently allow-by-default? If so, was that intentional, and how should consumers express deny-by-default?
Proposed fix
If allow-by-default is the current behavior: introduce a flag (e.g. init_interceptor(deny_by_default=True)) so consumers can opt in. If allow-by-default was a regression: restore deny-by-default.
Either way the docs should make the semantics explicit — "trusted_endpoints registration is required for indexing" reads ambiguously today.
Summary
We registered exactly one URL pattern in
trusted_endpoints:then made an HTTP call to
https://httpbin.org/postfrom insideprovably.intercept_context(...). The expected behavior (per ADR-style "deny by default" framing of the trust edge) was that the call would be refused before the network roundtrip. Observed: the request reached httpbin, returned 200, and was indexed as a successful intercept.Reproduction
In our demo this manifested as the policy-block scenario silently succeeding — the un-allowlisted
send_external_emailtool returned a realhttpbinresponse and the heal loop tried to verify it (trace example).Why this matters
The whole point of
trusted_endpointsfor our consumer is "the agent can't exfiltrate data or call services we haven't approved." Allow-by-default means:Workaround
We refuse client-side in the offending tool (tools.py:115-122):
This is a hack. Real consumers won't know to put this in front of every external tool — they'll trust the gate. Please confirm: is the trust gate currently allow-by-default? If so, was that intentional, and how should consumers express deny-by-default?
Proposed fix
If allow-by-default is the current behavior: introduce a flag (e.g.
init_interceptor(deny_by_default=True)) so consumers can opt in. If allow-by-default was a regression: restore deny-by-default.Either way the docs should make the semantics explicit — "trusted_endpoints registration is required for indexing" reads ambiguously today.