Skip to content
Alien Giraffe

Tunnel Architecture

Alien Giraffe uses managed tunnels to expose approved, request-scoped access into a provisioned data enclave without turning that enclave into a general-purpose network bridge. A tunnel exists only for the lifetime of an approved access path and is tied to one request at a time.

Tunnel model

Section titled “Tunnel model”

The tunnel architecture has four stable properties:

  • tunnels are created per request rather than per organization or deployment
  • each tunnel is attached to a single provisioned environment
  • access is mediated through a10e-manager edge routes and temporary tunnel credentials
  • only request-approved services are reachable through the tunnel surface after the enclave has completed its ingestion phase and entered a ready state

That keeps the tunnel inside the overall trust boundary instead of making it a bypass around policy or runtime isolation.

Provider architecture

Section titled “Provider architecture”

Alien Giraffe treats the transport provider as a pluggable capability. Tunnel providers include:

  • Cloudflare
  • ngrok

The architectural contract is the same regardless of provider:

  • the platform creates a request tunnel and tracks its status
  • the provider publishes a public entrypoint for that request
  • a10e-manager serves the authenticated tunnel edge
  • traffic is forwarded only into the approved request runtime

The exact provider transport and operational mechanics may differ, but the public access model stays the same.

Request-scoped lifecycle

Section titled “Request-scoped lifecycle”

In the current request flow:

  1. A user creates a tunnel for an active request that already has a provisioned environment.
  2. a10e-manager creates a request-tunnel record and assigns the selected provider.
  3. a10e-manager issues temporary credentials for that tunnel session.
  4. The enclave completes its approved ingestion phase, materializes the approved data, and clears pull credentials.
  5. The provider publishes a request-specific public base URL.
  6. a10e-manager exposes the request tunnel edge, explorer view, and API access paths for that tunnel.
  7. When the request is revoked, expires, or the tunnel is explicitly deleted, the tunnel is torn down and marked unavailable.

Only one active tunnel is allowed per request at a time.

Public tunnel surface

Section titled “Public tunnel surface”

The managed tunnel exposes a small, request-bound surface:

  • a root entrypoint for the request tunnel
  • an explorer interface for interactive access
  • an API path for request-scoped calls into the data runtime

These routes are served by a10e-manager, which authenticates the tunnel request and then forwards approved traffic into the request environment.

Authentication and access control

Section titled “Authentication and access control”

Tunnel access is temporary and credentialed. A tunnel session can be accessed with:

  • a temporary API key
  • temporary Basic Auth credentials

Those credentials are issued specifically for the request tunnel. a10e-manager validates them on each tunnel edge request before allowing access to explorer or API routes.

This means the tunnel is not an anonymous provider URL. It is a mediated access surface with per-tunnel authentication layered on top.

What the tunnel is for

Section titled “What the tunnel is for”

Request tunnels are intended for:

  • interactive exploration through the request explorer
  • request-scoped API access into the data enclave
  • controlled access to services that are part of the approved request runtime

They are not intended to:

  • expose the whole environment as a flat network
  • create long-lived organization-wide connectivity
  • bypass the request lifecycle, scope, or audit model

Auditability

Section titled “Auditability”

Tunnel activity participates in the same audit story as the rest of the request lifecycle. The platform records events such as:

  • tunnel creation and deletion
  • tunnel credential use
  • tunneled query execution

These records can be correlated back to the request, the tunnel, and the credential used for access.

Section titled “Related pages”