Your AI Doesn't Know the Login Was Stolen

ttackers only need one person, once. A company can train every employee, run every simulation, and still lose a working credential to a single convincing phone call. At the scale of a large enterprise, that is close to inevitable. What is not inevitable is how much of the business that one credential can reach.

On August 25, 2026, McKesson discovered a cybersecurity incident affecting its information systems. Three days later the company disclosed it in an SEC filing and said the investigation was in its early stages. McKesson has since confirmed that an unauthorized party reached third-party applications and removed data belonging to some customers of its Oncology & Multispecialty and Medical-Surgical businesses.

Public reporting, based largely on claims made by the ShinyHunters extortion group, describes attackers phoning employees, talking them out of their login details, and then using those details to sign in and reach the company's cloud applications. McKesson has not publicly confirmed the initial-access method, the applications involved, the volume of data taken, or the number of individuals affected. Those distinctions matter, and speculating beyond the confirmed facts would be irresponsible.

This is not an argument that McKesson, its identity provider, or its data platforms failed at their jobs. A login system generally keeps working exactly as designed after someone else is holding the password. That is the whole difficulty. It is also not an opening for a technology vendor to claim that one product would have prevented all of this.

The useful question is architectural:

When an attacker can successfully present a valid identity, what limits what that identity can do with the organization's data?

That question gets sharper as enterprises deploy AI agents that find information, generate queries, invoke tools, coordinate with other agents, and act at machine speed.

The answer cannot be authentication alone.

Definition

Zero Trust for Data assumes that any human identity, machine credential, application, or AI agent may be compromised. It grants no implicit trust based solely on successful authentication, network location, role membership, or platform access. Every request is evaluated against the human, the agent, the delegation chain, the approved purpose, the requested action, the sensitivity of the data, and the current risk context — and returns only the data necessary for that task, for only as long as it is needed.

Almost nobody argues with that definition. The difficulty is what it commits you to. Six claims follow from it, and each one asks an organization to change something it currently treats as settled.

The argument in brief

1. Authentication is one input to the decision, not the decision.A valid login should not simultaneously settle which data, which records, which fields, for what purpose, and for how long.
2. Least privilege is not enough. You also need least data.Least privilege controls whether an operation runs. Least data controls how much it returns.
3. Centralize authorization, not necessarily the data.One policy plane, enforcement inside each platform, and no single credential that spans the whole estate.
4. An AI agent is not a faster user. It is a separate identity.The human and the agent both have to stay visible, and delegation has to narrow authority at every hop instead of widening it.
5. Identity answers who. Purpose answers why.A purpose has to come from an approved case, project or workflow, not from something typed into a prompt.
6. Audit has to become a control loop.Checking behavior against what was actually authorized, while the work is still happening.

What follows takes each of these in turn, and ends with eight recommendations in the order we think they have to happen.

A valid login is not an authorization decision

Authentication establishes confidence in an identity. It does not prove that every subsequent action taken with that identity is legitimate. Once a credential, session, or token is compromised, the authentication system may keep working exactly as designed. The attacker looks like the employee and inherits the employee's groups, roles, application access, and standing permissions.

Traditional zero trust holds that no user or asset should receive implicit trust based on its location or ownership. It treats authentication and authorization as distinct decisions and protects individual resources rather than a trusted perimeter. Zero trust for data applies that same thinking directly to the data layer.

A successful login should not simultaneously answer:

• Which datasets and which records may this identity access?
• Which sensitive fields should be visible, and in what form?
• For what validated business purpose?
• How much data may be returned, and may the result be exported?
• How long should the authorization last, and may an agent exercise or delegate it?

Authentication answers who presented the credential. Data authorization still has to determine what this specific human or agent may do with this specific data, for this specific purpose, right now.

Least privilege controls operations. Least data controls exposure.

The goal is not to slow legitimate work down or bury information behind approvals. It is to maximize legitimate use while minimizing unnecessary exposure.

An analyst may need to study customer activity without needing every customer record in the company. A support representative may need detail on an assigned account, not every account. A researcher may need aggregate findings, not direct identifiers. A financial analyst may need transaction totals, not names and account numbers in clear text.

For a human, zero trust for data means receiving just enough data to complete the approved task: only the relevant datasets, rows, and columns; sensitive values masked when clear text is unnecessary; aggregates when raw records are unnecessary; access bound to an approved purpose; and authorization that expires when the work is complete.

Roles remain useful, but they are too coarse to make all of those decisions. A role establishes that someone is an analyst. Attributes establish the business unit, the region, the customer assignments, the completed training, the project membership. The decision also has to account for data sensitivity, the requested action, the approved use, and current context.

The difference is substantial. Under a coarse model, compromising one analyst may expose everything reachable through the analyst role. Under a fine-grained model, it exposes only the customers, records, fields, and uses that policy permits for that particular identity.

A compromised identity is still a serious event. It does not have to become a compromised data estate.

Centralize authorization — not necessarily the data

Cloud data platforms create enormous value by making information easier to discover, combine, and use, and consolidation often lowers infrastructure cost while making control simpler than managing hundreds of isolated systems.

But concentration changes the security equation. When large volumes of sensitive data sit behind a small number of access paths, the value of compromising one of those paths increases. A broad role, a privileged service account, or a compromised SSO identity can reach far more than it could in a fragmented environment.

The answer is not indiscriminate decentralization. Spreading data across additional platforms produces more copies of sensitive data, more systems to configure and monitor, inconsistent access policies, incompatible audit formats, orphaned datasets, and more credentials for privilege to accumulate against. Running three data platforms creates no meaningful segmentation if the same identity, role, or token moves freely across all three.

The better architectural principle is to centralize policy and visibility while distributing enforcement and preserving appropriate data boundaries. Minimize unnecessary copies. Keep data in authoritative systems where practical. Separate the most sensitive data domains. Apply consistent authorization across every environment.

The objective is not one physical repository or ten. It is that no single identity, token, role, application, or agent becomes a universal path to all enterprise data. A centralized authorization layer can govern access consistently while enforcement stays close to the data in each platform — which lets an enterprise consolidate where it makes economic and operational sense without treating platform access as permission to see everything inside the platform.

One policy plane. Multiple enforcement points. Bounded exposure everywhere.

Agents are distinct identities, not faster users

An agent is not merely a faster user interface. It can interpret a request, discover relevant sources, formulate queries, invoke APIs, combine results, create files, and hand parts of a task to other agents. A single human prompt may generate hundreds of downstream actions.

Agents are not inherently malicious. But they have no independent sense of organizational proportionality or confidentiality. They pursue an objective using the instructions, tools, context, and permissions they were given. An agent will not conclude on its own: I technically have access to ten million records, but I probably only need twenty. That restraint has to be designed into the authorization system.

This is why an agent should not simply impersonate the person using it. OAuth is not the problem — OAuth can support secure, limited delegation. The problem occurs when an agent receives a broad user token, becomes indistinguishable from the human, and inherits all of that human's standing access across downstream systems. When that happens, the organization loses the ability to distinguish the human who initiated the request, the agent that interpreted it, the service that executed it, and the sub-agent that performed part of the work — along with what authority was delegated, for what purpose, and what data each participant touched.

A secure agentic architecture preserves both the human identity and the agent identity. For every interaction, the authorization layer should know which human initiated the task, which agent is acting, whether that agent is autonomous or acting on someone's behalf, what authority has been delegated, which tools and data domains are in scope, which business purpose governs the work, how long the delegation remains valid, and whether additional agents may be invoked.

Agent authority should be temporary and bounded. An agent may require narrow access to a semantic layer, lookup table, or similar resource in order to function — but that should never expand the human's entitlement to sensitive data.

The same principle applies to sub-agents. Every delegation step should carry the original human, agent, and purpose context forward. Authority should remain constant or narrow as work moves downstream. A sub-agent should never gain privilege simply because an upstream agent asked it to complete a task.

Otherwise, the compromise of one human identity becomes the starting point for automated activity across many systems, with several agents all appearing to be the same person. That is not just impersonation. It is privilege amplification.

Identity answers who. Intent answers why.

Knowing who is requesting data is not enough. A person can hold every correct attribute and still attempt to use data for an inappropriate purpose.

The same healthcare analyst may legitimately access patient information for care operations but not for marketing. The same employee may be allowed to investigate one customer complaint but not export every customer record. A researcher may be authorized to use data for one approved study but not to train an unrelated AI model. The identity has not changed. The purpose has.

That is why intent must become an input to authorization. An intent represents an approved operating context: investigating suspected fraud, supporting a specific customer, conducting an approved clinical study, completing a regulatory report, reconciling a transaction, responding to a particular incident.

Critically, purpose cannot be accepted merely because a user or agent typed it into a prompt. If the entity requesting access is also inventing the justification for receiving it, there is no control. Purpose has to be grounded in trusted context — an approved project, case number, workflow, access request, data-use agreement, or policy-controlled business process — and the authorization layer has to validate that this human and this agent are permitted to operate under that intent.

For agents this matters even more, because one request produces many actions, and each action must remain bound to the approved intent. An agent should not be able to reinterpret a customer-support request as authorization for bulk analysis. A sub-agent should not be able to create a new purpose. A connector should not receive broader authority because it sits further down the execution chain.

Purpose has to travel with the work.

Audit has to become evaluation

Preventive authorization is only half of zero trust for data. Organizations also have to evaluate continuously whether actual behavior remains consistent with what was authorized.

Most audit systems operate as archives. They collect logs so investigators can reconstruct events days or weeks later. That remains necessary, but it is no longer sufficient. In an agentic environment, enormous volumes of data can be discovered, queried, joined, and moved in minutes. Audit therefore has to feed an active control loop: observe the activity, interpret it in the context of the human, agent, data, and purpose, identify deviation, and adjust or revoke access.

Behavior is contextual. A query returning a million rows may be routine for an approved regulatory process and alarming inside a support interaction. Hundreds of rapid queries may be normal for an autonomous reporting agent and suspicious for an employee who usually opens a dashboard twice a week. That requires baselines for more than individual users — by human, by agent, by human-agent pair, by approved intent, by data domain and sensitivity, by volume, and by delegation path.

Signals worth watching include first-time access to a sensitive dataset, a sharp increase in rows returned, queries spanning unrelated data domains, an export inconsistent with the approved purpose, an agent invoking a tool it has never used, a sub-agent reaching outside its parent task, or a temporary authorization being used differently than it was requested.

Not every anomaly is an attack. Quarterly reporting, litigation, and incident response all generate unusual behavior. Which is why purpose matters to detection as well. The question is not only is this statistically different? It is is this activity consistent with what this human or agent was authorized to accomplish?

The response can then be proportional to the risk: raise an alert, require additional approval, reduce the rows returned, apply stronger masking, shorten the authorization window, pause the agent, revoke the credential, or terminate the session.

Data-layer audit context — the actor, the role, the query, the objects and columns accessed, the rows produced — should complement, not replace, identity threat detection, SIEM, UEBA, DLP, endpoint security, and incident response.

What changes when an identity is compromised

Zero trust for data does not promise that no identity will ever be compromised. It changes what happens next.

An attacker compromises an employee's identity. The identity provider accepts the login. The employee legitimately belongs to a group with access to a data platform. The data authorization layer still evaluates every request: the employee is entitled only to records for assigned customers, sensitive identifiers stay masked, a broad export does not match the approved intent, access exists only inside a temporary task context, and unusual volume produces an immediate signal.

Now the attacker reaches for an AI agent. The agent does not silently become the employee. It authenticates as a distinct agent, identifies the human on whose behalf it is acting, receives temporary task-specific authority, and remains bound to the approved purpose. Any sub-agents carry the same delegation context without expanding it.

None of this makes the original compromise harmless. It does materially reduce the blast radius: less data is reachable, less sensitive data is returned in clear text, standing access is smaller, delegated access expires, agent activity stays attributable, unusual behavior is easier to recognize, and security teams get more opportunities to intervene.

There is an honest limitation. If the compromised human is already entitled to retrieve every affected record in clear text, no authorization layer can know that the person behind an otherwise valid session has changed. That is precisely why standing access has to be minimized before an incident, not during one.

Least privilege cannot be retrofitted mid-breach.

What we recommend, in order

Zero trust for data is not a product you install or a project that finishes. It is a sequence of architectural changes, and the order matters more than most roadmaps admit. Two of them have to be underway before an incident, because they cannot be done during one.

1. Establish sensitivity as a fact about the data, not a label on a system.
   Discover and classify sensitive data, and carry those classifications across every platform that holds it. Everything downstream is only as good as this. Marking a system "confidential" tells you nothing about which column holds a national identifier.
   Ask: can you list every place a national identifier can be returned in clear text today?‍
2. Inventory and reduce standing access.
   Find the broad roles, the privileged service accounts, the dormant grants, the orphaned datasets. Then cut what nobody is using. This is the recommendation that cannot wait, because standing access is precisely what a compromised identity inherits.
   Ask: if one analyst's credentials were used tonight, what could be exported before anyone noticed?‍
3. Move the access decision from group membership to evaluated context.
   A role establishes what someone is. Attributes establish which business unit, region, customer set, training, and project they belong to. Decide at query time against those attributes and the sensitivity of the data, rather than provisioning another role or another copy.
   Ask: how many roles exist only to describe one combination of region and business unit?‍
4. Make reduced data the default and clear text the exception.
   ‍Row filters, column masking, and aggregation should be what a query returns unless something specific justifies more. Reverse the default: clear-text access should require a reason, not merely the absence of an objection.
   Ask: for how many of your sensitive columns is clear text the current default?‍
5. Centralize the policy plane and keep enforcement local.
   Author policy, purpose, and audit in one place. Enforce inside each platform, next to the data. Minimize copies, keep data in authoritative systems where practical, and separate your most sensitive domains so that no single credential spans all of them.
   Ask: could you answer "who can see this column, everywhere" without opening more than one console?‍
6. Register agents as identities in their own right.
   An agent should authenticate as itself, name the human it is acting for, and hold temporary, task-scoped credentials. Do not hand an agent a broad user token. Constrain delegation so authority stays the same or narrows at every hop, and never widens.
   Ask: can you say which agent, acting for which human, ran a given query last week?‍
7. Ground purpose in a system of record.
   Bind access to approved intents that originate in a case, project, workflow, access request, or data-use agreement. A purpose typed into a prompt is a claim, not an authorization. Validate that this human and this agent may operate under that intent, and require the intent to travel with every downstream action.
   Ask: where would an approved purpose come from today, if you had to point at one?‍
8. Wire audit into a control loop.
   Baseline behavior by human, agent, human-agent pair, intent, data domain, and volume. Route deviations to a proportional response, from an alert through to revoking a credential. Then test that the loop actually fires, because an untested control is a logging configuration.
   Ask: what happens in the first ten minutes after an agent returns a million rows it has never touched before?

None of this requires a single vendor, and none of it is quick. But the first two recommendations determine how much the rest can help you. An organization that has reduced standing access and knows where its sensitive data lives has already changed the outcome of its next compromised identity, whatever else it does.

Where Immuta fits

We do not claim that a data authorization platform prevents an employee from being phished. Immuta is not an identity provider, an MFA product, an endpoint security service, or a substitute for an organization's broader detection and response stack.

Our role begins when a human, application, or agent attempts to use data. Immuta translates identity attributes, agent identity, data sensitivity, policy, and intent into fine-grained controls enforced in the underlying data platforms — determining whether access is granted, which rows are returned, which fields are masked, what data may be used under a particular intent, whether access should be temporary, and what evidence is captured for audit.

For agentic access, Immuta treats humans and agents as separate identities, using temporary roles and short-lived platform credentials so an agent can act on behalf of a human while both identities remain visible and data policies stay enforced.

That does not eliminate risk. It prevents successful authentication from being the only meaningful decision between an identity and the enterprise's data.

Design for the successful phish

Keep making identity compromise harder. Deploy phishing-resistant authentication, harden account recovery and help-desk processes, evaluate devices and sessions, protect privileged accounts, revoke suspicious credentials quickly.

Then build the data architecture on the assumption that one of those controls will eventually fail — and that a well-intentioned agent can overreach, a compromised agent can act at machine speed, and a compromised human identity can be used to initiate agentic workflows.

No longer sufficient

This identity successfully logged in.

The standard now

This specific human or agent is authorized to perform this specific action, on this specific data, for this validated purpose, under these conditions, right now.

Assume the login can be stolen. Assume AI will use it before anyone notices. Then design the data layer so that no single identity, human or agent, can ever hold a blank check.

‍