This document provides a comprehensive security review of DuckPipe for enterprise security teams evaluating the platform for production deployment. It covers the threat model, data flow analysis, control inventory, compliance mapping, and penetration testing guidance.

Use this document as the basis for your Software Lifecycle (SLC) security review.

1. Executive Summary
2. Threat Model
3. Data Flow Analysis
4. Credential Management
5. Agent Isolation Model
6. Audit System
7. Network Security
8. Input Validation & Injection Prevention
9. Authentication & Access Control
10. Trust Tier Enforcement
11. Dependency Security
12. Compliance Mapping
13. Penetration Testing Guide
14. SLC Review Checklist
15. Known Limitations
16. Incident Response

DuckPipe is a self-hosted, autonomous agent platform that monitors and manages data infrastructure (Airflow, Snowflake, dbt) through isolated Docker containers. It is designed with the assumption that it will be connected to production systems and handles this responsibility through:

• Zero cloud relay: No data, credentials, or telemetry leaves the deployment network
• Memory-only secrets: Credentials are never written to disk or logged
• Agent isolation: Each agent runs in a separate process or Docker container with scoped credentials
• Immutable audit log: Every action is logged before execution; logs cannot be modified or deleted
• Tier 1 read-only: The only supported tier today — no write actions possible at code level

Risk classification: Low risk. DuckPipe operates exclusively at Tier 1 (read-only). No write actions are supported. The policy engine blocks all writes unconditionally.

┌──────────────────┐     startup      ┌──────────────────┐
│  Secret Source    │────────────────▶│  Vault Module     │
│  .env / Vault /  │                  │  (in-memory only) │
│  AWS SM          │                  └────────┬─────────┘
└──────────────────┘                           │
                                               │ on-demand read
                                               ▼
                                    ┌──────────────────┐
                                    │  Orchestrator     │
                                    │  (main process)   │
                                    └────────┬─────────┘
                                             │
                              task dispatch (bus JSON, in-memory creds)
                                             │
                    ┌────────────┬───────────┼───────────┬────────────┐
                    ▼            ▼           ▼           ▼            │
            ┌────────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐   │
            │  Airflow   │ │   dbt    │ │Snowflake │ │  Comms   │   │
            │  Agent     │ │  Agent   │ │  Agent   │ │  Agent   │   │
            └─────┬──────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘   │
                  │             │             │            │          │
                  ▼             ▼             ▼            ▼          │
           Airflow API    dbt Cloud     Snowflake     Slack/Jira     │
           (HTTPS)        (HTTPS)       (HTTPS)       (HTTPS)       │
                                                                     │
                                                      Audit Log ◀────┘
                                                      (SQLite, local)

Key properties:

• Credentials exist in memory only. They are passed from the vault to the orchestrator to agents in bus message payloads.
• Bus files containing credentials are deleted immediately after the agent reads them.
• No credential is ever written to a log file, stdout, or the audit log.
• No outbound connection to any Duckcode-controlled server is made at any time.

Snowflake ──SELECT──▶ Snowflake Agent ──results──▶ Orchestrator ──▶ Audit Log
                                                         │
                                                         ▼
                                                   Workflow Logic
                                                         │
                                                         ▼
                                                   Comms Agent ──▶ Slack/Jira

Key properties:

• Only SELECT queries are executed against Snowflake (enforced at DB role level and application level)
• Query results are used for analysis (cost, performance) and discarded — they are not persisted to disk
• Data posted to Slack/Jira is diagnostic (query metadata, error messages) — never raw table data

interface VaultBackend {
  get(key: string): Promise<string>;
  // No set(), no delete() — DuckPipe never writes to the vault
}

The read-only interface is intentional. DuckPipe consumes secrets; it never manages them. Your secrets infrastructure (Vault, AWS SM, env files) remains the single source of truth.

1. Load: On startup, vault backend reads credentials from source into process memory
2. Cache: Credentials cached in-memory (HashiCorp: 5-min TTL with auto-refresh)
3. Distribute: Orchestrator passes credentials to agents via bus task payloads (in-memory)
4. Consume: Agent uses credential for a single HTTPS API call
5. Discard: Bus file deleted after read; no persistent storage of credentials

• Credentials are never written to console.log, console.debug, or any log level
• Credentials are never written to the audit log (input_json is sanitized)
• Credentials are never written to the SQLite database
• Credentials are never written to bus files that persist (files are deleted after read)
• Credentials are never sent to any Duckcode-controlled server

Each of the four agents (airflow, dbt, snowflake, comms) runs in its own Docker container:

┌─────────────────────────────────────────────────────────┐
│                    Host Machine                          │
│                                                          │
│  ┌──────────────┐  ┌──────────┐  ┌──────────┐  ┌──────┐│
│  │ Airflow Agent│  │dbt Agent │  │ SF Agent │  │Comms ││
│  │  Container   │  │Container │  │Container │  │Agent ││
│  │              │  │          │  │          │  │      ││
│  │ Has: Airflow │  │Has: dbt  │  │Has: SF   │  │Has:  ││
│  │   creds only │  │creds only│  │creds only│  │Slack ││
│  │              │  │          │  │          │  │Jira  ││
│  │ No network   │  │No network│  │No network│  │Confl.││
│  │ to other     │  │to other  │  │to other  │  │creds ││
│  │ containers   │  │containers│  │containers│  │only  ││
│  └──────┬───────┘  └────┬─────┘  └────┬─────┘  └──┬───┘│
│         │               │             │            │     │
│         └───────────────┴──────┬──────┴────────────┘     │
│                                │                          │
│                    Filesystem IPC (bus/)                   │
│                    Orchestrator Process                    │
└─────────────────────────────────────────────────────────┘

When Docker is unavailable (development, CI), agents run as child processes. The same IPC bus is used. Credential scoping and timeout enforcement still apply. Container isolation is not available in process mode — document this in your risk assessment if using process mode in production.

The audit log uses SQLite with triggers that prevent any modification:

CREATE TRIGGER prevent_audit_update
BEFORE UPDATE ON audit_log
BEGIN SELECT RAISE(ABORT, 'audit_log is immutable — no updates permitted'); END;

CREATE TRIGGER prevent_audit_delete
BEFORE DELETE ON audit_log
BEGIN SELECT RAISE(ABORT, 'audit_log is immutable — no deletes permitted'); END;

These triggers are enforced by the SQLite engine itself. Application code, SQL injection, or direct database access cannot bypass them without dropping and recreating the table (which requires file-level access and would be detected by file integrity monitoring).

The orchestrator calls logAction() before dispatching any agent task:

1. Audit entry written (workflow, agent, tool, tier, input, write_action flag)
2. If write fails (disk full, DB locked): action is not executed
3. Agent executes the task
4. Result (output, duration, success, error) written to companion table

This guarantees that every action that executes has a corresponding audit record created before execution began.

npx duckpipe audit --format json --since 2026-03-01 > audit-export.json
npx duckpipe audit --format csv --since 2026-03-01 > audit-export.csv

Exports include all fields. Use these for compliance reporting, incident investigation, or feeding into your SIEM.

DuckPipe makes outbound HTTPS connections to only the services you configure:

• No connection to duckpipe.dev, duckcode.ai, or any Duckcode-controlled server
• No telemetry, analytics, crash reporting, or usage tracking
• No license validation or phone-home
• No auto-update mechanism

DuckPipe can run in air-gapped environments. Requirements:

1. Docker images pre-pulled and available in a local registry
2. npm packages installed from a local mirror or vendored
3. Configuration points to internal-only API endpoints

All user-controlled inputs to Snowflake queries are validated:

The Snowflake agent rejects any query containing DDL/DML keywords (CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, GRANT, REVOKE) regardless of trust tier. The Snowflake role grants enforce this at the database level as a second line of defense.

All inter-process messages are validated using Zod schemas before processing. Malformed messages are logged and discarded.

duckpipe.yaml is validated against a Zod schema at startup. Invalid configuration prevents startup rather than falling back to defaults.

Health endpoints (/api/health/live, /api/health/ready) bypass authentication for Kubernetes probes.

CORS is restricted to http://localhost:9876 when no token is set, or * when a token is set (for reverse proxy deployments).

DuckPipe currently supports only Tier 1 (read-only). Tiers 2 and 3 are on the roadmap but not implemented.

The trust tier is checked at three levels:

1. Policy engine (src/policy.ts): Returns { allowed: false } for every write action at Tier 1
2. Orchestrator (src/orchestrator.ts): executeWriteAction() calls policy check before dispatch — always blocked at Tier 1
3. Agent tools: Write tools exist in agent code but are unreachable at Tier 1

When trust_tier: 1 (the only supported value):

• The policy engine returns { allowed: false } for every write action
• No configuration, policy file, or agent behavior can override this
• The code path for write execution is unreachable
• This is verified by automated tests (tests/policy.test.ts, tests/orchestrator-approval.test.ts)

• Maximum 6 runtime dependencies (enforced by project policy)
• All dependencies must have been updated within the last 6 months
• package-lock.json is committed and used for deterministic installs
• No post-install scripts in the dependency tree
• No native modules except better-sqlite3 (compiled, audited, widely used)

• Lock file ensures reproducible builds
• No dependency auto-update mechanism
• Recommend running npm audit as part of your CI pipeline
• All dependencies are from established, well-maintained projects

DuckPipe does not process, store, or transmit Protected Health Information (PHI). It accesses database metadata and query execution plans — not table contents. If your Snowflake query history may contain PHI in query text, configure watched_databases to scope access.

DuckPipe does not process cardholder data. It monitors pipeline health and query costs. Snowflake role grants should exclude databases containing cardholder data from DuckPipe's scope.

Use this section to scope a penetration test of your DuckPipe deployment.

1. Deploy DuckPipe with all integrations pointing to test/staging instances
2. Keep trust_tier: 1 (the only supported value) to test realistic code paths
3. Monitor audit log during testing to verify action recording
4. Test with both Docker and process runtime modes

Use this checklist for your enterprise security review board.

• All credentials stored in memory only — never written to disk, logs, or database
• Agent containers isolated with no inter-container networking
• Audit log immutability enforced by SQLite triggers (not application logic)
• Trust tier model prevents Tier 1 from executing any write action
• No outbound connections to vendor-controlled servers
• No telemetry, analytics, or usage reporting

• Vault module implements read-only interface (no set/delete operations)
• HashiCorp Vault backend implemented with in-memory caching
• AWS Secrets Manager backend available (interface defined)
• Snowflake key-pair JWT authentication supported (no password required)
• Credentials sanitized from audit log entries

• Dashboard binds to localhost by default; requires bearer token for remote access
• Slack listener filters by allowed_channels — no DM support
• Snowflake role grants follow least privilege (DUCKPIPE_READER — SELECT only)
• Airflow permissions use Viewer role (read-only)
• Policy engine blocks all write actions at Tier 1 (the only supported tier)

• SQL injection prevention with strict regex validation on identifiers
• SELECT-only enforcement on Snowflake queries (application + database level)
• Bus messages validated against Zod schemas
• Configuration validated at startup — invalid config prevents boot

• Every action logged before execution (pre-execution audit)
• Audit log supports JSON and CSV export for SIEM integration
• Dashboard provides real-time monitoring via SSE
• Health endpoints available for Kubernetes liveness/readiness probes

• Docker Compose configuration provided for local deployment
• Kubernetes manifests provided with RBAC, secrets, and probes
• Air-gap deployment supported (no external dependencies at runtime)
• Node.js >= 20 LTS required (active LTS with security updates)

• 121+ automated tests covering policy, audit, injection prevention, workflows
• Mock transport used in tests — no real API calls in test suite
• Tier enforcement tested explicitly (Tier 1 cannot trigger writes)
• SQL injection regression tests for Snowflake agent

If you suspect a security issue in DuckPipe:

1. Check the audit log: npx duckpipe audit --since <timestamp> to see all actions
2. Verify permissions: npx duckpipe verify to confirm current access levels
3. Revoke credentials: Rotate the affected integration's credentials in your secrets backend
4. Export audit: npx duckpipe audit --format json for forensic analysis
5. Report: Open a security issue at github.com/duckcode-ai/duckpipe (use responsible disclosure for critical vulnerabilities)

Copyright 2026 Duckcode.ai · Licensed under Apache 2.0