The Trust Surface: The Missing Complement to Attack Surface

Organizations don't have an identity crisis. They have a trust accounting crisis. Nobody is keeping the books.

Security has gone through two eras of defining itself by what it measures. In the 1990s, security meant the firewall: define the perimeter, control what crosses it. In the 2010s, as the perimeter dissolved into cloud and SaaS, security redefined itself around identity: Who are you, and what have we verified about you? Both eras produced real, durable progress. Both also quietly assumed the same thing — that once something was verified, it could be trusted going forward without much further scrutiny. That assumption held up reasonably well when the things being verified were mostly people.

It does not hold up anymore, and the reason is a numbers problem nobody built a metric for. Palo Alto Networks' 2026 Identity Security Landscape report — a 2,930-respondent survey and the successor to CyberArk's long-running identity survey after Palo Alto's acquisition of the company — found that 90% of organizations have suffered at least one identity-related breach in the past year, and 83% have suffered two or more. GitGuardian's 2026 secrets-sprawl research puts the ratio of machine identities to human identities at 80 to 1; Axis Intelligence's 2026 composite puts it at 109 to 1, up from 82 to 1 the year before. For every person a company employs, there are now somewhere between 50 and 109 non-human identities operating with almost none of the oversight applied to a new hire — and almost every security metric in wide use was built to track the humans, not the rest.

Last August, that gap stopped being theoretical. A threat cluster tracked as UNC6395 used a single set of stolen OAuth tokens — tied to the Salesloft Drift chatbot integration — to walk into more than 700 Salesforce customer environments, including Cloudflare, Google, PagerDuty, and Palo Alto Networks itself. Nobody exploited Salesforce. Google's Mandiant unit traced the root cause back to a compromise of Salesloft's own GitHub account months earlier; the tokens sat quietly, fully trusted, until attackers ran automated queries hunting support tickets for embedded secrets — AWS keys, Snowflake tokens, VPN credentials. Every existing framework struggles to explain what happened here. It wasn't an attack surface failure — there was no vulnerability to patch. It wasn't strictly an identity failure either — the tokens were, by every identity check that mattered, exactly who they claimed to be. Something else broke, and the vocabulary to name it doesn't exist yet.

Here's the underlying question, stripped of tooling and vendor language: what is trust, actually? Not as a feeling, as an engineering decision. Trust is what you get when you decide to stop verifying something continuously. You check a credential once, or on a schedule, and in between checks you act as though nothing has changed. That's not a flaw in how systems are built — constant re-verification of everything would be paralyzing — but it means every trust relationship is a bet that the interval between checks is short enough not to matter. Firewalls managed that bet at the network layer. Identity managed it at the authentication layer. Nobody is managing it at the layer where it now matters most: the accumulated, compounding set of things a system has already decided, at some point, to stop checking.

Call it the trust surface. Attack Surface answers "what can attackers reach?" Trust Surface answers a different question: "what can entities we've already decided to trust reach — and did anyone actually decide that on purpose, or did it just accumulate?" Those are not the same question, and the Salesloft-Drift breach is what happens when an organization only instruments the first one.

The Five Principles of Trust Surface

Attack surface has rules everyone already knows intuitively: patch it, scan it, shrink it. Trust Surface behaves by different rules, and until security teams internalize them, they'll keep managing the wrong variable.

Principle One: Trust accumulates faster than vulnerabilities. A vulnerability requires a flaw. A trust relationship requires only a decision — and decisions are cheap. Every new SaaS tool, every automation, every agent given "just enough access to get the job done" adds to the surface without anyone writing a CVE about it.

Principle Two: Trust expands through business decisions, not attacks. Nobody hacks their way into your Trust Surface. Marketing connects a chatbot to the CRM. An engineer grants an AI agent broad scope because narrow scope was slower to configure. Trust Surface grows precisely because it looks, from inside every individual team, like ordinary Tuesday work — which is exactly why security rarely gets a vote.

Principle Three: Trust compounds. One OAuth grant enables the vendor behind it to request more scope later. One AI agent spins up a sub-agent to handle a task it wasn't explicitly provisioned for. One integration authorizes five more once the first proves useful. Trust Surface doesn't grow linearly with the number of decisions made — it grows combinatorially with the number of relationships between those decisions.

Principle Four: Trust is inherited. Compromise one identity, and you don't just get that identity's access — you get everything downstream that trusted it. That's the entire Salesloft-Drift mechanism in one sentence: a GitHub compromise inherited into OAuth tokens, inherited into 700 companies' Salesforce data, inherited into whatever secrets those companies had pasted into support tickets.

Principle Five: Trust outlives intent. Someone granted an integration access eighteen months ago for a project that shipped, or didn't. Nobody remembers why the access exists. Nobody owns removing it. The trust persists long after the reason for it is gone — which is precisely the mechanism behind orphaned credentials, the single most common ingredient in non-human identity breaches.

Underneath the Principles, Three Things Have to Be True

Principles describe how Trust Surface behaves. Underneath them sit a smaller set of claims that don't depend on any particular breach, survey, or year — the load-bearing assumptions the rest of the framework rests on:

Axiom One: Trust is never free. It's only ever deferred. Every time a system stops verifying something continuously, it's borrowing certainty against the future. The bill comes due the moment the thing being trusted changes — a vendor gets breached, an employee leaves, an agent's scope quietly widens — and nobody re-checks in time.

Axiom Two: Every automation creates a governance obligation. The convenience of automating a decision doesn't remove the need to own that decision. It just moves the ownership somewhere less visible — usually nowhere at all, which is functionally the same as removing it.

Axiom Three: Every trust relationship eventually becomes infrastructure. A one-off OAuth grant made to solve a temporary problem outlives the problem, gets relied on by something else, and becomes load-bearing before anyone decides it should be. By the time someone notices, removing it looks riskier than leaving it — which is precisely how the riskiest trust relationships survive the longest.

What It's Made Of, and How to Measure It

Trust Surface is a composite, not a single asset class. Call this model the Trust Stack — the layered set of relationships that, together, make up an organization's Trust Surface:

                     THE TRUST STACK

          AI Agents (runtime, self-expanding)
                          │
    OAuth Grants ── Machine Identities ── Secrets & Keys
                          │
    Certificates ── Federation / SSO ── Third-Party Apps

     Every layer is a decision. Every decision compounds upward.

Each layer expands the surface the same way — not through an exploit, but through a decision that's rarely revisited. And because it's a composite, it needs a composite metric, the same way "attack surface" only became durable once it turned into something trackable: exposed services, open ports, unpatched CVEs. A working Trust Surface score tracks, at minimum:

• Orphaned identities — no confirmed owner, no recent activity
• Active OAuth grants per employee, and how many were reviewed in the last 90 days
• Standing permissions versus just-in-time access, as a ratio
• Unrotated secrets older than a defined threshold
• AI agents with write or execute permissions, mapped to what they can actually reach
• Average certificate and token lifetime across the environment
• External integrations with no assigned business owner

None of that data is exotic. Most of it already sits in a secrets manager, an identity provider, or a CASB. What's missing is the discipline to roll it into one number a board reviews as automatically as it reviews vulnerability counts. Confirming the pattern: a 2026 Infrastructure Identity Survey found 70% of organizations grant AI systems more access than they'd give a human doing the identical job, only 44% have any policy governing AI agents, and just 13% call themselves "extremely prepared" for agentic AI — despite 92% agreeing that governing it is critical. That's not a preparedness gap. It's a category error: teams are still asking "who logged in?" when the real question is "what did the agent decide to do, and what could it reach when it decided to do it?"

The Second-Order Consequence Nobody Wants to Say Out Loud

Here's the uncomfortable implication. If Trust Surface keeps growing at its current rate — machine identities compounding, AI agents spawning sub-agents, every integration authorizing the next — Attack Surface starts to matter less. Not because vulnerabilities stop existing, but because attackers increasingly don't need one. Why exploit a flaw when a trusted OAuth token gets you there with no alarm at all? Salesloft-Drift wasn't an edge case; it was a preview. An organization can have a shrinking, well-patched Attack Surface and a metastasizing Trust Surface, and by the metric everyone's already tracking, look like it's winning.

That's a genuinely uncomfortable claim for an industry that's spent two decades building its entire tooling market around Attack Surface Management. It should be debated, not just accepted — but the debate is overdue.

A framework earns the right to be taken seriously when it generates its own vocabulary instead of needing new terms borrowed from elsewhere. Trust Surface does that cleanly: Trust debt for how unmanaged trust compounds into liability, Trust architecture for designing systems that grant it conditionally rather than permanently, Trust observability for the instrumentation layer, Trust decay for permissions that should expire but don't. That's not five separate ideas. It's one model, viewed from five angles — which is usually the sign a concept is structural rather than decorative.

What Actually Closes the Gap

IBM's Cost of a Data Breach research puts the average breach north of $4.9 million once non-human credentials are involved. Rubrik Zero Labs finds two-thirds of enterprises have been breached specifically through a compromised non-human identity, and Obsidian Security's research puts machine identities somewhere in 68% of 2026 security incidents — not as a footnote, but as the entry point.

Closing Trust Surface isn't a new dashboard. It means treating every non-human identity the way a well-run company treats a departing employee: known owner, defined lifecycle, automatic expiry, least privilege by default — plus a runtime layer able to stop an action even when the credential authorizing it is technically valid, because Principle Two means the credential will always look valid right up until it doesn't. Standards are catching up: NIST and CISA jointly released IR 8587 in December 2025, giving federal agencies and cloud providers implementation guidance for securing the tokens behind machine identities and AI agents specifically. The CA/Browser Forum has voted to cut maximum TLS certificate lifespan from 398 days today to 47 days by 2029 — an eightfold increase in mandatory rotation, forced precisely because long-lived trust has become the exploit, not the exception.

Where This Goes

This piece isn't really about OAuth tokens, or AI agents, or even Salesloft. Trust Surface is the proof; the actual claim is bigger and less comfortable: security has spent twenty years measuring the wrong variable. Not the wrong tools, not the wrong budget — the wrong number. Attack Surface tells you how exposed you are to what you haven't yet decided to trust. It has never told you how exposed you are to what you already have.

Firewalls managed the perimeter. Identity managed the individual. Trust is the layer neither one was built to see, and it is the layer growing fastest, because it grows through ordinary business decisions rather than attacks. The next twenty years of security work will be spent learning something harder to instrument and harder to put in front of a board than a patch count: reducing assumptions. Because the modern breach increasingly doesn't begin with something attackers discovered. It begins with something the organization forgot it had already chosen to trust.

The companies that survive this shift won't necessarily run fewer machines than their competitors. They'll be the ones that can say, for every one of them, why it's trusted, who owns that decision, and when it was last checked. Everyone else will find out the way Salesloft's customers did: that a token nobody was watching is still a door nobody locked.

This is the first in a series developing the Trust Surface framework. Next: Trust debt — how unmanaged trust compounds over time into an organizational liability, the same way technical debt does.

Sources cited: Palo Alto Networks 2026 Identity Security Landscape Report; GitGuardian State of Secrets Sprawl Report 2026; Axis Intelligence Machine Identity Statistics 2026; GigaOm/One Identity commentary via The Hacker News (May 2026); SpyCloud 2026 Identity Exposure Report; Google Threat Intelligence Group / Mandiant reporting on the Salesloft Drift breach (Aug–Sep 2025) via The Hacker News, Cloud Security Alliance, and Anomali; 2026 Infrastructure Identity Survey via NHIMG.org; Obsidian Security NHI guide; IBM Cost of a Data Breach report; NIST IR 8587 (Dec 2025); CA/Browser Forum certificate lifecycle vote.