There is a ritual I’ve watched play out in more incident retros than I can count. Someone pulls up the architecture diagram — the one in Confluence, the one that hasn’t been touched since the last audit — and starts tracing boxes. Load balancer. VPC. RDS instance. EKS cluster. Everyone nods because the diagram is comforting. It’s also increasingly a lie of omission.
It doesn’t show the GitHub Action that has write access to three cloud accounts. It doesn’t show the OIDC federation between your CI runner and your production IAM role. It doesn’t show the third-party SaaS chatbot holding a long-lived OAuth token that your sales team connected to Salesforce 18 months ago and forgot about. It doesn’t show any of the things that actually decide whether an attacker gets from “found a bug in a support ticket” to “exfiltrated your customer database.”
That’s because the diagram was never wrong, exactly. It was just answering a question nobody asks anymore. Modern systems don’t fail — or get breached — because a box in a topology diagram went down. They fail because a ‘relationship’ between two identities was more powerful, more persistent or less scrutinized than anyone realized. Call it what it is: A trust graph. Most engineering organizations are troubleshooting the wrong picture entirely.
Put the two pictures side by side and the gap is obvious:
Traditional Diagram Trust Graph
The left-hand diagram tells you where packets travel. The right-hand one tells you where an attacker travels — and increasingly, where a normal Tuesday-afternoon outage travels too. Networks determine where packets go. Trust determines where attackers go. Those used to be roughly the same map. They aren’t anymore, and the distance between them is where every incident in this piece actually happened.
The Diagram Problem
Infrastructure diagrams describe ‘what exists’. They don’t describe ‘what can act on what’. A Kubernetes service account, a Terraform state file with an assumed role, a GitHub Actions workflow with an OIDC trust policy to AWS, an AI agent with a standing API key to your CRM — none of these show up as nodes on a topology map; yet, each one is a live, exploitable edge in the actual system that runs your business.
I’d argue this gap is now the single biggest blind spot in platform engineering, and the numbers back it up. Palo Alto Networks’ 2026 Identity Security Landscape report — the successor to CyberArk’s long-running survey, following the acquisition — puts the ratio of machine identities to human identities at 109 to 1, up from 82 to 1 just a year earlier. Of every 109 machine identities for each human, 79 are AI agents. Other vendors land on different numbers — Veza says 17:1, Entro Labs says 144:1 in cloud-native environments — and the spread itself is the point. Nobody can agree on the ratio, but every measurement agrees on the direction.
None of that would matter much if these identities sat still. They don’t. They authenticate constantly; they hold standing permissions and — this is the part that should keep platform teams up at night — roughly 80% of organizations report having no formal, documented policy for creating or retiring them. We spent a decade building governance around human accounts: Onboarding, offboarding, access reviews, MFA. Then we quietly built a second workforce, 10 to over a 100 times larger, with almost none of that discipline attached.
A Vocabulary for the Thing We’re Actually Looking At
If the trust graph is real, it needs its own language, because ‘IAM’ and ‘network topology’ don’t capture the dynamics that matter operationally.
‘Trust nodes’ are any identity capable of independent action — a service account, a workload identity, a CI job, an AI agent, a webhook integration. Not every node is equally dangerous; what matters is what it’s trusted to do.
‘Trust edges’ are the relationships that let one node act as, or on behalf of, another — an OIDC federation, an assumed IAM role, an OAuth grant, a shared secret baked into a pipeline. An edge is a promise: ‘If you present this credential, I will treat you as authorized’.
‘Trust amplification’ happens when a low-privilege node sits upstream of a high-privilege one. A GitHub Action that seems trivial — say, a file-diffing utility — becomes catastrophic the moment it’s allowed to print CI runner memory into a public log, because that memory contains the actual secrets used downstream. The action itself was never the target. It was the amplifier.
‘Trust bottlenecks’ are the single edges that, once compromised, unlock disproportionate reach — a shared CI bot token used across an entire GitHub organization, or a single SaaS integration connected into every business unit’s Salesforce instance.
‘Trust cascades’ are what happens when an amplifier meets a bottleneck: One compromised edge propagates outward across systems that were never architecturally related, only ‘trust-related’.
These aren’t abstractions. 2025 gave us two textbook cases, back to back.
Case One: The Amplifier
On March 14, 2025, at roughly 9 a.m. Pacific, a popular open-source GitHub Action called tj-actions/changed-files — used in over 23,000 repositories — started quietly printing CI/CD secrets into public build logs. Attackers had retroactively modified multiple version tags to point at a malicious commit, meaning even organizations pinned to a specific release were affected. The compromise ran for roughly 15 hours before GitHub pulled the repository. The vulnerability was assigned CVE-2025-30066.
The forensic trail, pieced together by StepSecurity, Wiz and Palo Alto’s Unit 42, is a near-perfect illustration of trust amplification. Investigators found that the attacker likely first compromised a separate, less-visible action, reviewdog/action-setup, and used a leaked token from that dependency to reach the higher-value tj-actions repository. Unit 42’s later analysis suggested the campaign actually began as a targeted operation against Coinbase’s repositories before the attacker apparently lost that focus and widened the blast radius indiscriminately.
Look at what that means in trust-graph terms. reviewdog/action-setup was a low-privilege trust node — a setup utility, the kind of dependency nobody reviews twice. However, it sat upstream of tj-actions/eslint-changed-files, which sat upstream of tj-actions/changed-files itself, which was a trust edge running inside 23,000 separate CI pipelines. That’s a trust amplifier by definition: A small, boring node whose downstream reach was enormous. Also, because every one of those 23,000 pipelines trusted the same tagged reference, the compromised action functioned as a trust bottleneck — one credential, one repository, one retagged commit — and the blast radius touched every organization that depended on it. No topology diagram would ever have flagged reviewdog/action-setup as load-bearing. On the trust graph, it was one of the most connected nodes in the software supply chain.
Case Two: The Cascade
Five months later, the pattern repeated at a different scale, through a different kind of node: An AI agent.
Between August 8 and 18, 2025, a threat cluster tracked as UNC6395 used stolen OAuth tokens belonging to Salesloft’s Drift — an AI chatbot widely embedded into corporate Salesforce instances for live chat and lead generation — to walk into hundreds of enterprise environments without triggering a single password prompt. Over roughly 10 days, the group ran systematic queries against more than 700 organizations, including Cloudflare, Google, PagerDuty, Palo Alto Networks, Proofpoint and Zscaler, exporting support-case data at scale. Since Drift’s OAuth tokens had been granted broad reach, investigators later found the same stolen credentials also opened doors into Slack, Google Workspace, AWS, Azure and OpenAI accounts connected through the same integration.
The attackers weren’t after Salesforce itself. They were combing exported case text for plaintext AWS keys, Snowflake tokens and VPN credentials that customers had pasted into support tickets — using one trust edge to go fishing for the credentials needed to open the next one. Google put the confirmed toll at over 700 organizations impacted. Fastly, Workday and Toast each independently confirmed exposure and moved to sever the integration and rotate tokens once notified.
Nothing about this incident involved a firewall misconfiguration, an unpatched server or a phished employee clicking a bad link in the conventional sense. It involved one AI agent’s OAuth grant sitting at the center of an enormous number of downstream trust edges — a single node whose blast radius nobody had mapped, because nobody draws a diagram of ‘what a chatbot integration is allowed to touch’.
The Reliability Angle Nobody’s Pricing in Yet
Security teams are (slowly) absorbing this. Reliability and platform teams mostly aren’t, and that’s the second half of the argument. About 10 years ago, an outage was usually a resource problem — CPU, memory, disk, a bad deploy. Increasingly, it has become an authorization problem: An expired workload identity token, a revoked service account nobody flagged as load-bearing, an OIDC trust relationship that silently broke after a provider-side change.
This is the automation paradox in one sentence: The more you remove humans from a deployment pipeline, the more that pipeline’s reliability depends on identity, not infrastructure. A human on-call engineer can route around a broken dependency. An automated pipeline authenticating via a dead workload identity just fails, silently, at 2 a.m. and the postmortem reads like a security incident even though nothing was ‘hacked’. The OWASP Foundation formalized this shift in its 2025 Non-Human Identities Top 10, codifying failure modes — improper offboarding of retired service accounts, secret leakage into logs and repos, insecure machine-to-machine authentication — that read like an SRE runbook as much as a security framework, because at this point, they’re the same document.
The scale of what’s now ungoverned is the part that should reframe how platform teams prioritize. GitGuardian’s 2026 State of Secrets Sprawl report found 28.65 million hardcoded secrets added to public GitHub repositories in 2025 alone — a 34% jump year over year, the largest single-year increase on record — with AI-service-related leaks specifically up 81.5%. Of the secrets confirmed live back in 2022, roughly 64% remain exploitable as of this January — meaning most organizations aren’t just failing to prevent new exposure, they’re failing to clean up exposure they already know about.
What This Actually Changes About the Job
If you accept that the trust graph is the real architecture, a few practical things follow and none of them are “buy another dashboard.”
First, threat modeling has to include CI/CD dependencies as first-class production infrastructure, not developer tooling. reviewdog/action-setup wasn’t a footnote; it was the entry point. Every transitive action, every third-party GitHub App, every Terraform module pulled from a public registry is a trust edge with the same blast-radius potential as a misconfigured security group — arguably more, because almost nobody reviews it with the same rigor.
Second, every SaaS integration and AI agent needs an owner and a documented scope, the same way a production database needs one. “We connected Drift to Salesforce for lead routing” is a perfectly reasonable business decision. “Nobody remembers what data Drift can touch, or that its OAuth token never expires” is the actual vulnerability, and it’s a governance failure, not a technical one.
Third — and this is the harder cultural shift — reliability engineering and identity security need to stop being separate disciplines with separate tooling and separate on-call rotations. An expired workload identity that breaks a deployment pipeline and a stolen OAuth token that exfiltrates customer data are the same category of failure: A trust edge that behaved in a way nobody had modeled. Treating one as an SRE problem and the other as a SOC problem guarantees blind spots exactly where the two disciplines don’t talk to each other.
The old diagram isn’t wrong. It’s just describing a system that stopped being the whole story around the time OIDC federation, service meshes and autonomous agents became normal. The graph that actually determines whether your organization has a good week or a very bad one is the one made of trust edges — and right now, almost nobody is drawing it, reviewing it or putting an owner’s name on it. That’s not a tooling gap. It’s an architecture gap, and it’s the one worth arguing about in 2026.