Insights

When a Vendor Breach Inherits Your Permitted Access

May 11, 2026 Alexandre Genest 6 min

Your most valuable data leaves on access you granted on purpose. When a vendor is breached, the attacker inherits access you granted on purpose, and the permission was right; only the behavior changed. How runtime governance catches that.

When a Vendor Breach Inherits Your Permitted Access cover image

You issued the token yourself. You vetted the vendor, scoped the integration, signed the data processing agreement, and wired the connection into production. Months later the vendor gets compromised, and the attacker does not break anything on your side. They pick up the credential sitting in the vendor's environment and use the access you already granted.

Nothing about that access is wrong. The permission was right. Only the behavior changed.

Most third-party risk programs cannot see that change, because they look everywhere except at the data while it moves.

Your vendor reviews happen before and after, never during

Vendor risk management runs at two moments: before the connection exists, and after the incident is closed. You read the SOC 2, the pen test summary, the questionnaire. You re-assess every year. Real work, and it screens out bad partners. But it judges the vendor as an entity at a point in time. It says nothing about the data leaving on that connection at 2am next Thursday.

Continuous monitoring tools watch the vendor's external posture: exposed services, leaked credentials, a slipping security grade. Keep them running. A posture score tells you the vendor looks riskier today than it did yesterday. It does not tell you the integration token you issued is pulling tables it has never touched, on a schedule it has never used, toward a destination that did not exist in its history an hour ago.

The breach never shows up at the vendor's perimeter. It shows up as movement on your side of the connection. You authorized that connection on purpose, so every control that checks whether the move was permitted answers yes and lets it pass.

What an inherited-access breach actually looks like

A SaaS analytics vendor holds read access to a slice of your production data. The access is scoped to a service account and flows over an approved API connection. For months the account does one thing: a nightly pull of a fixed set of tables, steady volume, one known destination.

The vendor is breached. The attacker finds your integration credential in the vendor's environment. No privilege escalation. No lateral movement. No endpoint alarm in your estate. They use the access exactly as it was built to be used. That is the whole problem.

The use is just slightly off. The pull reaches tables outside the agreed scope. It runs at hours the integration never ran. The volume passes anything in the account's history. The egress lands on infrastructure new to this identity.

Read any one of those lines alone and it is the most boring entry in the log. The token is valid. The connection is approved. The action is permitted. Read them together and they are the breach. Every move is permitted. The pattern is the breach.

Runtime is the only window where the pattern is visible

Your most valuable data leaves on access you granted on purpose, so the danger is never one forbidden action. It is the shape of many permitted ones.

A control that asks "was this move allowed" answers yes, correctly, every time, right up to the disclosure letter. To catch the shape you have to watch while the data moves. Not before, when predictive tools guess which vendor might fail and guess wrong. Not after, when forensics reconstructs the loss from access logs you cannot un-leak.

Runtime data movement governance lives in that window. It does not ask whether the vendor was permitted. It asks whether this movement fits what this identity has done every other night.

What Hilt sees that a questionnaire cannot

Hilt watches data movement at the kernel, metadata only by default, off the path. It runs single-tenant inside your own cloud, on the order of 0.1% of one core and 4 to 8 MB of memory per host. It never sits inline, and it does not have to read your data to know a pattern is wrong.

Each move resolves to a probabilistic, source-dependent identity: which service account, which job behind the connection, which destination, and whether this fits the baseline that account built over months. That resolution turns an approved vendor integration from an opaque pipe into something you can reason about while it runs.

When the compromised integration starts behaving unlike itself, the deviation lands across layers at once. The job is unusual for that identity. The access reaches paths the account has never read. The volume breaks from its own history. The destination is new. One signal is noise. The set is a case, not an alert, narrative already written: this account, behaving unlike itself, on this access, toward there.

The response does not wait for you to read the case in time. Hilt isolates the host at the network from the control plane, quarantining the workload. It never stands between your data and where it was headed, because it does not block, drop, or alter traffic. It observes the move and isolates the host.

This sits on top of what you already run

Hilt is additive, and the honest version matters more than the flattering one.

Your vendor risk platform vets partners and scores posture. Keep it. Your CASB and API gateway decide which vendors may connect and at what scope. Keep them. Your EDR watches endpoint behavior. Your CSPM watches cloud configuration. Both do real work. None of them baselines the data movement on a permitted vendor connection and flags the night that movement turns against its own history.

That is the layer Hilt adds. It does not rank your vendors. It tells you when access you already trusted starts doing something it has never done, while you can still isolate the host.

One test for your own stack

Pick your highest-value vendor integration. Ask whether your current tools can answer this about it: did the data on that connection move the way it always moves, resolved to the account and the job behind it, scored against months of its own history, at 2am last Thursday?

If the answer is that the connection was permitted so nothing fired, that is the gap. The permission was right. Only the behavior changed, and behavior is the only place this breach was ever going to show.

If you run vendor integrations that touch your most sensitive data, a 30-minute technical call walks through exactly what Hilt would see on one of your real connections, engineer to engineer.