Smartflow is the trust boundary
Smartflow sees everything that flows through it — prompts, responses, tool calls, agent-to-agent traffic, compliance verdicts, cost, and identity. But the instant data is handed to something outside the perimeter, that visibility stops. Trust-Fabric Egress Auditing marks that line.
It attests at the boundary, not beyond it
Smartflow does not pretend to see inside a third party's agentic workflow. Instead, at the exact chokepoint where a call leaves the perimeter, it seals a record: this request left the Smartflow trust fabric at time T, to destination Y, under user X's identity, releasing tool/data Z — and downstream is opaque.
The record is tamper-evident
Each egress marker is written to the same HMAC-linked audit chain Smartflow uses for every governed request (sequence number + previous-entry hash + signed entry). It cannot be silently altered or deleted, and it surfaces alongside the original request in the VAS log and Traces views.
It scans what comes back
Data returning from an opaque source is still untrusted. Smartflow runs its compliance scan on the returned payload and notes on the egress record whether sensitive identifiers (PII / PHI / secrets) came back — so a hand-off that returns regulated data is flagged for review.
The question every security team asks
"We can see our own agents and MCP calls. But the agent we call is outside our perimeter, and it may invoke other agents and tools before returning data. Can you track that?"
The honest answer is the strong answer. You cannot see inside someone else's agent — and claiming you can erodes trust. What you can do is treat the perimeter crossing as a recordable event, which is exactly how regulators already think about third-party data flows:
It is a recognized control
Not a gapThird-party data-sharing logs, GDPR processor hand-off records, SR 11-7 third-party / vendor model risk, and DLP egress accounting all rest on the same principle: mark the hand-off, declare where you lose visibility.
"Opaque" is a finding, not a failure
Auditors want the line drawnAn audit trail that ends with "data left to external-public endpoint Y; downstream visibility: none" is far more defensible than silence. It tells the examiner precisely where the controlled zone stops.
How a destination is classified
Smartflow classifies every egress using signals it already has — the destination URL, whether the operator declared a server internal-only, and the MCP Trust Registry status. Internal destinations stay inside the fabric and are not marked; everything else is a boundary crossing.
internal
Inside the perimeterPrivate / RFC-1918 host, cluster-internal DNS, loopback, or a server the operator declared not reachable from public IPs. Stays inside the trust fabric — no egress record.
external_trusted
Public, but vettedA public endpoint that is marked Trusted in the MCP Trust Registry. Still a boundary crossing — it is recorded — but at a lower severity because it has been vetted.
external_public
Public, not vettedA public endpoint with no trust-registry vetting. Full downstream opacity. Recorded, and escalated when the returned payload carries sensitive data.
unknown
Unresolvable destinationNo URL, or a host that cannot be parsed. Treated as outside the perimeter for safety — recorded rather than assumed safe.
What gets recorded at the boundary
Every boundary crossing produces a sealed perimeter_egress audit event and stamps perimeter fields onto the request's VAS log row, so it shows up wherever you already review traffic.
The same crossing also stamps these fields onto the request's VAS log row:
| VAS field | Type | Meaning |
|---|---|---|
left_perimeter |
bool | true when this request's data was released outside the trust fabric. |
perimeter_classification |
string | internal / external_trusted / external_public / unknown. |
perimeter_destination |
string | The endpoint (URL or provider id) data left the perimeter to. |
Where it is enforced
Egress marking runs at the gateway chokepoints data actually passes through — so it cannot be bypassed by an agent or client choosing a different path.
MCP Gateway
Every tool call proxied to an upstream MCP server is classified using the server's URL, its internal-only flag, and its Trust Registry status. Smartflow reuses the returned-payload compliance scan it already performs, then seals the egress record and stamps the VAS row.
A2A Gateway
Agent-to-agent tasks execute against a cloud LLM provider — a destination outside the perimeter. Each task now seals a perimeter_egress record and runs a quick sensitive-identifier sweep on the returned text, closing what was previously an unaudited path.
Observability export
The perimeter markers are also forwarded to downstream log / SIEM pipelines via the standard observability payload, so trust-boundary crossings land in your existing security tooling — not just the Smartflow dashboards.
Reading the records & configuration
The markers surface in the tools you already use, and a durable, dedicated egress audit stream is one config toggle away.
VAS Log & Traces
Filter or scan for left_perimeter = true to see every request that crossed the boundary, with its classification and destination inline. Each row links back to the original request and its compliance verdict.
Tamper-evident audit chain
For MCP egress the marker is carried on the request's sealed VAS log row, which is part of the HMAC-linked audit chain — durable and verifiable by default, with no extra configuration.
Optional: a dedicated, persistent egress stream
To keep a standalone, append-only audit file of only perimeter crossings (handy for shipping straight to a WORM store), set two environment variables on the proxy. Without them, the dedicated stream stays in-memory while the VAS chain remains the durable record.