Secret Isolation

A core design principle in Alien Giraffe is that secrets should not be shared across trust boundaries unless a runtime path explicitly requires them. The platform is designed to reduce long-lived credential exposure and to avoid turning the control plane into a generic credential broker.

Zero secret sharing across trust boundaries

In this architecture:

• secrets stay in the organization environment
• the platform does not act as a long-term store for organization credentials
• the control plane does not proxy unrestricted access to internal systems
• scoped credentials are created only when the approved runtime path requires them

This keeps authentication and approval logic separate from the environment that actually reaches protected data.

Configuration and secret material are kept separate

In the current admin and runtime model used by a10e-manager, datasource configuration is split into two distinct concerns:

• admin-facing datasource payloads use config_fields and secret_backend
• runtime execution uses secret_refs

That split matters because the platform does not need to treat every datasource field as equally sensitive. Hostnames, ports, schemas, and scan policy can remain part of normal configuration, while credentials are stored as backend-managed references rather than as plain values in datasource configuration.

For admin flows:

• secret-marked fields are submitted through config_fields with is_secret: true
• secret values are treated as write-only inputs
• secret values are not returned by datasource APIs after save
• the UI shows that a secret exists without showing the stored value again
• edits preserve existing secret values unless an admin explicitly replaces or clears them

This prevents the control plane from becoming a convenient read surface for organization credentials.

Secret backends and references

Alien Giraffe uses a pluggable secret backend model rather than assuming a single credential store. The current implementation ships with these secret backends:

• file
• java-keystore
• aws-secrets-manager

These backends serve different operational environments, but the isolation rule is the same in all cases: datasource definitions keep references to backend-managed secret material instead of persisting raw secret payloads in durable config.

file

The file backend is intended for local and operator-controlled environments. It can resolve secret values either from inline fields or from *_file paths.

java-keystore

The java-keystore backend stores secret values under deterministic aliases. Datasource secret references keep the alias mapping instead of exposing the underlying values again through admin APIs.

aws-secrets-manager

The aws-secrets-manager backend stores secret material in AWS Secrets Manager and keeps only a secret_id reference in the datasource metadata. At runtime, that secret is resolved into the canonical credential shape required by the request execution path.

From admin payload to runtime contract

The current flow looks like this:

1. An admin submits datasource configuration using config_fields.
2. Secret config fields are marked with is_secret: true.
3. The datasource also declares which backend should store those secret values with secret_backend.
4. a10e-manager writes the secret values into the selected backend.
5. The durable datasource record keeps backend-managed references in secret_refs rather than returning plaintext secrets later.
6. When a request is approved, the runtime receives only the scoped secret references it needs for the approved pull path.

This means the admin API is the write path for secret material, while the runtime contract is the resolution path.

Request-scoped secret resolution

When a request is approved, the platform does not hand the data enclave a general-purpose view of the secrets backend. It passes only the secret references and the narrow runtime inputs needed to resolve those specific references for that request.

That means:

• the control plane carries secret references, not a dump of secret values
• the enclave receives only the references needed for the approved datasources
• the enclave can resolve only the referenced secrets needed for that request
• the enclave remains blind to unrelated secrets that also exist in the backend

sequenceDiagram
    autonumber
    participant Admin as Admin Workflow
    participant CP as Control Plane
    participant SB as Secrets Backend
    participant DE as Data Enclave
    participant DS as Approved Datasource

    Admin->>SB: Store secret material in selected backend
    Admin->>CP: Save datasource config with secret_backend and config_fields
    CP->>CP: Persist datasource config plus secret_refs only
    CP->>DE: Provision approved enclave
    CP->>DE: Send request contract with scoped secret references
    CP->>DE: Attach minimal secret-resolution inputs
    DE->>SB: Resolve only referenced secret entries
    SB-->>DE: Return only the approved secret values
    DE->>DS: Authenticate and pull approved data

Why this matters

This model preserves the main trust-boundary guarantees:

• admins can rotate secrets without turning datasource APIs into a read surface for credentials
• the control plane persists references instead of plaintext values
• the runtime resolves only the secrets required for the approved request
• different deployments can use different backends without changing the request execution model

Related pages

• Read Configure Data Sources for the admin datasource contract.
• Read Data Enclaves for the runtime environment created after approval.
• Read Tunnel Architecture for how connectivity is established without opening inbound network paths.