Security & Architecture Overview

Gondola operates as a control plane between three parties: your Snowflake account, the chat platforms your users work in, and the Cortex Agents that answer them. When a user @mentions a bot, Gondola routes the message to the agent on your Snowflake connection and streams the reply back into the thread. Gondola holds the credentials needed to connect these systems — never the message content itself.

Trust boundaries sit at each hop:

• Your Snowflake account to the Gondola control plane. Gondola authenticates with a personal access token (PAT) or key pair you provision, using the least-privilege Snowflake role you choose.
• Gondola control plane to chat platforms. Gondola holds bot tokens for Slack, Microsoft Teams, Google Chat, and Discord, and verifies them against the platform before saving.
• Chat platforms to your users. Users interact only with the chat app; they never touch the Gondola interface or your Snowflake account directly.

Gondola’s role is a bridge: for each bot it creates a connection between your chat platform and your Cortex agent, carries messages across it, and streams replies back. The connection takes one of two forms — an outbound socket (Slack Socket Mode, Discord) or a public HTTPS endpoint the platform pushes events to (Teams, Google Chat, and Slack webhook bots). Network implications differ by platform and are covered in the Network section below.

Secrets are encrypted at rest with AES-256-GCM — the Advanced Encryption Standard with a 256-bit key in Galois/Counter Mode, an authenticated cipher that detects tampering. Snowflake PATs and chat platform bot tokens are stored this way, each encrypted with a unique initialization vector.

The UI is write-only by design. Once a token is saved, Gondola never renders it again and never returns it through the API. There is no way to view a stored secret, and secrets are scrubbed from logs and error messages.

Credentials are verified before they are persisted. During platform setup, Gondola tests the credential against the platform and stores it only if the check passes — a bad or expired credential is rejected up front instead of surfacing later.

Everything in Gondola is scoped to a workspace. Connections, agents, and bots belong to exactly one workspace, and members see only what their workspace grants them. Four roles define what a member can do, on a least-privilege basis:

• Owner — full control, including billing and membership.
• Admin — manages workspace resources and members.
• Builder — creates, edits, and deletes agents, and manages bots.
• Member — views agents, and creates and manages bots bound to existing agents.

Because access is workspace-scoped, an agency can run many customer workspaces from one account without cross-tenant visibility: a member of one workspace cannot see or act on another.

Each chat platform requires a different transport, and the network implications differ accordingly:

• Slack. Socket Mode (default) is outbound-only: Gondola opens the connection to Slack, so no public URL or inbound firewall rule is needed. Webhook bots are the exception — Slack pushes events to Gondola over HTTPS, so the host must be publicly reachable.
• Microsoft Teams. Webhook-only — there is no socket mode. The Bot Framework pushes activities to Gondola over HTTPS, so the host must be publicly reachable.
• Google Chat. Webhook-only — there is no socket mode. Google pushes events to Gondola over HTTPS, so the host must be publicly reachable.
• Discord. The bot connects outbound to Discord’s gateway socket, so no public URL is needed to receive messages. But Discord’s interactions endpoint is always required — Discord pings it to verify the bot, and slash commands and buttons arrive over HTTP — so that endpoint must be publicly reachable over HTTPS.

Runtime control is explicit. Each bot can be activated or deactivated individually, so a misbehaving or unused bot can be stopped without affecting the rest of the workspace. Every bot exposes its current status and, when something fails, the last error — visible in the UI without digging through logs.

Secrets are the customer data Gondola encrypts at rest: AES-256-GCM for Snowflake PATs and chat platform bot tokens.

Gondola does not store your messages. Gondola’s role is to create a socket — or, for webhook platforms, a receiving endpoint — that links your chat platform to your Cortex agent. Messages and replies stream back and forth across that connection and pass through Gondola in memory only; they are never written to storage.

The only conversation data Gondola retains is the mapping it needs to thread replies. For each conversation, Gondola stores the thread or conversation ID from your chat platform and the Snowflake thread (session) ID it corresponds to, along with the last message reference. That mapping is what lets Gondola route follow-up replies back into the same Cortex agent session, so context carries across turns — the messages themselves are not part of it.

All AI processing happens inside your Snowflake account. When a message arrives, Gondola passes it to your Cortex agent over your Snowflake connection, and the agent runs entirely in your account with the models and tools you configured on it. Gondola never runs the models and holds no copy of your data beyond the routing mapping above.

Gondola also keeps non-content metadata needed to operate and audit: human-readable channel names, deep links back to threads, per-message usage records (bot, channel, timestamp) for quotas and metering, and an audit trail of administrative actions.

All external connections — to Snowflake and to chat platforms — are expected to run over TLS (Transport Layer Security), the standard encryption-in-transit protocol.

Security is a joint effort, and the division is explicit:

Gondola is responsible for:

• Encrypting and protecting credentials at rest and in transit.
• Enforcing workspace isolation and role-based access.
• Keeping the control plane and bot runtime secure and up to date.
• Recording an append-only audit trail of administrative actions.

You are responsible for:

• The Snowflake credentials and roles you provision — provision the least privilege your agents need.
• Chat app configuration and scopes, such as the Slack app manifest or Google Chat scopes.
• Agent configuration: model, instructions, tools, and budgets.
• Workspace membership and role assignments for your team.

The product is built for operators, so day-to-day security controls are direct:

• Stop a bot fast. Deactivate any bot individually; the change takes effect immediately.
• See runtime state. Each bot shows whether it is running and the last error, without opening logs.
• Workspace isolation. Multi-workspace agencies get hard separation between customers out of the box.
• Audit trail. Administrative actions are recorded with actor, timestamp, and non-secret context.