Zero Trust Architecture (ZTA)

Enterprise confidentiality, data sovereignty, and strict compliance with NIST SP 800-207 Zero Trust Architecture (ZTA) govern every architectural decision in this deployment. The system meets rigorous compliance requirements for organizations handling proprietary data and regulated workflows.

1. Zero Trust Architecture Tenets

The system enforces the four core tenets of NIST SP 800-207:

graph TD
    subgraph ZTAPrinciples [NIST SP 800-207 Zero Trust Tenets]
        AB[1. Assume Breach: Software and parsers can fail]
        NT[2. Never Trust, Always Verify: Explicit cryptographic authentication]
        LP[3. Least Privilege and Micro-Segmentation: Per-resource isolation]
        ZC[4. Zero Static Credentials: Keyless short-lived tokens]
    end

    subgraph Enforcement [System Enforcement Mechanisms]
        AB -->|Quarantined Containers| AppIsolation[Compute and Tier Isolation]
        NT -->|Mutual TLS and OIDC| GatewayEnforce[API Gateways and IAP]
        LP -->|User-Scoped Tokens| ScopeEnforce[Single-Resource OAuth Scopes]
        ZC -->|Workload Identity| IAMEnforce[Link-Local Metadata and HSMs]
    end

1. Assume Breach

Runtimes, containers, and third-party parsing dependencies that process external inputs are assumed to be vulnerable. Software boundaries ensure that a local container exploit cannot expand into a tenant-wide compromise.

2. Never Trust, Always Verify

Network locality, private VPC membership, and internal IP addressing confer zero implicit trust. Every request between microservices, cloud APIs, and administrative interfaces requires cryptographically signed tokens (OIDC, mutual TLS).

3. Least Privilege and Micro-Segmentation

Operational capabilities are isolated by privilege tier. Microservices possess access strictly to the resources required for their micro-task (for example: single mailbox OAuth vs. tenant-wide impersonation).

4. Zero Static Credentials

Static credentials, long-lived API keys, and exported private key files (*.json) are prohibited across all operational scripts, configurations, and runtime environments. Identities are minted dynamically via ambient cloud workload identities.

2. Platform vs. Application Threat Boundary Separation

Every security assessment and threat model decouples the system into two distinct architectural layers:

graph TD
    subgraph Layer2 [Layer 2: Application Software and Dependencies]
        direction TB
        AppCode[Our Software: Rust Binaries and Containers]
        Parsers[Input Parsers: MIME, Audio, JSON, Webhooks]
        AppCode --- Parsers
        Threat[Locus of Compromise: Parser exploit or zero-day]
    end

    subgraph Layer1 [Layer 1: Platform and Infrastructure Provider]
        direction TB
        CloudIAM[Google Cloud IAM and OAuth 2.0 Gateways]
        KMS[Cloud KMS and Hardware Security Modules]
        Perimeter[Private VPC and Firewall Isolation]
        Containment[Platform Hard Containment: Gateways reject unauthorized calls]
    end

    Layer2 -->|Requests Bound to Ambient Identity| Layer1

Layer 1: Platform & Infrastructure Provider (Google Cloud, Cloudflare, Google Workspace)

• Role: Identity provider (IAM, OAuth), cloud perimeter isolation, API enforcement gateways, and cryptographic hardware security modules (HSMs).
• Security Invariant: Assume the platform provider functions as designed. The cloud boundary, token validation, and OAuth scopes are cryptographically enforced by the provider’s gateways.

Layer 2: Application Software & Dependencies (Our Code, Containers & Crates)

• Role: Business logic, message routing, and parsing external inputs (emails, attachments, webhooks, audio frames).
• Security Invariant: Assume application software can have vulnerabilities, dependency defects, or zero-days.

Assessment Rules:

1. Locus of Compromise: Threats originating from external input processing compromise only the application container, not the platform provider.
2. Credential Abuse Vector: A compromised container abuses the ambient platform credentials assigned to its environment.
3. Platform Containment Boundary: The platform configuration defines the blast radius. If the platform permissions are cryptographically locked to a single mailbox (via user OAuth), horizontal lateral movement is impossible even when our application layer is fully compromised.

3. Service Account Privilege Boundary Separation

To enforce defense-in-depth and least privilege, identities are partitioned across operational tiers:

1. Independent Deployments (Mandatory Separation):
   • Microservices operating in distinct infrastructure tiers never share a service account.
   • Specifically, email-forwarder (Cloud Run) and org-assistant (Compute Engine VM) always use separate identities (email-forwarder@... and org-assistant@...).
2. Co-located Containers (Separation by Privilege Divergence):
   • Any container processing untrusted external inputs (such as browser automation or document parsing) must not share service accounts with components holding Domain-Wide Delegation.
3. Workspace Domain-Wide Delegation Scope Isolation:
   • Where Domain-Wide Delegation is used, scopes are strictly partitioned.
   • email-forwarder holds only https://www.googleapis.com/auth/gmail.readonly and https://www.googleapis.com/auth/chat.bot.
   • org-assistant holds https://www.googleapis.com/auth/gmail.compose and https://www.googleapis.com/auth/chat.bot.