The credential was valid. The export was 100 million records.

The 2024 campaign against cloud data warehouse tenants is remembered as a breach and taught as an MFA lesson. It was neither. Every authentication succeeded, the platform was not compromised, and the thing nobody asked was whether a human meant to export the customer table.

Somewhere in the second half of 2023, on a contractor's personal laptop, an installer for a cracked piece of software did what it was built to do. It walked the browser profiles, pulled saved passwords out of the credential store, copied session cookies, harvested anything in a password manager that had been left unlocked, packaged all of it, and posted it to a server. The contractor noticed nothing. There was nothing to notice. The machine kept working perfectly, which is the entire design goal of an infostealer, because a machine that misbehaves gets reimaged and a machine that does not gets to keep producing credentials for months.

That package joined millions of others in a commodity market. Stealer logs are sold in bulk, sorted, indexed and searchable by domain. Somebody searching for a particular data warehouse domain would find, among thousands of entries, a set of working credentials for an analytics account at a large company. The credentials had been rotated at some point on paper, and not in practice. The account had no multi factor authentication because it was a service oriented analytics login that predated the policy, and it had been exempted, and the exemption had outlived everyone who remembered granting it.

Months later, someone logged in. Not exploited. Logged in. Username, password, session established, welcome back. Then they ran a query. Then they ran a query that returned everything, and staged it, and pulled it down.

Nothing in that tenant asked a single question about the second query that it had not already asked about the first. There was no threshold, no confirmation, no human in the path. The system did exactly what a party holding valid credentials told it to do, which is what systems are for.

What actually happened in the Snowflake customer campaign?

The public account, principally from Mandiant's 2024 reporting on the threat cluster it tracks as UNC5537 and from the platform's own statements, is unusually clear for an incident of this size, and it is worth stating precisely because the details are constantly misremembered.

Attackers obtained credentials for customer tenants. The credentials came predominantly from infostealer infections, a meaningful share of them on machines belonging to contractors rather than employees, some of the infections dating back years before the credentials were used. The affected accounts lacked multi factor authentication. Once authenticated, the attackers reconnoitred and then exported data at scale. Mandiant's reporting described at least 165 potentially exposed customer organisations. Several of the victims were very large, and the incidents widely reported at the time involved record counts in the hundreds of millions across the campaign as a whole. A defendant later pleaded guilty in connection with the campaign, with reporting on the plea describing extortion proceeds in excess of two and a half million dollars.

Now the part that matters and that most coverage buried under the word breach.

There was no vulnerability in the platform. No exploit, no bypass, no flaw in the authentication logic. The platform's own investigation and the external analysis agreed on this. Every single authentication in the campaign was, from the system's point of view, correct. Valid credentials were presented and valid credentials were accepted, which is precisely what a login system is contractually obliged to do.

Calling it a breach of the platform is not merely unfair to the vendor, it is analytically destructive, because it points every reader towards the wrong remediation. If you believe a system was broken, you patch the system. If you understand that the system worked, you have to ask a harder question, which is why working exactly as designed produced this outcome.

Why was "enforce MFA" the wrong lesson?

It was not a wrong lesson. It was an incomplete one, in a way that has consequences.

Multi factor authentication at login would have stopped this specific campaign, and the platform's subsequent move to make MFA enforceable and then default was correct and overdue. If your data warehouse accounts lack MFA today, close this article and go fix that first, because you have a more urgent problem than the one discussed here.

But look carefully at what MFA changes. It raises the cost of obtaining a session. It does absolutely nothing about what the session can do once obtained. The entire security value is spent in the first second of the connection, and every action afterwards inherits authority from that moment without further question.

This matters because sessions are stolen in ways that do not care about MFA at all. Adversary in the middle phishing kits proxy the genuine login page, let the victim complete multi factor authentication correctly against the real identity provider, and capture the resulting session cookie, a pattern examined in detail in your MFA worked perfectly, the attacker was already inside the session. Infostealers take cookies directly from the browser profile alongside passwords. Long lived API tokens and personal access tokens skip login entirely by design. In each case the attacker ends up holding a valid session against an account with MFA fully enabled, and MFA has no further move to make.

So the honest formulation of the post mortem is this. MFA enforcement fixes the specific credential path used in 2024. It does not fix the structural condition that made the export possible, which is that the export was never authorized by anybody. It was performed by a session. This is Session-Inherited Authorization applied to the most valuable action the system offers.

Why does authentication say nothing about volume?

Here is the analogy, and it is worth sitting with because it reframes the problem permanently.

A library gives you a card. The card proves you are a member in good standing. You show it at the desk, you take out a book, everything is in order. Now imagine the same card, at the same desk, with the same check, also authorises you to reverse a lorry up to the loading bay and remove the entire collection. Nobody would design that. The membership check and the removal check are obviously different questions with obviously different stakes, and any physical institution separates them instinctively, usually with a person whose whole job is to look at the lorry.

Now the mechanism, which is where the analogy has to stop and the precision has to start.

In a data platform, a query is a query. The authorization model asks whether this principal may read this object. It is a boolean about access, and it is evaluated identically whether the result set is one row or nine hundred million. Row level and column level security refine which data is visible, and they are genuinely valuable, but they refine the same boolean. There is no dimension in the model that represents magnitude, because magnitude is a property of the result, not of the request, and the authorization decision is made before the result exists.

That is not an oversight by any particular vendor. It is inherited from the relational model itself and it is present in essentially every database and every SaaS reporting tool ever built. The permission to read a table has always implied the permission to read all of it. For forty years that was fine, because reading all of it meant a tape, a room, and a person who had to be physically present.

What changed is that the loading bay became an API call, the lorry became a signed URL to object storage, and the entire collection became a hundred gigabytes that leaves in eleven minutes over someone else's network. The authorization model did not change. The physical friction that used to substitute for a control simply evaporated, and almost nobody noticed because nothing broke.

The two questions nobody separates

Write them next to each other and the gap is obvious.

May this principal read this data? Answered by access control. Answered well, by mature systems, with roles, grants, row filters and masking policies. Genuinely solved.

Did a human intend to move this much of it, to there, now? Not answered by anything. Not asked by anything. There is no field in any grant statement that expresses it, and no point in the query path where the question is posed.

Every large exfiltration incident of the last five years lives in the space between those two sentences.

Why do rate limits, anomaly detection and DLP not close this?

They help. They are worth running. And each of them has the same structural position, which is downstream of the authority having already been granted.

Anomaly detection compares this query against a baseline and raises an alert when the volume looks unusual. The alert is generated as the data moves or after it has moved. In an incident where staging and download take minutes, an alert that reaches a human queue in twenty is a notification, not a control. It also has the ordinary base rate problem: analytics teams run enormous legitimate queries constantly, quarter end looks exactly like exfiltration, and a detector tuned tightly enough to catch the real thing will bury the team, so in practice it gets tuned loose.

Rate limits and result caps are a genuine control and underused, but they are blunt in a way that makes people disable them. A cap that permits the largest legitimate export permits most illegitimate ones, and a cap set below legitimate need becomes a ticket queue that engineers route around with a service account, which is how the exempted account in our opening story came to exist in the first place.

Data loss prevention inspects content on the way out and blocks what matches policy. It is meaningful for known patterns and structured identifiers. It is also positioned at the egress point of an action that was already authorized, it struggles with the encrypted and compressed staged transfers that data platforms use natively, and it does not attempt to answer the intent question at all.

Infostealer monitoring services tell you when your domain appears in a stealer log on a criminal market. This is useful and you should buy it. It tells you about a credential that has already been stolen and often already sold, and its value depends entirely on your ability to rotate faster than a buyer can act, which in the 2024 campaign was a race measured in months and lost.

The common shape: all four are estimates made after the authority was granted. The thing missing is a decision made before, by a person, about this specific movement of data.

What does a signed export actually look like?

The control is narrow, which is what makes it viable. You do not sign every query. You classify egress by blast radius and require a fresh human signature above a threshold.

Blast radius, not sensitivity. Sensitivity classification is a project that takes eighteen months and is never finished. Row count and destination are properties you already have, at the moment you need them, without a data governance programme. Start there and refine later.

The payload that gets signed is the description of the movement:

{
  "typ": "manav.action.export.v1",
  "tenant": "acme-prod",
  "object": "analytics.customers",
  "row_estimate": 41880012,
  "destination": "s3://acme-exports/2026-09-11/",
  "requested_by": "svc_analytics_7",
  "requested_at": "2026-09-11T02:14:09Z",
  "reason_code": "quarterly-audit-extract"
}

That object is hashed, and the hash becomes the challenge for a WebAuthn assertion produced on an enrolled device belonging to a named human. The stolen credential does not include that device. The infostealer log does not contain it. The proxied login session cannot produce it. What comes back is a receipt that verifies offline against a published key, which means an auditor or a regulator can check it later without asking the platform or us to vouch for anything.

The gate is unremarkable to implement, which is deliberate:

def authorize_export(req, policy):
    if req.row_estimate < policy.threshold_rows and req.destination in policy.internal:
        return ALLOW                       # ordinary analyst work, untouched

    if req.principal.is_service_account:
        chain = delegations.for_job(req.job_id)
        if chain and chain.covers(req) and not chain.revoked():
            return ALLOW_WITH(chain)       # pre-authorized recurring job
        return DENY("no valid human delegation for this scheduled export")

    receipt = manav.require_signature(payload=req, timeout="90s")
    if not receipt.valid():
        return DENY("bulk export requires a human signature")
    return ALLOW_WITH(receipt)

Three branches. Ordinary work passes untouched, which is what keeps the control alive politically. Scheduled and automated work runs under a delegation a human signed once, with a scope and an expiry. Everything else, above the threshold, needs a person.

The worked example

Replay the opening story with the gate in place. The attacker has the same stolen credentials, the same absent MFA, the same session. They log in. They reconnoitre freely, because reconnaissance is small queries and small queries are untouched. They then request the customer table.

The request crosses the threshold. The platform constructs the payload above and demands a signature. There is no device to sign with. The export is denied, and the denial itself is a high fidelity signal, because a failed bulk export signature request is not an ambiguous anomaly score, it is a specific event that says somebody with valid credentials tried to move forty million rows and could not prove they were a person. That event is worth waking someone up for, and unlike an anomaly alert it fires before the data moves rather than during.

But what about scheduled exports and pipelines?

This is the first objection any competent data engineer raises, within about four seconds, and it is correct. A design that ignores it deserves to be ignored.

Most bulk data movement in a mature organisation is legitimate, recurring and unattended. Nightly extracts to a warehouse, replication to a reporting environment, feeds to a partner, model training pulls, backup jobs. Nobody is awake at 02:14 to tap a phone, and any control that requires it will be removed within a fortnight, correctly, because availability is also a security property.

The answer is a scoped delegation rather than a per run signature. A named human signs one object that says: this job, moving this class of data, to this destination, up to this volume, on this schedule, until this date. That delegation is itself a signed artifact with an expiry and a revocation identifier. Each nightly run verifies against it and proceeds. The human signed once and remains accountable, which is a different and better property than nobody having signed at all.

Three design rules make this work in practice rather than on a slide.

Delegations expire and the expiry is short enough to matter. Ninety days, not never. The renewal prompt is the review that access certification campaigns pretend to be.

Scope changes break the delegation. If the job starts writing to a new destination or the volume doubles, the delegation no longer covers it and a human is asked again. This is where the control earns its keep, because a compromised pipeline that starts sending elsewhere is exactly the case you care about.

Fail loudly, never silently. A denied export must page someone. The failure mode of a quiet denial is a broken pipeline that nobody notices for a week, and after that happens once the whole control gets disabled. Related mechanics for bounding and revoking delegated authority are covered in delegation chain depth and the authority graph.

There is a fourth case that is now unavoidable, which is the autonomous agent with warehouse credentials. An agent writing and running its own SQL is a service account with judgement, and the judgement is the problem: it can decide to widen a query for a reason that seemed sound inside its context window. The same delegation model applies, with the additional requirement that the chain be walkable back to the human who authorised the agent. The failure pattern when nothing gates the destructive or bulk operation is the one described in three AI agents deleted production databases.

What does this do for incident response?

This is the benefit that gets undersold, and for a CISO it is often the one that funds the work.

Consider the position of a responder on day one of a suspected exfiltration. The question is which data left, and the available evidence is query logs. Query logs are voluminous, they describe what was run rather than what was intended, and they cannot distinguish an analyst's quarterly extract from an attacker's staging run, because at the log level those two things are identical. So the responder reconstructs intent by interviewing people, weeks after the fact, about queries they may or may not remember. That is why breach investigations take months and why disclosure statements say "we are unable to determine".

Now add receipts. Every bulk export above the threshold carries either a human signature or a delegation chain naming the human who authorised the job. The responder partitions the entire set of large movements in one pass: authorised, with a named person and a timestamp, or unauthorised. The unauthorised set is the investigation, and it is usually small.

That partition also has value the responder does not get to enjoy but the general counsel does. Under breach notification regimes that turn on the scope of affected data, being able to demonstrate with cryptographic evidence which exports were human authorised is materially better than an affidavit about log interpretation. It composes with the broader argument in audit trail design for AI agents, which is that evidence you generate yourself is weaker than evidence a third party can verify without trusting you.

Where should the control sit?

No row replaces the others. The point of the table is that six of the seven rows answer questions about access or about statistics, and exactly one answers a question about a person's intention.

Honest limits

An insider with an enrolled device can sign. A malicious employee who genuinely holds the credential and the device will produce a valid signature and take the data. What changes is attribution: the export carries their name, cryptographically, and they knew it did at the moment they signed. That is a deterrent and a strong evidentiary position, and it is not prevention. Anyone claiming a signature stops a determined insider is overselling.

Slow theft under the threshold evades this entirely. An attacker who reads a hundred thousand rows a night for a year moves the same data and never trips the gate. Thresholds create a rate ceiling, not a total ceiling. Volumetric detection over long windows remains necessary, which is one reason this composes with anomaly detection rather than replacing it.

It does nothing about read access. Someone who can query can see. If the harm in your threat model is a person reading twenty specific records rather than exporting forty million, this control is the wrong tool and you want access minimisation and purpose limitation instead.

Thresholds are a policy judgement and you will get them wrong first. Set them too low and you generate fatigue that kills the control; too high and the gate never fires. Expect to tune for a quarter, instrument the denials, and treat the first month as calibration rather than enforcement.

Manav has no data platform connectors. The shipped pieces are the per action signature, the delegation chains and the offline verifiable receipts. Putting them in front of a warehouse export today means a query proxy or an application layer gate that you build. There is no native integration with any data platform, and describing one would be describing roadmap.

What to do this week

1. Inventory your export paths, not your tables. List every way data leaves at volume: warehouse export, signed URLs to object storage, share features, reporting downloads, API pagination at scale, replication targets. Most teams find two or three nobody remembered.
2. Find the exempted accounts. Every organisation has a small set of logins excused from MFA for a reason that made sense once. Enumerate them, find out who granted the exemption, and note how many of them belong to contractors or to people who have left.
3. Measure your own distribution. Pull ninety days of export volumes and plot them. The threshold conversation is unwinnable in the abstract and easy with a histogram, because in most organisations the legitimate large exports turn out to be a small, nameable set of recurring jobs.
4. Ask who authorised your three largest recurring exports. If the answer is a ticket from 2023 closed by someone who has since left, you have found the delegation you need to make explicit.
5. Check whether your platform can gate export separately from query. Read the documentation rather than assuming. The answer determines whether you gate in the platform, in a proxy, or in the application.
6. Give your agents a chain. Any agent holding warehouse credentials should have a delegation naming the human who authorised it, with a scope and an expiry, before it has a bad week.
7. Run the tabletop with the query log only. Ask your responders to determine, from logs alone, which of last month's ten largest exports were legitimate. The time it takes is the cost of not having receipts, and it is more persuasive than any vendor slide.

The signing and delegation mechanics are documented in the developer documentation, and the signing demo shows a payload bound signature end to end in a browser if you want to see the shape before designing around it.

Frequently asked questions

How did the Snowflake breach happen and what would have prevented it? Attackers used credentials stolen by infostealer malware, often from contractor machines, to log into customer tenants that lacked multi factor authentication, then exported data at scale. There was no platform vulnerability and every authentication succeeded. Enforcing MFA would have blocked that specific credential path. Requiring a human signature on bulk exports would additionally block the case where a session is stolen after a correct MFA login.

Was Snowflake itself breached? No. The public reporting from Mandiant and the platform's own investigation concluded that the campaign targeted individual customer tenants using valid stolen credentials, not a flaw in the platform. This distinction matters because it determines the remediation: there was nothing to patch, and the exposure came from how customer accounts were configured and how sessions carry authority.

What is an infostealer? An infostealer is malware that harvests saved passwords, session cookies, browser autofill data and token files from an infected machine and sends them to an operator, usually without disrupting the machine at all. The resulting stealer logs are traded in bulk on criminal markets and indexed by domain, so an attacker can search for credentials belonging to a specific target company months or years after the infection.

Should data exports require MFA or step-up authentication? Above a volume or destination threshold, yes, and a signature bound to the specific export is stronger than a generic step-up prompt. A generic prompt proves someone completed a challenge in the session; a signature over the export payload proves a named human approved this object, this row count and this destination, and produces a receipt that verifies offline afterwards.

Will this break our scheduled data pipelines? Not if it is designed properly. Recurring and automated exports run under a scoped delegation that a named human signs once, covering a defined job, destination, volume ceiling and expiry, so unattended runs proceed without a prompt. A human is asked again only when the scope changes, the volume ceiling is exceeded, or the delegation expires.

Can an AI agent export data from a warehouse? It can if it holds credentials, which is the concern. An agent is a service account that makes its own decisions, so it can widen a query for reasons that seemed reasonable in its context. The workable arrangement is a delegation chain: the agent acts under authority a human signed, with an explicit scope and expiry, and every export it performs is traceable back to that human.

Does this help during a breach investigation? Substantially. Query logs record what ran but not what was intended, so responders reconstruct intent by interviewing people weeks later. Export receipts partition large movements immediately into human authorised, with a named person and timestamp, and everything else. The second set is usually small and becomes the actual investigation.

Sources

1. Mandiant, Google Cloud Threat Intelligence, UNC5537 targeting Snowflake customer instances for data theft and extortion, 2024. cloud.google.com
2. Snowflake, company statements and security advisories on the 2024 customer account campaign. snowflake.com
3. United States Department of Justice, charging and plea documents in the related prosecution. justice.gov
4. NIST Special Publication 800-63B, Digital Identity Guidelines, authentication and reauthentication requirements. pages.nist.gov
5. CISA, guidance on credential theft and identity based intrusions. cisa.gov
6. IBM, Cost of a Data Breach Report series. ibm.com
7. Center for Internet Security, CIS Critical Security Controls, data protection controls. cisecurity.org

The export was not authorized by anyone. It was performed by a session, and a session is not a person.