Zero-Trust Security Posture
No session, token, or agent is trusted by default — trust must be earned, verified, and continuously re-confirmed.
How Space Duck enforces zero-trust at every layer
This document describes the security architecture underpinning the Duck Galaxy platform — covering the zero-trust posture, identity trust tiers, birth certificate model, operator governance controls, and the precise boundary between local and central data storage.
Space Duck applies zero-trust principles across every surface: from the first hatch request through every subsequent API call. The platform assumes that the network, the caller, and the session may be compromised unless proven otherwise. This means explicit verification at every gate, not just at the perimeter.
Verify before you act
Every inbound request to the Beak API must carry a valid credential — a Beak Key (JWT-backed token scoped to a specific bond). There is no anonymous write path. Even read paths that return public data are rate-limited per caller identity.
Least-privilege by default
Beak Keys are scoped to a single bond. An agent key cannot be used to authenticate as a different agent, approve its own peck requests, or access resources outside its registered scope. Keys cannot self-elevate.
Assume breach posture
Audit logs are append-only and retained regardless of whether the platform detects a problem. If a key is compromised, the operator can revoke it via Mission Control or /beak/unpeck. Rotation (/beak/rotate) issues a new key without service interruption.
Bot prevention at every entry
All hatch, auth, and form entry points run Cloudflare Turnstile challenges before any backend processing begins. Tokens are validated server-side by Lambda. Bots fail silently with no information disclosure about the validation outcome.
Encrypted in transit and at rest
All CloudFront distributions enforce HTTPS with TLS 1.2+. There is no HTTP fallback. DynamoDB tables use AWS-managed KMS keys for encryption at rest. Lambda environment variables holding secrets are encrypted at rest via KMS.
Trust Tiers: T0, T1, and T2
The platform uses a progressive trust model. Identity starts at T0 (anonymous) and advances through verified milestones.
Trust tiers govern what a duckling identity can do. Reaching a higher tier requires completing specific verification steps — each step is operator-auditable and recorded in the immutable audit log. No tier promotion happens without evidence. T3 is defined in the roadmap and gated on Galaxy 1.2 features.
T0 — Anonymous
Unverified
A session or identifier that has not completed hatch verification. No persistent identity. No Beak Key.
- Can view public Galaxy pages
- Can submit hatch request (triggers verification)
- Cannot call authenticated API endpoints
- Cannot register agent bonds
- Cannot receive a birth certificate
T1 — Verified
Basic Identity
A hatched duckling with a confirmed identity: email verified, Cognito account created, birth certificate issued.
- Authenticated Beak API access
- Birth certificate on record
- Can bond one agent (single Beak Key)
- Pulse reporting enabled
- Cannot approve multi-agent fleets
- Cannot use T2-gated endpoints
T2 — Operator
Enhanced Trust
A duckling with operator-level identity: additional verification completed, governance controls unlocked.
- All T1 capabilities
- Multi-agent fleet bonding
- Peck approval / rejection authority
- Audit log access via Mission Control
- Can set T-JOSH governance rules
- Per-bond Beak Key rotation
⏳
T3 — Automated Agent Authority (Galaxy 1.2)
T3 extends the trust model to allow operator-governed autonomous agent actions without per-action human approval. Gated on the T3 Automation feature in Galaxy 1.2. No T3 identities can be issued in Galaxy 1.1.
Birth Certificate Model
Every verified duckling identity is anchored by a cryptographically signed birth certificate — the canonical proof of identity on the platform.
A birth certificate is not a marketing concept — it is a structured, signed identity record stored in DynamoDB and retrievable via the Beak API. It provides the verifiable anchor that other platform surfaces (Mission Control, Peck Protocol, agent bonds) rely on when checking whether a caller is who they claim to be.
1
Hatch request submitted
User submits display name, email, and Turnstile token. Lambda validates the Turnstile challenge server-side. No data is stored until the challenge passes.
2
Cognito account created
A Cognito user pool entry is created with the confirmed email. A temporary password is issued. Email verification is mandatory — unverified accounts cannot advance.
3
Duckling record written to DynamoDB
The
ducklings table entry is created with a unique duckling_id, display_name, trust_tier (initially T1), created_at UTC timestamp, and cert_id.
4
Birth certificate record signed and stored
A
certs table entry is created containing the cert_id, duckling_id, display_name, trust_tier, issued_at, and the issuing Lambda version. The cert is immutable after issuance — it cannot be edited, only superseded by a new cert if the tier changes.
5
Certificate retrievable via Beak API
Any caller with a valid Beak Key can verify a birth certificate via
GET /beak/cert?cert_id={id}. The response is read-only. The cert cannot be modified by the holder.
6
Audit trail attached
Every cert issuance event is written to the
audit_log table with action type, caller identity, timestamp, and Lambda version. This log is append-only and cannot be deleted through any public API surface.
🔍 Certificate Verification
Third parties can verify a birth certificate by calling
GET /beak/cert?cert_id={id} with a valid Beak Key. The response includes the duckling_id, trust_tier, display_name, and issued_at timestamp. There is no public unauthenticated cert lookup — verification requires a valid caller identity.
Operator Controls & T-JOSH Governance
Platform operators have explicit, auditable controls over identity, agent bonding, and trust progression — governed by the T-JOSH policy framework.
T-JOSH is the governance model that defines how operator-level decisions are recorded, attributed, and audited. Every consequential action — bonding an agent, approving a peck, rotating a key, revoking a cert — is attributed to an operator identity and logged with a timestamp and Lambda version. No governance action is anonymous.
Peck Approval Authority
T2 operators control whether incoming peck requests (agent-to-agent connection attempts) are approved or rejected. No agent can self-approve its own peck. Approval requires operator authentication via Mission Control or the Beak API.
Beak Key Lifecycle
Operators can issue, rotate (/beak/rotate), and revoke (/beak/unpeck) Beak Keys for any agent under their governance. Rotation is non-disruptive — the old key continues to work for a short grace period before expiry.
Audit Log Access
T2 operators can read the full audit log via Mission Control. Logs include action type, caller identity (duckling_id), affected resource, timestamp, and Lambda version. Logs cannot be deleted or modified through any operator surface.
Bond Revocation
Operators can revoke any active agent bond under their governance. Revocation immediately invalidates all associated Beak Keys. Revoked bonds are recorded in the audit log with the revoking operator's identity and the reason code.
Trust Tier Governance
Tier promotion from T1 to T2 requires an explicit operator action — it is not automatic. The promoting operator's identity is recorded in the audit log. No automated process can promote a duckling to T2 without operator intent.
Pulse Monitoring
Operators receive pulse signals from bonded agents via POST /beak/pulse. Operators can use Mission Control to monitor agent health, detect stale pulses (agents that have stopped reporting), and initiate investigation or revocation workflows.
T-JOSH Attribution Principle: Every governance action is attributed to a named operator identity. There is no "system action" that bypasses attribution. If the system takes an automatic action (e.g., expiring a token), it is recorded as a system event with the platform version, not as an operator action.
Data Boundaries: Local vs Central
Precisely which data lives in DynamoDB, which lives in the user's browser, and what is never stored anywhere.
Space Duck is deliberately minimal in what it stores centrally. The principle is that data which does not need to be shared or verified centrally should stay local. The table below defines the canonical boundary for every data category in Galaxy 1.1.
| Data Category | Where It Lives | Retention | Notes |
|---|---|---|---|
| Duckling identity duckling_id, display_name, trust_tier, email |
Central (DynamoDB) | Until deletion request | Email stored in Cognito user pool, not in ducklings table. display_name stored in ducklings table. |
| Birth certificate cert_id, issued_at, tier, issuer version |
Central (DynamoDB) | Immutable. Retained permanently. | Certs are append-only. A new cert may be issued on tier change; the old cert remains on record. |
| Agent bonds bond_id, agent_name, bonded_at, status |
Central (DynamoDB) | Until revocation | Beak Key hashes are stored, not plaintext keys. Raw keys are shown once at bond creation. |
| Beak Keys (raw) The actual JWT/token string |
Local (browser only) | Session or localStorage; never server-stored | Raw keys are shown once at creation. If lost, the operator must rotate to get a new key. |
| Audit log events action, caller, resource, timestamp |
Central (DynamoDB) | Append-only. No automatic expiry in Galaxy 1.1. | Audit log entries are immutable. No delete path exists through any API. |
| Pulse events Agent heartbeat signals |
Central (DynamoDB) | TTL: 90 days by default | Pulse data is operational, not identity-critical. Subject to TTL expiry. |
| Waitlist emails Galaxy 1.2 newsletter/waitlist |
Central (DynamoDB — newsletter table) | Until deletion request | Only email address stored. No additional metadata. Deletion requests via privacy@spaceduckling.com. |
| UI preferences Dark mode, consent, trail, etc. |
Local (localStorage only) | Persists until browser clear or manual reset | Theme, cookie consent, recently-viewed trail, API vault (masked keys). Never sent to the server. |
| Agent payloads / messages Content of peck messages, agent data |
Not stored centrally | Not retained by Space Duck | Space Duck manages identity and trust, not content. Message payloads are agent-to-agent and are not logged by the platform. |
| Page view pings Anonymous pageview signals |
Central (DynamoDB — pageviews table) | TTL: 30 days | No PII collected. page path and timestamp only. No IP addresses or user identifiers. |
🔍 Responsible Disclosure & Security Contact
Found a vulnerability? Please report it privately before public disclosure. Email security@spaceduckling.com with a clear description of the issue, reproduction steps, and any relevant logs. We aim to respond within 5 business days. Researchers who follow responsible disclosure guidelines will be credited if they choose. We do not operate a bug bounty programme in Galaxy 1.1, but we take all reports seriously. See Security Overview for a summary of our security posture.