Edge deployment and boundary ingest

Topic

From the PointSav Documentation

The platform routes all external network connections through Ring 1 boundary-ingest services at the system edge, sanitizing incoming payloads before they reach core processing rings and recording clean, validated events to the audit ledger rather than raw network traffic.

Updated 2026-05-09 · HistoryEspañol

The platform moves all external network connections to the outermost boundary of the three-ring architecture before any data reaches the core processing rings. This architecture prevents common network-based attacks from reaching the financial ledgers and structured records held in Ring 2, with sanitized records written to the WORM ledger.

[edit]Key Takeaways

  • All inbound internet traffic is processed exclusively in Ring 1 — the boundary layer. No external payload reaches Ring 2 until it has been sanitized, validated, and stripped of transport metadata by the appropriate Ring 1 ingest service. The public internet is never in direct contact with Ring 2 or Ring 3.
  • Ring 1 is implemented as a set of per-channel MCP server processes (one per ingest type: email, filesystem, people records, external input). Each accepts, sanitizes, and passes only clean structured records inward — a compromised ingest channel cannot escalate to the ledger layer.
  • The audit ledger in Ring 2 records what the system acted on, not what arrived at the network boundary. This is a precondition of the WORM ledger design: clean, validated events — not raw traffic — are what get written to the immutable record.
  • Ring 2 has no outbound internet path except through service-egress. The boundary is enforced in both directions: inbound via Ring 1 ingest, outbound via the egress service.

[edit]The problem with deep ingest

Standard server configurations process incoming internet traffic — email, HTTP, external API calls — inside the same execution environment that holds core data. A vulnerability in any ingest pathway grants an attacker access to the same memory space as the core records. Isolation cannot be added retroactively once a process has shared-memory access to another.

[edit]Boundary placement

The platform positions all ingest processes at the physical and logical edge of the system. No inbound internet payload crosses into Ring 2 until it has passed through the Ring 1 boundary layer. Ring 1 is implemented as a set of Model Context Protocol (MCP) server processes, one per ingest channel (email, filesystem, people records, external input).

Each Ring 1 process:

  1. Accepts the inbound payload from the external source.
  2. Sanitizes the payload — removes transport metadata, validates structure, discards malformed input.
  3. Passes only the cleaned, structured record inward to Ring 2.

The public internet is never in direct contact with Ring 2 or Ring 3. Ring 2 has no outbound internet path except through service-egress.

[edit]Effect on audit integrity

Because raw payloads are sanitized at the boundary and the cleaned records are what Ring 2 processes, the audit ledger in Ring 2 reflects what the system acted on — not what arrived at the wire. This separation is a precondition of the WORM ledger design: the ledger records clean, validated events, not raw network traffic.

[edit]See also

Edit this page · View source