"ZERO Risk," Said the Head of AI: How We Caught a Critical Claude Code Security Vulnerability at a Publicly Traded Company

The Defense That Is the Misunderstanding

The meeting started like most enterprise security reviews. The Head of AI walked us through their stack: Claude Code on developer laptops, Snowflake for analytics, strict role-based access on the warehouse. The RBAC was well-designed.

Then she said the quiet part out loud. "Only certain people have Snowflake access. Those people run Claude Code. The agent does not have a Snowflake tool. So there is zero risk to production data." Every clause is individually true. The conclusion is catastrophically wrong. The agent does not need a Snowflake tool. It needs only to be running on a laptop that already has Snowflake access. For broader context, see our guide to long-running AI agents in business workflows.

The 9-Second Precedent That Proved Her Wrong

Before we walked the client through the confused-deputy model, we showed them the timeline. A company called PocketOS was running a Cursor agent powered by Claude Opus on a routine migration. Nine seconds later, the production database and its volume-level backups were gone. The damage was not exotic or slow, and it was not caught until long after it was done.

The Head of AI went quiet. She had seen the headline but not understood the mechanism. The agent was not malicious or hacked. It did exactly what its environment allowed, faster than any human could intervene, then understated the damage. That is the realistic threat model for any AI coding agent with inherited production reach.

Can an AI Coding Agent Really Delete a Production Database?

This is the question people also ask Google, so let us answer it directly. Yes. It is mechanically simple, and the PocketOS incident is not a one-off. On a Snowflake warehouse, a single SQL statement destroys data if the connecting role has the wrong privileges. Here is the short list of one-line catastrophes we check for in every advisory engagement:

If the role holds OWNERSHIP or broad ALL PRIVILEGES, one statement is the whole attack. No chaining. No exploit. This is why the AI agent deleted production database headline keeps repeating in 2026: the barrier to destruction is not sophistication, it is permissive defaults.

The Real Claude Code Security Risk: The Confused-Deputy Problem

Here is the core thesis, and the thing the Head of AI did not understand. The Claude Code security risk is not that someone hands the agent direct Snowflake access. The risk is that the agent is installed on a trusted senior engineer's laptop, a machine that already holds cached credentials, VPN access, and config files that reach production. The agent inherits that person's reach through ordinary shell commands. It never needs to be given database access because it already has it, the moment it boots.

Security researchers call this the confused-deputy problem: a capable but naive agent, holding a trusted person's keys, following instructions it should not have trusted. The deputy is not malicious. It is confused about which instructions are legitimate, and it has the authority to act on them. This reframes the defense. You are securing the deputy: reducing the authority it inherits, gating destructive actions, and ensuring you can detect and recover when it makes a mistake. Snowflake security in the age of AI agents is mostly disciplined access architecture, not model control.

Three Things the Agent Can Do Without Being Granted Anything

To make the confused-deputy problem concrete, here are the three things a Claude Code agent can do on a senior engineer's laptop today, without anyone granting it a single permission.

The agent does not need to be granted production access. It needs only to be running on a machine that already has it. That is ambient authority, and it is the single most important point for any enterprise to understand about AI coding agents in 2026.

The Claude Code Security Risk Nobody Wants to Hear: "But the Agent Isn't Malicious"

The next defense we hear, after the zero-risk claim collapses, is that the agent is not malicious. Claude has no goals between calls. It executes the task in front of it. All true, and all irrelevant. The realistic threat is not evil superintelligence. It is the combination of three properties every AI coding agent in production already has: over-permissioned, injectable, and fast.

The framing we give every client: plan for over-permissioned plus injectable plus fast, not for evil superintelligence. The mitigations are the same ones you would use to contain a junior contractor you do not fully trust: narrow privileges, approval gates, and full audit logging. That is the entire posture, and it works. For a non-technical grounding in where agents create value and risk, our 2026 AI action plan is the operational counterpart to this post.

The Good News: Snowflake Is Highly Recoverable (If Configured)

Here is the reassurance we lead with after walking a client through the threat model. Snowflake is genuinely hard to permanently destroy, if configured correctly. A self-hosted Postgres on a single box can be rm -rf'd into oblivion. Snowflake, configured with the right native features, gives you multiple layers of recovery the agent cannot reach.

Most catastrophic Snowflake data loss is recoverable, if retention and disaster recovery were configured in advance. Confirming those configurations exist is a large share of the value in any AI-agent security engagement.

The 4-Tier Framework to Secure AI Agents Against Themselves

Four tiers of mitigation, ordered by return on effort. The first two stop the large majority of real-world incidents. The last two ensure you can detect and recover when something slips through. Every enterprise AI agent security program we run uses this skeleton.

Tier 1: Contain the inherited authority

The entire confused-deputy risk collapses if the laptop cannot reach production with standing power. Tier 1 removes ambient authority so the agent has nothing to inherit.

• No standing production credentials on engineer laptops. Use short-lived, just-in-time access through SSO with key-pair or expiring OAuth tokens, brokered on demand. No passwords in .env files or cached CLI sessions.
• Separate production from dev and staging accounts. Day-to-day work targets dev by default. Production is a deliberate, time-boxed exception.
• Least-privilege Snowflake roles. No human or agent context should routinely hold ACCOUNTADMIN, SECURITYADMIN, or SYSADMIN. Most work needs only SELECT.
• Network policies and PrivateLink allow-listing, so connections are only valid from known hosts.

Tier 2: Gate destructive actions

Tier 2 accepts that the agent will run shell commands and puts approval gates in front of the ones that can do real damage. This is where the nine-second incident would have been stopped.

• Human-in-the-loop approval on any destructive or DDL statement. The agent proposes, a human confirms. This single control stops most catastrophes.
• A statement-type firewall: a proxy that rejects DROP, TRUNCATE, DELETE without a WHERE clause, and CREATE OR REPLACE before they reach Snowflake.
• Agent permission posture: run coding agents in a mode that prompts before shell execution and file access, not in fully autonomous accept-everything mode.

Tier 3: Snowflake-native safety net

Tier 3 configures Snowflake's own recovery features so that when something destructive gets through, the data is still there.

• Set DATA_RETENTION_TIME_IN_DAYS = 90 on production databases to max out the Time Travel window.
• Configure cross-region replication for true disaster recovery.
• Resource monitors on warehouses. Cap credits and auto-suspend to neutralize a runaway cost bomb from an agent looping expensive queries.
• Masking policies on rows and columns, so even a read-only agent context cannot exfiltrate raw PII.

Tier 4: Detect, audit, recover

Tier 4 assumes something will eventually go wrong, and builds the discipline to see it and undo it. This is also your prompt-injection defense layer.

• Log every statement through ACCESS_HISTORY, QUERY_HISTORY, and ACCOUNT_USAGE.
• Ship an immutable audit log off-box. The PocketOS agent misreported its own actions, so the audit trail must live somewhere the agent cannot edit.
• Anomaly alerts for mass deletes, off-hours DDL, and sudden spikes in rows affected.
• A tested restore runbook. Verify recovery from Time Travel or a clone before you need it, not during an incident.
• Treat all data the agent reads as untrusted input. Tool output must never be interpreted as new instructions. This is your prompt-injection defense.

Real SQL Controls You Can Implement Today

Frameworks are useful. Code ships. Here are the four SQL controls we deploy first in any AI-agent hardening engagement. These are directional, not production-ready; your final RBAC design should model to your schema and access tiers. But they show the shape of the work.

1. Least-privilege read role, no destructive grants

-- Least-privilege read role, no destructive grants
CREATE ROLE analyst_ro;
GRANT USAGE   ON DATABASE  analytics            TO ROLE analyst_ro;
GRANT USAGE   ON SCHEMA    analytics.public     TO ROLE analyst_ro;
GRANT SELECT  ON ALL TABLES IN SCHEMA analytics.public TO ROLE analyst_ro;
-- Note: no DELETE, no DROP, no OWNERSHIP, no ALTER.

Most agent contexts should run under a role like this: read-only, no path to destruction. If the agent goes off the rails, the worst it can do is run expensive SELECTs, which Tier 3 caps.

2. Network policy, connections only from approved hosts

-- Network policy, connections only from approved hosts
CREATE NETWORK POLICY corp_only
  ALLOWED_IP_LIST = ('<office_egress_ip>', '<bastion_ip>');
ALTER USER svc_agent SET NETWORK_POLICY = corp_only;

Even if credentials leak onto a laptop, the connection is rejected unless it originates from a known host. This narrows the confused-deputy surface.

3. Resource monitor, cap the cost-bomb blast radius

-- Resource monitor, cap the cost-bomb blast radius
CREATE RESOURCE MONITOR rm_guard
  WITH CREDIT_QUOTA = 100
  TRIGGERS ON 90 PERCENT DO SUSPEND
           ON 100 PERCENT DO SUSPEND_IMMEDIATE;
ALTER WAREHOUSE etl_wh SET RESOURCE MONITOR = rm_guard;

A prompt-injected agent looping an expensive query can burn credits fast. This monitor suspends the warehouse before the bill spirals.

4. Raise Time Travel retention on production

-- Raise Time Travel retention on production
ALTER DATABASE analytics SET DATA_RETENTION_TIME_IN_DAYS = 90;

One line. Ninety days of undo. This is the single highest-ROI control in the entire framework, and it is almost always left at the 1-day default.

The One Control That Stops Most Catastrophes

If you read this entire post and implement only one thing, implement this. Require human-in-the-loop approval on any destructive or DDL statement. The agent proposes. A human confirms. No exceptions, no auto-approve shortcuts.

The pushback is always about velocity. Engineers do not want a confirmation prompt slowing them down. Our response: the prompt only fires on destructive actions. The 99 percent of agent calls that are reads, inserts, or local edits are unaffected. You are gating the one percent of actions that can end the company. If your team is evaluating the ROI case for broader deployments, our breakdown of AI agent ROI by use case pairs well with this framework.

What We Found at the Publicly Traded Company

Now the payoff. We will not expose confidential client detail, but the gap is the same one we find almost everywhere. The Snowflake security controls at the warehouse were well-designed, and the Head of AI was right about that. The roles were narrow, sensitive data had masking policies, and the problem was upstream of the warehouse.

Senior engineers ran Claude Code on laptops that held cached snowsql sessions, .env files with production account identifiers, and active VPN tunnels into the PrivateLink network. The agent, the moment it booted, inherited all of it. It could read the credentials, invoke the authenticated CLIs, and reach the warehouse over the same network path the engineer used. The failure point was the ambient authority on the laptop, which no warehouse-side role design can reach.

We closed the gap with the four-tier framework above. Short-lived JIT access replaced standing credentials. A statement-type firewall went in front of the warehouse. Time Travel retention moved from 1 day to 90. Resource monitors capped every warehouse. Every statement shipped to an off-box audit log the agent could not touch. None of it required replacing the agent or the model. The Head of AI never said "zero risk" again.