Channels

Channels represent how an approved request is used once access has been granted. In the current Alien Giraffe model, channels are not a broad catalog of application types or direct database connection methods. They are the approved interaction surfaces exposed for a request-scoped data enclave.

Today there are two channel types:

• Web-based access through the data explorer
• API-based access through request-scoped query endpoints

Each of those channels can be delivered in one of two network modes:

• Internal access through the organization’s network
• Tunnel access through a temporary data tunnel

Relationship to Policies

Channels are one of the five core components that policies coordinate. When a policy references channels:, it is defining the allowed interaction mode for the approved request, not granting a generic network path or raw datasource credentials.

That distinction matters:

• policies approve an interaction surface
• the platform provisions a request-scoped runtime for that interaction
• the user or client reaches the runtime only through the approved channel

Channel Model

The current channel model is intentionally narrow:

• channels are request-scoped, not organization-wide
• channels are bound to an approved and active request
• channels expose prepared enclave data, not direct upstream datasource access
• channels inherit the same audit, lifecycle, and revocation model as the request

This means a channel should be understood as an access surface over an enclave, not as a standing integration contract for arbitrary applications.

Interaction Types

Data Explorer

The data explorer is the web-based interaction channel.

It is intended for:

• interactive schema browsing
• read-only SQL execution
• analyst-driven exploration of the data loaded into the enclave

In the current runtime flow, the explorer ultimately runs read-only queries against the prepared enclave data plane. It does not open a general database session back to the original datasources.

API Access

The API channel is the programmatic interaction surface.

It is intended for:

• request-scoped query execution
• service or script-driven access to approved enclave data
• controlled integration with internal tools that should consume results over HTTP rather than through a browser

In the current implementation, the core read-only query surface is exposed as a request-bound API path and proxied into the enclave runtime.

Delivery Modes

Internal Network Access

Internal access is the default delivery mode when users or systems can already reach Alien Giraffe from inside the organization’s network boundary.

In this mode:

• the requester uses authenticated Alien Giraffe endpoints directly
• the platform proxies approved requests into the provisioned enclave
• no public tunnel URL is required

This is the right model for:

• internal analysts
• admin or operations users on the corporate network
• internal services that can already reach the platform directly

Data Tunnel Access

Tunnel access is the temporary externalized delivery mode for the same interaction types.

In this mode:

• a tunnel can be created only for an active request with a provisioned environment
• the tunnel exposes a request-scoped root, explorer path, and API path
• access is authenticated with temporary tunnel credentials
• the tunnel exists only for the lifetime of that request access path

The tunnel does not create a general-purpose network bridge. It exposes the same request-scoped explorer and API surfaces through a temporary mediated edge.

Current Request Surfaces

In the current implementation, the request-scoped channels map to these surfaces:

• internal API query access through POST /v1/requests/:id/query
• internal natural-language-to-SQL assistance through POST /v1/requests/:id/nl-to-sql
• tunnel management through:
  • GET /v1/requests/:id/tunnel
  • POST /v1/requests/:id/tunnel
  • DELETE /v1/requests/:id/tunnel
• tunnel-delivered explorer and API access through:
  • GET /v1/tunnels/:id/edge
  • GET /v1/tunnels/:id/edge/explorer
  • ANY /v1/tunnels/:id/edge/api/*path

These surfaces are all request-bound. They become unavailable when the request is revoked, expires, or the runtime is torn down.

What Channels Are Not

Channels do not currently mean:

• direct database connectivity from end users to upstream datasources
• long-lived application registrations with independent standing permissions
• a generic catalog of SaaS, ETL, notebook, or microservice integration types
• unrestricted inbound access to the enclave environment

Those patterns may still matter at the architecture or product-planning level, but they are not the current request interaction model exposed by the platform.

Security and Audit Expectations

Every channel participates in the same core control model:

• request approval happens before the channel is exposed
• the enclave is provisioned and prepared before interactive use
• access remains bound to request state and channel credentials
• query activity is auditable
• tunnel credential use is auditable
• revocation or expiry removes the channel

This keeps channels aligned with the platform’s main trust boundary: approved, time-bounded interaction with prepared enclave data.

Example Policy Shape

At the policy level, the important distinction is the interaction mode, not an infrastructure-specific client type.

channels:
  - type: explorer
    delivery: internal

  - type: api
    delivery: tunnel

This should be read as:

• allow interactive web exploration through the internal platform surface
• allow programmatic API access through a temporary data tunnel

The exact request lifecycle, credentials, and runtime URLs are then provisioned by the platform for that approved request.

Related Pages

• Read Data Enclaves for the runtime that serves approved channel access.
• Read Tunnel Architecture for the temporary tunnel delivery model.
• Read Policies for how channels combine with subjects, resources, constraints, and context.