Autonomous cognitive companion deployed for TAČR.

Welcome to the dedicated organizational assistant portal and security documentation for TAČR.

This technical portal provides complete transparency regarding deployment boundaries, communication protocols, privilege isolation, and data protection mechanisms. It is designed for Enterprise CISOs, Information Security Officers, Compliance Auditors, and Workspace Administrators.

Tenant Deployment Profile

The table below summarizes the active configuration, infrastructure isolation tier, and runtime components provisioned for this deployment:

Active Component Inventory

This portal reflects only the features and infrastructure components enabled for TACR:

• Google Chat Connector: Real-time conversational interface, Pub/Sub webhook ingestion, and bot identity isolation.
• Google Meet & Audio Pipeline: Headless virtual display, PipeWire audio loopback, and streaming speech-to-text.

Core Security Invariants

All components deployed for TACR enforce three non-negotiable security baselines:

1. NIST SP 800-207 Zero Trust Architecture: Every interaction requires explicit cryptographic verification. The system assumes that software processing external inputs can be compromised. Privilege boundaries prevent lateral movement.
2. Platform vs. Application Layer Separation: Security boundaries are enforced by cloud identity providers (Google Cloud IAM, OAuth 2.0 gateways) rather than software configurations.
3. Data Sovereignty and Zero Retraining: Enterprise data, messages, transcripts, and documents are never used to train generalized artificial intelligence models.

Navigate the chapters in the sidebar or use the search bar above to review the architecture and threat evaluations for each system layer.

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.

Infrastructure & Perimeter Isolation

The organizational assistant operates inside a dedicated, isolated perimeter provisioned within the customer’s chosen cloud tenant. Network exposure, identity management, and container execution follow strict defense-in-depth principles.

1. Perimeter Isolation & Network Topology

graph LR
    subgraph PublicInternet [Public Internet]
        User[Corporate User]
        API[Workspace API Gateway]
    end

    subgraph VPC [Private Cloud VPC / Internal Network]
        CloudNAT[Cloud NAT Gateway]
        IAP[Identity-Aware Proxy: Port 22]

        subgraph PrivateVM [Private Dedicated VM: No Public IP]
            Host[Linux Host OS]
            Container[Quadlet Container: Unprivileged User]
        end
    end

    User -->|TLS 1.3 HTTPS| API
    API -->|Encrypted Pub/Sub| PrivateVM
    IAP -.->|Encrypted SSH Tunnel| PrivateVM
    PrivateVM -->|Egress via NAT| CloudNAT
    CloudNAT -->|Outbound HTTPS| PublicInternet

Zero Public IP Addresses

• Host compute instances are provisioned with --no-address. No public IPv4 or IPv6 addresses are allocated or bound to network interfaces.
• Inbound connections from the public internet are disabled at the VPC network firewall level.

Administrative Access via Identity-Aware Proxy (IAP)

• Administrative access operates exclusively through Google Cloud Identity-Aware Proxy (IAP) tunnels (--tunnel-through-iap).
• No SSH ports are exposed to the internet.
• Connection requires enterprise identity authentication, Multi-Factor Authentication (MFA), and explicit IAM role assignment (roles/iap.tunnelResourceAccessor).

Outbound Traffic via Cloud NAT

• External API calls (to Google Workspace APIs, Pub/Sub endpoints, and inference models) route through a dedicated Google Cloud NAT gateway.
• The Cloud NAT gateway provides controlled, monitored outbound internet access without exposing the VM to inbound traffic.

2. Compute Runtime & Container Sandboxing

graph TD
    subgraph VMHost [Compute Engine Host Instance]
        subgraph UserSpace [Unprivileged User Context: uid 1000]
            Quadlet[systemd Quadlet Service Manager]
            subgraph ContainerSandbox [Rootless Podman Sandbox]
                direction TB
                App[Org Assistant Process]
                Tmpfs[(In-Memory tmpfs: /tmp)]
                ReadOnlyFS[Read-Only Container Rootfs]
            end
        end
    end

    Quadlet -->|Manages Lifecycle| ContainerSandbox
    App -->|Writes Ephemeral Cache| Tmpfs

1. Rootless Container Execution: The core assistant daemon runs under an unprivileged user context (org-assistant, UID 1000) using systemd Quadlet and Podman.
2. Read-Only Root Filesystem: Container root filesystems are mounted read-only wherever supported by workload constraints.
3. In-Memory Ephemeral Storage: Scratch data and session caches reside on volatile tmpfs mounts that clear immediately upon process termination.
4. Process Isolation: The container operates within separate mount, network, PID, and IPC namespaces.

3. Cryptographic Secret Management

• Secrets at Rest: All client profile configurations (encrypted.config.json and encrypted.clients.json) are encrypted using Mozilla SOPS backed by Google Cloud KMS or Age keys.
• Zero Environment Variables for Operational Secrets: Operational tasks, provisioning scripts, and container definitions never pass API tokens or private credentials via ambient environment variables.
• In-Memory Provisioning: Decrypted configuration blocks stream directly into the isolated runtime memory or transient tmpfs mounts across encrypted SSH/IAP pipes. No plaintext configuration files persist on developer workstations.
• Workload Identity: Server-to-server Google API requests authenticate dynamically using the VM link-local metadata server (http://metadata.google.internal), minting short-lived OAuth access tokens with 1-hour lifespans.

Data Privacy & Model Sovereignty

Data protection and regulatory compliance are integral to the system architecture. Enterprise data processed by the assistant remains under the strict control of the customer organization.

1. Google API Services User Data Policy Compliance

The assistant complies strictly with the Google API Services User Data Policy, including the Limited Use requirements:

2. Zero AI Model Retraining & Sovereign Processing

graph LR
    subgraph EnterprisePerimeter [Client Security Perimeter]
        DataIn[Inbound Communications: Email, Chat, Audio]
        Core[Cognitive Assistant Core]
    end

    subgraph LLMInference [Enterprise AI Inference Endpoint]
        InferenceEngine[Private Model Runtime]
        Weights[(Model Weights: Static Freeze)]
    end

    DataIn --> Core
    Core -->|Stateless Prompt Context| InferenceEngine
    InferenceEngine -.->|Zero Weight Update| Weights
    InferenceEngine -->|Ephemeral Response| Core

• Stateless Inference: Text prompts and context windows sent to language model inference endpoints are processed statelessly.
• Strict Prohibition on Model Fine-Tuning: Client communications, meeting transcripts, channel conversations, and indexed corporate documents are never retained by model providers for training, retraining, or model tuning.
• Contractual Zero-Retention: Inference integrations utilize enterprise endpoints configured with zero data logging and zero retention agreements.

3. Data Sovereignty & Retention Invariants

1. Dedicated Client Projects: Compute resources, Pub/Sub topics, Secret Manager secrets, and Firestore document databases reside in a dedicated Google Cloud project assigned strictly to the tenant organization.
2. Zero Cross-Tenant Leakage: Infrastructure components are not shared across clients. No database table or messaging topic contains data from multiple tenants.
3. Transient Memory: Short-term conversational context is retained only in volatile container memory during an active session and discarded upon session close.
4. On-Demand Data Erasure: Tenant administrators hold full authorization to trigger immediate data deletion across all project storage buckets, Firestore documents, and local caches.

Google Chat Connector

The Google Chat connector provides bidirectional, real-time message routing between corporate Google Chat spaces and the cognitive assistant runtime.

1. Flow Architecture

graph TD
    subgraph GoogleWorkspace [Google Workspace Perimeter]
        User[Corporate User]
        ChatAPI[Google Chat App: Bot Identity]
    end

    subgraph GoogleCloud [Customer Dedicated Google Cloud Project]
        Topic[Pub/Sub Topic: chat-events-topic]
        Sub[Pub/Sub Subscription: chat-events-sub]

        subgraph VMRuntime [Compute Engine Private VM]
            Assistant[Org Assistant Runtime]
        end
    end

    User -->|Sends @mention / Direct Message| ChatAPI
    ChatAPI -->|Pub/Sub Push Event| Topic
    Topic --> Sub
    Sub -->|Pull Stream: Long-Polling| Assistant
    Assistant -->|REST API: chat.bot Scope| ChatAPI

1. Inbound Webhook Delivery: When a user interacts with the bot via direct message or @mention in a space, Google Chat delivers the event payload to an encrypted Pub/Sub topic (chat-events-topic).
2. Asynchronous Pull Ingestion: The assistant daemon running on the private VM pulls message events from chat-events-sub over an outbound TLS connection. The VM exposes no inbound open ports.
3. Outbound Response Dispatch: The assistant formats structured messages or interactive cards and posts responses back to Google Chat using the Google Chat REST API.

2. Identity & Privilege Boundaries

• Dedicated Service Account: The Chat connector uses the dedicated identity org-assistant@<project_id>.iam.gserviceaccount.com.
• Minimal OAuth Scopes: The bot identity requests strictly the following scope:
  • https://www.googleapis.com/auth/chat.bot (Permits posting messages as the bot in spaces where invited).
• Scope Quarantine: The service account holds no access to user mailboxes (gmail.*), Google Drive documents (drive.*), or Workspace administrative settings. It cannot impersonate domain users.

3. Threat Model & Mitigations

Google Meet & Virtual Audio Pipeline

The Google Meet integration enables the assistant to participate in scheduled virtual conferences, transcribe multi-party discussions, and provide real-time meeting synthesis.

1. Headless Virtual Display & Audio Topology

graph TD
    subgraph ContainerEnvironment [Podman Quadlet Container: Unprivileged User]
        Xvfb[Xvfb :99 Headless Virtual Display]
        PipeWire[PipeWire Audio Daemon]
        WirePlumber[WirePlumber Session Manager]

        Sink[Virtual Audio Sink: virtual-sink]
        Source[Virtual Audio Source: virtual-mic]

        Chromium[Headless Browser: Meet Client]
        Core[Assistant Audio Engine]

        Chromium -->|Speaker Output| Sink
        Source -->|Microphone Input| Chromium

        Sink -->|PCM Frame Capture| Core
        Core -->|TTS Audio Injection| Source
    end

    subgraph ExternalCloud [Google Cloud Services]
        STT[Google Speech-to-Text API]
        TTS[Google Text-to-Speech API]
    end

    Core -->|Encrypted Streaming gRPC| STT
    TTS -->|Synthesized Audio Stream| Core

1. Virtual Display & Audio Loopback: The container operates a headless X11 server (Xvfb) and a local PipeWire audio daemon. Virtual audio nodes (virtual-sink and virtual-mic) decouple the browser from physical hardware.
2. Headless Browser Execution: A sandboxed Chromium browser connects to the designated Google Meet meeting URL.
3. Real-Time Speech Processing: PipeWire captures incoming audio frames from the virtual sink and streams them over encrypted gRPC channels to the Google Speech-to-Text API for transcription.

2. Privacy & Anti-Eavesdropping Invariants

• Explicit Invitation Trigger: The assistant never joins meetings autonomously without an explicit calendar invitation or direct invitation link dispatched by an authorized meeting participant.
• Dormant Default State: When no scheduled conference is active, audio daemons and browser processes are completely stopped. The system does not maintain passive listening streams.
• Zero Audio Storage: Raw audio frames are processed in-flight in volatile memory and discarded immediately following transcription. No raw audio files (.wav, .mp3) are written to disk.
• Participant Transparency: The assistant enters the conference with a clearly identifiable display name and visual avatar, notifying participants of automated note-taking.

3. Threat Model & Mitigations

Privacy Policy

Effective Date: October 1, 2026 • Scope: TAČR Tenant

This Privacy Policy governs the processing of data by the Alfons organizational assistant operated for TAČR. All data processed remains the sole property of TAČR.

1. Overview & Data Ownership

The organizational assistant operates within dedicated, tenant-isolated infrastructure. Data collected, processed, or generated during assistant interactions belongs exclusively to TAČR. The provider does not claim ownership, licensing rights, or commercial utilization rights over customer data.

2. Google User Data Policy Compliance

The application strictly complies with the Google API Services User Data Policy, including the Limited Use requirements:

• Limited Purpose: Data obtained through Google Workspace APIs (Google Chat, Google Meet, Gmail, Google Calendar) is strictly utilized to provide user-facing assistant features requested by TAČR.
• Zero Model Training: Workspace data is never used to train generalized or third-party artificial intelligence or machine learning models.
• Zero Advertising Transfer: User data is never transferred, leased, or sold to advertising networks, data brokers, or information resellers.
• Human Inaccessibility: Human review of customer data is prohibited except where explicitly authorized by TAČR administrators to resolve critical technical incidents.

3. Data Retention & Perimeter Isolation

• Isolated Runtime: The service executes within private compute instances. Inbound connections from public networks are disabled.
• Transient Memory: Short-term conversational context is kept in volatile memory or isolated client databases. It is never shared across client tenants.
• On-Demand Erasure: Administrators can trigger the complete erasure of local indexes and cache stores at any point.

4. Contact & Inquiries

For privacy inquiries or deletion requests, contact the organization administrator at jan.cespivo@tacr-external.cz.

Terms of Service

Effective Date: October 1, 2026 • Scope: TAČR Tenant

1. Acceptable Use

The Alfons service is provided exclusively for authorized members, employees, and contractors of TAČR. All use must comply with corporate acceptable use policies, operational procedures, and enterprise security directives.

2. Authorized Collaboration Interfaces

Access to the assistant is provisioned through authorized enterprise collaboration platforms, including Google Chat and Google Meet. Users must not attempt to circumvent policy engine controls, authentication boundaries, or API rate limits.

3. Algorithmic Processing & Output Verification

Assistant summaries, action items, meeting minutes, and draft responses are generated algorithmically. Users remain responsible for reviewing proposed draft emails, scheduling actions, and meeting minutes before final dissemination or execution.

4. Modifications & Operational Support

Administrative questions and support requests should be directed to the organizational support contact at jan.cespivo@tacr-external.cz.