Hex Notebook Agent Security Risks

Data Engineering Agents hex.tech Humble Providers
AI RISK QUADRANT POSITION DEFENSE CONTROLS (5) ATTACK SURFACE (4.8) EXPOSED GIANTS FORTIFIED LEADERS HUMBLE PROVIDERS TIGHT OPERATORS
AIRQ Score
3.66
Critical
Attack Surface
4.8
Medium
Blast Radius
4.25
Medium
Defense Controls
5
High
About The Agent

Hex Notebook Agent is a cloud-hosted SaaS data notebook agent that converts natural language prompts into SQL queries, Python code, and interactive visualizations against connected data warehouses. The agent operates on vendor-managed cloud infrastructure, accepting input from the web notebook interface, a Slack integration, and an OAuth-authenticated MCP server endpoint. Every input channel feeds the same warehouse query authority, and the agent generates executable code that runs in per-session kernels with access to whatever data the authenticated user can reach through their configured connections.

About the AI Risk Quadrant

Humble Providers placement reflects a moderate attack surface lifted above its raw weighted average by a complete trifecta condition, a contained blast radius bounded by cloud-hosted kernel isolation and default-off writeback, and a partial defense posture where role-based access controls exist but input guardrails and output data-loss controls are absent. Operators inherit meaningful trifecta exposure from the combination of multi-channel prompt ingestion, warehouse data access, and external output delivery, but benefit from vendor-managed infrastructure that limits the ceiling of any single compromise path.

1 Key Risks

The most critical security risks an operator inherits when deploying this agent in its documented default configuration. Hex Notebook Agent presents moderate surface exposure amplified by a complete trifecta condition, with absent input guardrails and Enterprise-gated monitoring as the dominant operator blind spots on the default configuration.

Key Input Risks
The Notebook Agent ingests natural language prompts from a web UI, Slack mentions, and an MCP server endpoint without a documented prompt shield or injection detector. Workspace context and warehouse schema metadata from multiple users are loaded into every conversation, and a vendor-documented sqlsafe flag can bypass SQL parameterization entirely. [7][15]
Key Execution Risks
The agent generates and executes SQL queries against connected warehouses and runs Python code in per-session cloud kernels without published container-level sandbox specifications or network egress restrictions. Operators should verify kernel network isolation independently or accept the residual risk of undocumented outbound access from Python execution environments. [5][7]
Key Action Risks
Scheduled runs and API-triggered project executions fire without per-execution operator approval once configured by an admin or editor. Writeback cells, when enabled, allow the agent to write dataframes back to production databases, and Slack and MCP responses deliver query results to external channels autonomously. [12][13]
Key Output Risks
The agent emits rich output including charts, data tables, and markdown with secrets redacted as bracket-masked values, but no documented data-loss prevention or exfiltration blocking covers the output path. Published data apps, Slack responses, and MCP responses are channels where untrusted agent output can reach downstream consumers. [8][14]
Key Monitoring Risks
Structured audit logging with SIEM streaming is available only on the Enterprise plan, leaving non-Enterprise deployments without forwarded audit trails for incident investigation. No documented behavioral anomaly detection or real-time alerting exists for detecting injection attempts or unusual query patterns against connected warehouses. [10][11]

2 AIRQ Scores

The four headline scores quantify how exposed the agent is, how damaging a successful attack would be, and how much the agent’s own controls reduce that risk. Hex Notebook Agent scores in the moderate-risk band, where the trifecta floor on attack surface outweighs the contained blast radius and partial vendor-provided defenses.

AIRQ Metrics

The agent lands in the Humble Providers quadrant as a borderline placement, with attack surface within the threshold margin of the Humble Providers boundary, blast radius contained by cloud-hosted execution, and defense controls partially present through role-based access and kernel isolation.

Each metric is scaled to its denominator: Attack Surface and Blast Radius to ten, Defense Controls to fifteen, and the AIRQ composite to fifteen.

Metric Score Comments
AIRQ Score 3.66 Borderline placement driven by trifecta floor requires operators to prioritize input guardrails and output exfiltration controls to reduce the attack surface below the threshold margin.
Blast Radius 4.25 / 10 Cloud-hosted kernel model with default-off writeback and no direct infrastructure deployment capability keeps the blast radius below the midpoint across all six factors.
Attack Surface 4.8 / 10 Raw weighted average sits below the trifecta floor; all three trifecta dimensions are triggered on the documented default, lifting the composite to the floor value.
Defense Controls 5 / 15 Role-based access and kernel isolation are vendor-documented, but input guardrails are absent, output data-loss controls are undocumented, and structured audit logging is Enterprise-gated.

3 Attack Surface

Attack surfaces are the entry points and interaction patterns through which adversarial input can reach the agent’s reasoning loop and steer its behavior. The dominant exposures are multi-channel prompt ingestion from the web UI, Slack, and MCP without input filtering, combined with direct SQL and Python execution authority against connected data warehouses.

Attack Surface Metrics

Higher scores indicate wider adversarial reach into the agent's reasoning loop; User Input and Tool Execution carry the most weight for this cloud-hosted data agent.

Each row maps a surface to its base score and a one-line comment describing the documented default behavior that grounds the assessment.

Surface Score Comments
User Input 2 / 4 No prompt shield or injection detector covers the three input channels (web UI, Slack, MCP); workspace context rules provide behavioral guidance but not security input filtering. [7][15]
External Data 2 / 4 Ingests warehouse schema metadata, table contents via SQL queries, and cross-project references from admin-curated sources; all data connections are user-authorized through the permissions model. [7][9]
Memory 1 / 4 Session-scoped kernel memory cleared on restart; no persistent cross-session agent conversation memory exists, though workspace context rules persist as admin-managed configuration. [7][11]
Reasoning 2 / 4 Multi-step reasoning with visible chain-of-thought through subagent decomposition; reasoning constrained to the declared analytical task scope within the notebook session. [7]
Planning 2 / 4 Builds visible analytical plans decomposed into focused workstreams with user review of generated cells before execution; plans do not execute autonomously without acceptance. [7]
Tool Execution 2 / 4 Generates and executes SQL against warehouses and Python in per-session cloud kernels; writeback disabled by default, with programmatic database write capability when enabled. [2][7][13]
Orchestration 2 / 4 Multi-step task execution within user-supervised sessions with subagent decomposition for parallel workstreams; scheduled runs operate at the project level after initial admin configuration. [7][12]
Inter-Agent 1 / 4 Internal subagent decomposition only within the vendor platform; the MCP server provides an inbound OAuth-authenticated endpoint but does not delegate to external agent systems. [7][14]
Output Processing 2 / 4 Produces charts, visualization widgets, data tables, and formatted markdown with project secrets masked in rendered cells; no documented exfiltration controls or data-loss prevention on the output delivery path. [7][8]
Configuration 1 / 4 Configuration through the vendor web UI with admin-managed workspace settings and data connection permissions; no auto-loaded config files from project directories or untrusted plugin marketplace. [9][11]

The Lethal Trifecta is triggered when an agent processes untrusted content, accesses private data, and communicates externally in the same session — the three conditions that turn an isolated prompt injection into full-chain exfiltration. Hex Notebook Agent exhibits all three on the documented default: a prompt injected through Slack, MCP, or workspace context can read warehouse data through SQL queries and transmit results through Slack responses, MCP output, published data apps, Python HTTP calls, or writeback channels without crossing a system-level exfiltration control.

Lethal Trifecta · Complete (3 of 3)

Hex Notebook Agent exhibits all three of these conditions in its documented default configuration:

  • Untrusted input — Natural language requests from the notebook interface, Slack channel mentions, and MCP connections reach the reasoning loop alongside admin-authored workspace context and warehouse schema metadata. [7][15]
  • Sensitive data — SQL queries execute against connected warehouses containing customer data, and Python cells can access project secrets stored in the encrypted vault. [7][8]
  • External egress — Agent output flows to Slack channels, MCP clients, published data apps, and Python kernels can make outbound HTTP requests with no documented network restriction. [14][15]

4 Blast Radius

The blast radius is what an attacker who controls the agent can reach — which systems they touch, which credentials they read, and which actions they take without operator approval. A compromised session reaches warehouse data through SQL, runs arbitrary Python in the kernel, and can write back to databases when writeback is enabled, but cannot access operator infrastructure or local file systems directly.

Blast Radius Metrics

Higher blast scores indicate wider reach from a single compromised session; SQL and Python execution against warehouses carry the dominant factors for this cloud-hosted agent.

Each row ties a blast factor to the documented scope of operator assets the agent can reach through that capability on the default configuration.

Factor Score Comments
Code execution 2 / 4 SQL queries execute against warehouses and Python runs in per-session cloud kernels with operator-level data access; kernel isolation is vendor-managed without published container-level specifications. [7][5]
File system access 1 / 4 Cloud-hosted kernel model bounds file access to the session scope; the agent reads warehouse data and project artifacts but the operator's local file system and cloud storage are not directly reachable. [7]
Network access 2 / 4 Outbound database connections to configured warehouses plus undocumented Python kernel network access; no published network egress restrictions for the kernel environment. [5][6]
Credential access 2 / 4 Data connection credentials stored in encrypted vault with secrets redacted in output; the agent accesses whatever the authenticated user can query through shared or per-user OAuth credentials. [9][8]
Autonomous action 2 / 4 Scheduled runs and API-triggered executions fire without per-execution approval; writeback cells write to databases when enabled; Slack and MCP responses deliver results autonomously. [12][13]
Deployment access 1 / 4 No direct infrastructure deployment capability; the agent can publish data apps and write back to databases when explicitly enabled but cannot modify cloud infrastructure or production deployments. [7]

5 Defense Controls

Defense controls are what the agent’s own architecture does to detect, contain, and report attacks before they reach the operator’s systems. The vendor documents role-based access controls and per-session kernel isolation, but input guardrails, output data-loss controls, and behavioral anomaly detection are absent from the default configuration.

Defense Controls Metrics

Higher defense scores indicate stronger vendor-provided safeguards on the default configuration; for this agent, action controls carry the most weight while input guardrails are absent.

Each component is scored on what the vendor implements by default, with confidence reflecting whether the control is independently verified, vendor-documented, or architecturally inferred.

Component Score Comments
Input Guardrails 0 / 3 No documented prompt shield, injection detection, or instruction hierarchy separation for agent-generated queries; the vendor-documented sqlsafe flag can bypass parameterization entirely, and workspace rules are behavioral guidance rather than security filters. [5][4]
Execution Isolation 1 / 3 Per-session kernel isolation on vendor-managed cloud infrastructure with idle timeouts and restart controls; no published container-level or network-level sandbox specifications for kernels. [5][7]
Action Controls 2 / 3 Five-tier workspace role model with granular data connection permissions, writeback disabled by default, and admin-configurable restrictions on agent access from external integrations; no documented single-step bypass. [9][6]
Output Guardrails 1 / 3 Secrets redacted as bracket-masked values in output; no documented data-loss prevention, exfiltration blocking, or URL sanitization for agent-generated rich output including charts and data tables. [8][7]
Monitoring 1 / 3 Admin-only conversation observability through the context management dashboard with topic tracking; structured audit logging with SIEM streaming is Enterprise-only and absent from default lower-tier configurations. [10][11]

6 Hardening Tips

Concrete actions an operator can take to reduce the risks reported above, grouped by which defense control each tip strengthens. Operators should prioritize closing the trifecta by adding input guardrails and output exfiltration controls, then extending audit logging and network egress restrictions to contain the remaining exposure.

Input Guardrails

Input guardrails intercept adversarial content before it reaches the reasoning loop.

Input Guardrails
  • Policy Require all Notebook Agent interactions to flow through workspace accounts with enforced SSO and MFA, restricting the set of users who can inject prompts into the reasoning loop.
  • Configuration Configure Context Studio workspace rules to constrain agent behavior for sensitive data domains, and restrict which data connections the agent can access from Slack and MCP integrations.
  • Engineering Deploy a prompt-injection detection layer as a preprocessing step before agent prompts reach the LLM, using a classifier trained on text-to-SQL injection patterns. [1][3]

Execution Isolation

Execution isolation contains what a compromised agent can do on the host.

Execution Isolation
  • Policy Require that all data connections use OAuth per-user credentials rather than shared service accounts, ensuring kernel execution inherits the least-privilege scope of the authenticated user.
  • Configuration Configure kernel idle timeouts to the shortest acceptable interval and enforce kernel restart between sensitive sessions, reducing the window for accumulated state to be exfiltrated through the session context.
  • Engineering Instrument kernel network egress monitoring through a cloud-side network proxy or VPC flow logs to detect and block unauthorized outbound connections from Python kernels.

Action Controls

Action controls govern which tools and actions the agent can invoke autonomously.

Action Controls
  • Policy Require that the per-context write mode toggle for writeback cells remain disabled in production workspaces unless approved through a change-management process with named reviewers. [13]
  • Configuration Configure data connection permissions to the minimum required scope per workspace role, and restrict Slack and MCP agent access to read-only data connections.
  • Engineering Build an approval workflow that gates scheduled run configurations behind a secondary admin review, ensuring autonomous executions are audited before activation. [12]

Output Guardrails

Output guardrails inspect what the agent sends to other systems and users.

Output Guardrails
  • Policy Require that published data apps undergo security review before publication, verifying that exposed query results do not contain sensitive data beyond the intended audience.
  • Configuration Configure workspace-level restrictions on which data connections can be used in published apps and Slack responses, limiting the scope of data reaching external output channels.
  • Engineering Deploy a data-loss prevention proxy on the network path between the platform and downstream output channels to detect sensitive data patterns, directly countering the absent output exfiltration controls.

Monitoring

Monitoring captures what the agent did and surfaces anomalies for review.

Monitoring
  • Policy Require Enterprise-tier deployment or equivalent audit-log access for any workspace processing sensitive data, ensuring structured audit trails are available for incident investigation. [10]
  • Configuration Configure SIEM streaming to forward audit logs to the central security monitoring platform with alerting rules for anomalous query patterns and permission changes.
  • Engineering Build automated alerting on conversation metadata to detect unusual topic patterns, high-frequency agent interactions, or queries against sensitive data connections. [11]

7 References

The evidence base behind every score and finding in the profile, grouped by source type so the reader can verify any claim. Numbers in brackets throughout the report (e.g. [7, 13]) refer to entries below, listed in citation order.

Selected Vulnerabilities

  1. SecureSQL NL2SQL Data Leakage Evaluation Demonstrates prompt injection and inference attacks against NL2SQL interfaces with high success rates across multiple LLM backends.
  2. TrojanSQL Backdoor SQL Injection Shows backdoor-based SQL injection against text-to-SQL parsers achieving up to 99 percent attack success rates.

Selected Research

  1. P2SQL Prompt-to-SQL Injection in LLM Web Apps Evaluates prompt-to-SQL injection attacks against LangChain-based web applications and proposes the LangShield defense portfolio.
  2. OWASP Top 10 for LLM Applications 2025 Industry framework covering prompt injection, excessive agency, and improper output handling risks for LLM-integrated agents.

Vendor Documentation

  1. Hex Security Page Documents vendor SOC 2 Type II attestation, encryption standards, access controls, bug bounty, and penetration testing.
  2. Hex Security Addendum Details the Information Security Program with SOC 2 Type II, HIPAA, and PCI DSS certifications but does not document input filtering, kernel sandbox specifications, or output DLP controls.
  3. Hex Notebook Agent Documentation Describes Notebook Agent capabilities including cell generation, subagent decomposition, and cross-project references.
  4. Hex AI Data Privacy Covers LLM provider zero-retention policy, bring-your-own-key option, and workspace-level AI opt-out.
  5. Hex Sharing and Permissions Documents five-tier workspace role model and granular data connection permissions.
  6. Hex Audit Logs Describes Enterprise-only audit logging with SIEM streaming to Datadog, Splunk, S3, and GCS.
  7. Hex Context Studio Describes the observability dashboard for agent conversations including topic tracking and context management.

Other Sources

  1. Hex Scheduled Runs Documents automated project execution on configurable schedules with notification triggers.
  2. Hex Writeback Cells Documents native writeback cells for writing dataframes back to databases with write mode disabled by default.
  3. Hex MCP Server Documents OAuth-based MCP integration enabling external AI tools to query warehouse data through Hex.
  4. Hex Agent in Slack Documents the Slack integration that lets workspace members invoke Hex Agent via at-mentions.