Part Three: Deep Dive
Block 40

Token Authority vs Relational Trust

Every time you click “Login with Google,” you're participating in a specific philosophy of trust. Understanding that philosophy — and its limits — is essential for governing agentic systems.

How OAuth Works

OAuth is delegated authorization. Instead of giving an app your password, a trusted authority (Google, Microsoft, etc.) issues a limited-use token on your behalf. The app never sees your credentials. It gets a valet key that only opens what you approved.

The flow:

  1. App redirects you to the authority
  2. You authenticate and approve specific permissions (scopes)
  3. Authority issues a bearer token
  4. App uses the token to access resources
  5. Done

OpenID Connect (OIDC) adds authentication on top: not just “what can this app do?” but “who is this person?” Together, they're the backbone of modern identity on the web.

And they encode a very specific trust model.

The Trust Model Inside OAuth

PropertyHow OAuth handles it
Source of trustCentral authority (Google, Microsoft)
RepresentationBearer token — if you have it, you're authorized
Time dimensionStateless snapshot (“valid right now”)
GranularityPredefined scopes (“read email,” “access profile”)
RevocationCentralized kill switch
Behavioral memoryNone — token doesn't know how the entity has behaved

Five words capture the philosophy: trust is granted, not earned. You authenticate once. The authority issues a token. Every system that receives that token treats it as proof of authorization. No questions asked about behavior, history, or context.

Where This Breaks

The Vercel breach (April 2026) is the textbook case. An employee connected a third-party AIArtificial IntelligenceSystems that learn, adapt, and act with real-world impact tool to their Google Workspace via OAuth. The tool was compromised. The attacker used the OAuth trust relationship to pivot from the tool into the employee's Workspace, then into Vercel's infrastructure, then into customer data.

Every system along that chain did exactly what OAuth says to do: received a valid token, checked the scopes, granted access. The token was legitimate. The authorization was legitimate. The entity holding the token was an attacker.

OAuth can't distinguish between a legitimate holder and an attacker holding a legitimate token. It doesn't ask. The token IS the trust. There's nothing else to check.

What Relational Trust Looks Like

Web4Web4Open governance ontology for trust-native entity interactions inverts the model. Trust is not a token issued by an authority. Trust is a continuously computed assessment based on observed behavior, accumulated history, and contextual relevance.

PropertyOAuthWeb4
Source of trustCentral issuerDistributed, composable trust graph
RepresentationBearer token (opaque)LCTLinked Context TokenAn entity's witnessed presence — permanent, non-transferable, cryptographically anchored (linked, evolving, inspectable)
TimeStateless snapshotTemporal continuity — history matters
GranularityPredefined scopesContextual MRHMarkov Relevancy HorizonFractal context scoping — defines where governance applies-based evaluation
RevocationCentralized kill switchTrust decay from observed behavior
Behavioral memoryNoneT3Talent / Training / TemperamentThree-dimensional trust measurement, role-contextual, with decay trust tensor evolving from every interaction

The core shift: OAuth asks “did Google say this is okay?” Web4Web4Open governance ontology for trust-native entity interactions asks “given everything known about this entity across contexts, does this action align?”

The Vercel Breach Under Relational Trust

Replay the same attack against a trust-native architecture:

  1. Employee connects a third-party tool. The connection creates an LCTLinked Context TokenAn entity's witnessed presence — permanent, non-transferable, cryptographically anchored relationship with a trust ceiling determined by the tool's anchor type (software-only = 0.4 out of 1.0). The tool can read calendar events; it cannot pivot into infrastructure. The ceiling is architectural, not a checkbox.
  2. Tool is compromised. The attacker uses it to access resources the tool never accessed before. The T3Talent / Training / TemperamentThree-dimensional trust measurement, role-contextual, with decay profile flags the behavioral deviation immediately — not as a SIEM alert, but as a routine trust update. Novel behavior degrades trust. Degraded trust restricts capability. Restricted capability limits blast radius.
  3. The attacker's access is structurally bounded. Even if the token is valid, the trust is not. The system distinguishes between a legitimate token and a legitimate entity — because trust is relational, not transactional.

OAuth as Bootstrap, Not Authority

OAuth doesn't disappear in this model. It becomes a bootstrap layer — the initial handshake that establishes a connection. Then relational trust takes over:

  • Layer 1 (existing world): OAuth, APIs, centralized identity — what we have today
  • Layer 2 (bridge): OAuth tokens ingested as one input signal into trust computation — not treated as authority
  • Layer 3 (native): LCTLinked Context TokenAn entity's witnessed presence — permanent, non-transferable, cryptographically anchored-first interactions where trust is independent of the original issuer

The OAuth token goes from being the answer to being one piece of evidence. A high-quality piece — but weighted by context, not absolute.

The Fundamental Break

OAuth assumes trust must be decided before interaction. Relational trust allows trust to be refined through interaction.

OAuth scales access. Web4Web4Open governance ontology for trust-native entity interactions scales accountability, context, and coherence.

OAuth is transactional trust: valid token, valid access, end of story. Web4Web4Open governance ontology for trust-native entity interactions is relational trust: every interaction is a signal, signals accumulate, coherence emerges — or doesn't.

When it doesn't, the system notices. Not because an alert was configured. Because that's what trust measurement does.