Your Agent Runs With Your Credentials. That's the Whole Problem.

The Threat Model Nobody Updated

The barrier to building with data has collapsed. A marketing analyst with no SQL background can now scaffold a full-stack analytics app in a few hours, querying HubSpot campaign data against their data warehouse without filing an engineering ticket. A finance practitioner can pull Stripe revenue events, join them against their ledger, and ship a live P&L dashboard before lunch, all in natural language. Vibe coding and AI-native BI tools have democratized what used to take a team of engineers weeks to deliver.

That democratization is real and valuable. It has also quietly dismantled the security assumptions that were baked into the old model.

The pauses that used to exist were doing invisible security work: the engineering review, the infra ticket, the DBA approving a new connection.

When a data practitioner manually connects to a database, they authenticate deliberately. They know what they are touching. When an AI agent does it, that context collapses and someone hands the agent the keys. Usually via a .env file, a hardcoded connection string, or an environment variable that "isn't sensitive." The agent runs with the same privilege level as the practitioner. There is no least-privilege boundary. There is no review gate. There is no audit trail.

A compromised agent is a compromised production system. And the AI toolchain itself is now an attack surface.

This article is not primarily about software developers. Developers follow established environment hygiene: local, staging, and production are separate. A coding agent running locally operates against local or staging data. If a dev machine is compromised, it is painful, but production data is not directly in the blast radius.

Data analytics and dashboard building are a different story entirely. And that is what this is about.

3 Incidents. 30 Days. Every Layer Hit.

In March and April 2026, attackers went after the AI development stack directly: the packages, the gateways, and the platforms. Each incident exposed a different entry point. Together, they map the complete attack surface.

Axios: The Dependency You Trusted

On March 31, 2026, two versions of axios, the npm HTTP client with over 300 million weekly downloads, were found to contain a Remote Access Trojan (RAT). The attacker did not find a code vulnerability. They social-engineered a primary maintainer, hijacked their npm account, and published two backdoored versions in a 39-minute window. Microsoft and Google both attributed the campaign to Sapphire Sleet, a North Korean state actor. (Microsoft Security Blog, Google Cloud Blog)

The delivery mechanism is what makes this dangerous at scale. Most projects do not pin dependencies. A package.json with "axios": "^1.14.0" silently resolves to the latest matching version on the next install. You installed nothing new. You changed nothing. You were just compromised.

Andrej Karpathy posted about his near-miss: axios had been pulled transitively through a googleworkspace/cli he had been testing. His version resolved to 1.13.5, unaffected by luck. "If I had done this earlier that day the code would have resolved to latest and I'd be compromised." His conclusion: unpinned dependencies mean a single hijacked maintainer account propagates a RAT to millions of systems at random. No zero-day required.

Vibe coding tools scaffold projects and run npm install autonomously, pulling whatever latest resolves to, with no mechanism to audit the supply chain they are trusting on your behalf.

LiteLLM: They Went After the AI Gateway Itself

On March 24, 2026, TeamPCP, a threat actor running a coordinated multi-week supply chain campaign, compromised LiteLLM, the Python library AI teams use to route calls across LLM providers. 3.4 million downloads per day. The package that holds your OpenAI keys, your Anthropic keys, your Bedrock credentials. (LiteLLM Security Update, Datadog Security Labs)

The entry point was a Trivy security scanner running in LiteLLM's own CI/CD pipeline. TeamPCP had previously poisoned Trivy, and when LiteLLM's pipeline ran it, the PyPI publishing token was exfiltrated. The attackers published versions 1.82.7 and 1.82.8, live for roughly 40 minutes before PyPI quarantined them.

The payload was a .pth file, a Python mechanism that auto-executes on every interpreter startup with no import required. It ran a multi-stage credential stealer: SSH keys, Git credentials, AWS/GCP/Azure configs, cloud provider tokens. Everything an AI-enabled analytics and dashboard environment accumulates.

Trend Micro's headline was accurate: "Your AI Gateway Was a Backdoor." The irony is precise. The tool designed to abstract and manage your LLM credentials was the vector used to steal them.

The root cause is not that LiteLLM was poorly secured. It is that the credentials were locally resident in the first place. The .pth payload only worked because there was something worth stealing on the machine. A supply chain attack on a locally installed package is only dangerous if the local environment holds secrets. Eliminate local credential storage and this entire attack class becomes inert.

Vercel: The OAuth Chain Reaction

In April 2026, Vercel published a security bulletin after attackers accessed environment variables belonging to a subset of customers. The entry point was not Vercel. It was Context.ai, a small third-party AI tool whose Google Workspace OAuth app was compromised.

That was enough. The attacker pivoted into a Vercel employee's account, then accessed environment variables that had not been flagged as "sensitive." Those variables contained what environment variables always contain: Supabase credentials, Datadog API keys, Authkit tokens, database passwords. ShinyHunters later claimed to be selling the data on BreachForums for $2 million. (BleepingComputer, The Hacker News)

Vercel's remediation advice was to rotate any environment variable not marked sensitive. Reasonable triage. But it treats the symptom. The root cause is that credentials were stored somewhere a third-party AI tool could reach them, with no architectural boundary to prevent it.

The Attack Capabilities Are Accelerating Too

The three incidents above involved human-operated threat actors with conventional tooling. That baseline is shifting.

In April 2026, Anthropic released details of Project Glasswing, built on Claude Mythos Preview. Mythos can autonomously reverse-engineer binaries, chain vulnerabilities into working exploit sequences, and generate functional attack code without human steering. Anthropic restricted access to a closed coalition of AWS, Apple, Google, Microsoft, and others specifically because releasing it publicly would hand every threat actor capabilities previously reserved for elite security researchers. Arctic Wolf's assessment: the asymmetry between attacker capability and defender response time is widening.

The implication for credential exposure is direct. A Mythos-class model handed a stolen production credential can autonomously enumerate your schema, identify the highest-value tables, chain the access with other reachable vulnerabilities, and exfiltrate at a speed no human operator could match. The stolen credential is no longer just an entry point. It is the seed input for an autonomous exploitation pipeline.

Data Analytics and Dashboarding Are the Acute Risk

Data practitioners have no staging equivalent. Staging data is incomplete, anonymized, or months out of date. It is useless for anything meaningful. Production is the only option. Always.

Every analyst agent, connecting directly to production, runs with credentials resident on the local machine: database passwords, API keys, connection strings. There is no intermediary. The local machine and production are directly coupled. That coupling is the root of the problem.

This creates two compounding risks, not one.

Risk 1: Credential exposure. The production connection string, API key, or database password sitting in a local .env file or config is a high-value target. Any of the attack patterns above, whether a compromised package, a poisoned CI scanner, or a hijacked OAuth app, can silently exfiltrate it. The practitioner did nothing wrong. The secret was just reachable.

Risk 2: Production system access. A stolen credential is not just a leaked secret. It is an open door. With a valid production database password, an attacker can query any table the practitioner has access to, exfiltrate customer records, financial data, or PII at scale, silently, with no query log, no alert, and no trace. The blast radius is not a compromised local machine. It is your production data in an attacker's hands.

These two risks are sequential and inseparable. The credential exposure is the entry point. The production access is the consequence.

The Read-Only Objection

A common objection here is that analyst agents only get read-only access, so the risk is bounded. Read-only helps. It does not close the problem.

Read-only access to environment variables was sufficient in the Vercel breach to cause a catastrophic incident. A SELECT on a customer table containing SSNs, health records, or payment data is a breach regardless of whether any writes occur. Stolen read-only credentials can be used to exfiltrate data at scale without write access. The credential is the attack surface, not the permission level.

Beyond credential risk, read-only access alone leaves three governance gaps open:

No query-level enforcement. Read-only access to a warehouse does not constrain what the agent queries. It can query columns it should not touch, join tables to reconstruct PII from nominally anonymized data, or pull financial records that a practitioner has technical access to but should not be routing through an AI system.

Heterogeneous sources, fragmented governance. Production data lives in Postgres, Snowflake, Google Sheets, Salesforce, and Excel files on someone's desktop simultaneously. Each source has its own access model. There is no unified policy plane. An agent holding the practitioner's credentials has read access across all of it with none of it governed consistently.

No audit trail. Read-only with no logging means you cannot prove what was accessed. GDPR, SOC2, and HIPAA require you to demonstrate exactly that. An agent running ad-hoc queries against production with no audit trail is a compliance gap you will discover at the worst possible moment.

The blast radius of a compromised analyst agent is not a bad deploy. It is exfiltrated customer data and a regulator notification, even if nothing was ever written.

The instinct is to reach for existing controls.

Why the Obvious Fixes Fall Short

Three mitigations come up in every conversation about this. All reduce risk. None eliminates it.

VPN and VPC: Perimeter Controls Against an Insider Threat

Putting data systems behind a VPN or deploying into a VPC is sound practice. It blocks unauthenticated external actors from directly reaching your production database and is standard infrastructure for most mature teams.

But VPN and VPC are network perimeter controls. They are designed for an outside-in threat model. Supply chain attacks do not come from outside the perimeter. They execute inside it, on a trusted machine, already authenticated, already on the network.

When a supply chain attack runs on a machine inside the corporate network, the malicious payload makes outbound calls to an attacker's C2 server over HTTPS on port 443, indistinguishable from normal traffic. The VPN sees nothing wrong. This is the outbound blind spot.

Once compromised code is running on an inside machine, it can exfiltrate credentials outbound, then query production using those credentials and stream results to the attacker, all from within the trusted perimeter. VPN/VPC secures the network path. It does nothing about credentials sitting in a local .env file on a practitioner's laptop inside that network. The credential lives on the machine, not on the wire.

MCP: A Step in the Right Direction, Not Security by Design

MCP meaningfully reduces direct exposure. By sitting between the agent and the data source, it means the agent authenticates to the MCP server and the server handles the actual production connection. That is a genuine improvement over handing a production connection string directly to an agent.

But MCP was designed for interoperability, not security. It is a standard protocol for agents to talk to tools, and security was not a first-class design goal. That shows up in the gaps: no built-in governance, no query policy enforcement, no audit trail. Being in the middle with a token is not sufficient if the intermediary itself is compromised, which is exactly what the OAuth chain reaction above demonstrated.

There is also a practical force accelerating MCP's limitations. It consumes context tokens heavily. Every tool definition, every schema description, every protocol round-trip eats into the context window. Teams building serious agentic workflows are already moving toward CLI and API interfaces, which are lighter, faster, and more composable. The already-incomplete security model of MCP is becoming moot as the ecosystem shifts underneath it.

Sandboxes: Execution Isolation Without Credential Isolation

Sandboxes prevent an agent from taking arbitrary actions on the host system. That is real value. But they do not prevent the agent from running a destructive or exfiltrating query against a production database it has been given credentials to reach. The sandbox is isolated. The database connection is not.

Some sandbox implementations compound this problem by injecting credentials as environment variables inside the sandbox, which is architecturally equivalent to a local .env file. The secret is still resident in the execution environment and reachable by anything running inside it.

Even implementations that keep credentials outside the boundary and proxy outbound connections through a controlled layer face a structural limitation: recent research found command injection vulnerabilities in the pre-sandbox initialisation phase that allow credential exfiltration before the sandbox activates, bypassing all protections.

The deeper issue is that sandboxes are solving a different problem. Execution isolation and credential isolation are not the same thing. A sandbox constrains what an agent can do to the host system. It says nothing about what the agent can do with the production credentials it has already been handed.

What a Real Solution Looks Like

The security boundary has to be architectural. Not a .env convention. Not a prompt instruction telling the agent to be careful with credentials. Not practitioner discipline. These are soft controls that depend on humans and models consistently doing the right thing, every time, under pressure. That is not a security model. That is optimism.

An architectural boundary means the credential is structurally unreachable, not because someone remembered to protect it, but because the system was designed so it never enters the execution environment in the first place.

The principle is simple: agents should never hold credentials or secrets.

Instead, they authenticate to a governed execution layer. The layer holds credentials in a vault, enforces access policy, runs the query in an isolated environment, and returns results. The agent sees rows. It never sees a connection string. There is nothing to exfiltrate, nothing to leak through a compromised package, nothing to expose through a misconfigured variable.

This is the same principle as modern IAM: workloads get scoped roles, not root access. The boundary is enforced by the platform, not by practitioners remembering to do the right thing under deadline pressure.

For a data execution layer, this means five things in practice:

Credential isolation. Connection strings, API keys, and database passwords live in the layer. The agent calls the layer. The layer calls the source. The agent never sees the secret. Not in the prompt, not in the environment, not in a config file.

Unified policy plane. Whether the source is Postgres, Snowflake, Google Sheets, Salesforce, or an Excel file, access policy is defined and enforced in one place. Query controls apply consistently regardless of where the request originates.

Sandboxed execution. Queries run in an isolated environment, not raw against production. This limits blast radius, enables resource controls, and prevents a runaway query from locking a production table.

Full audit trail. Every query, from every agent or practitioner, is logged. When the next incident happens, and there will be a next incident, you know exactly what was accessed, by whom, and when. That is what your compliance framework requires.

Schema context without credential exposure. Agents can introspect available data sources, table schemas, and column definitions without being handed connection details. They understand the data model. They query through the layer. They never need a direct connection.

As a compounding benefit: a centralised execution layer materialises query results, caches intermediate computations, and accumulates query history across every agent and practitioner. Performance improves. And the layer builds adaptive semantic context over time, keeping agents progressively better grounded in the actual data model.

The Mental Model: A Data Operating System

The right frame is not "a BI tool with an API." It is an operating system.

An OS abstracts hardware from userland processes. Applications do not get raw memory addresses or direct device access. They issue syscalls. The kernel enforces policy. Userland never touches hardware directly.

A governed data execution layer applies the same architecture to data infrastructure. Agents issue query calls. The layer enforces policy. Agents never hold credentials.

Your data sources, Postgres, Snowflake, Salesforce, Google Sheets, Excel, are the hardware. The execution layer is the kernel. The agents, practitioners, and AI tools are userland. The security boundary is a property of the architecture, not of practitioner discipline or careful .env management.

This is what headless BI means when taken seriously. Not "BI without a UI." BI as operating system. A credential-free, policy-enforced, audited query interface that any tool, agent, or practitioner can call, with governance as a first-class primitive, not bolted on afterward.

The Questions Worth Asking Right Now

If you are running analyst agents against production data today:

• Where do your production credentials live? In .env files? In an MCP server config on a practitioner's machine? In a third-party AI tool's OAuth scope?
• What is your blast radius if any tool in your stack is compromised: the AI gateway, a third-party OAuth app, a transitive dependency?
• Can your agents query production data with no enforcement layer between them and the source?
• Are your dependencies pinned, or is your next pip install or npm install resolving to whatever latest is today?

The answer to most of these, for most teams, is uncomfortable.

The incidents above are not edge cases. They are the default failure mode for an industry that moved fast on AI adoption and skipped the security architecture layer. The vibe coding era removed the human friction that was quietly doing security work nobody had formally assigned. Something has to pick up that slack.

The answer is not slowing down. It is building the right architectural layer underneath the speed, so the credential never reaches the agent, the query never executes without a policy check, and the audit trail exists before you need it.

______

Fabi just shipped its headless BI layer, built specifically for data practitioners who want to leverage analyst agents without compromising on security. Connect any data source and never hand your agents a credential. Built-in caching, policy enforcement, and audit logging included. Learn more at fabi.ai