============================================================ nat.io // BLOG POST ============================================================ TITLE: Every System Is a Trust Graph DATE: March 12, 2026 AUTHOR: Nat Currier TAGS: Security Architecture, Distributed Systems, Identity, Governance ------------------------------------------------------------ Every security architecture is a trust graph, whether teams model it or not. Principals, services, devices, and data stores form nodes, while authentication, authorization, and delegation relationships form edges. Most security programs still describe controls as isolated layers: IAM, network, endpoint, secrets, compliance. That decomposition is useful for ownership, but it can hide interaction risk. Incidents rarely follow one control domain at a time. They propagate across edges that connect domains. Graph thinking helps teams see this propagation early. If a compromised workload can assume another role, call a control-plane API, and modify policy in one flow, that path is the real attack surface regardless of how many independent controls look healthy in dashboard isolation. The value of the trust-graph model is operational, not academic. It enables better architecture reviews, clearer privilege minimization, faster incident scoping, and more realistic governance decisions. It also creates a shared language between engineering and leadership. Graph paths make risk concrete. Instead of debating abstract severity labels, teams can point to reachable paths from compromised principals to high-impact actions. That clarity improves prioritization and reduces the gap between technical findings and executive decisions. > **Thesis:** Security risk lives in relationship paths, not isolated controls. > **Why now:** Distributed systems increased edge count and delegation complexity beyond linear threat models. > **Who should care:** Security engineers, platform teams, architects, and leadership responsible for systemic risk. > **Bottom line:** Model and manage trust edges explicitly, or incidents will map your graph for you. [ Key Ideas ] ------------------------------------------------------------ - Nodes represent actors and resources; edges represent trust semantics. - Delegation edges are high-leverage risk amplifiers. - Least privilege means constraining graph paths, not just role definitions. - Incident response improves when teams can trace reachable trust paths quickly. - Governance decisions should target graph-risk concentration, not only control checklists. This is the continuation of [Authorization Is the Hardest Problem in Security](/blog/authorization-is-the-hardest-problem-in-security). Read it before this one, then continue to [The Multi-Decade Cryptography Migration](/blog/multi-decade-cryptography-migration). [ Nodes: what belongs in the trust graph ] ------------------------------------------------------------ A practical trust graph starts with concrete node classes: It should include human principals such as employees and contractors, machine principals such as services and jobs, devices and runtime environments, control-plane components, and protected resources such as data stores and key systems. Each node class has different identity and policy semantics. Human nodes include workforce lifecycle events. Workload nodes include deployment and runtime metadata. Resource nodes include classification, tenancy boundaries, and action sensitivity. If these distinctions are collapsed, graph analysis becomes noisy and less actionable. Precision at node definition is what makes path analysis useful. [ Edges: trust semantics are the real policy language ] ------------------------------------------------------------- Edges should encode the actual trust relationship, not generic "connects to" metadata. Common edge types include: authentication edges where a principal proves identity, authorization edges where a principal is allowed to perform an action on a resource, delegation edges where authority is transferred, transitive execution edges where one service acts on behalf of another, and policy-mutation edges where a principal can change trust rules. Delegation and policy-mutation edges deserve special attention. They can change graph structure at runtime and often create nonlinear blast-radius growth. In my experience, teams document authentication edges more consistently than delegation edges. That gap creates false confidence because the most damaging incidents often involve delegated privilege misuse. [ Why linear control checklists miss graph risk ] ------------------------------------------------------------ Control frameworks typically ask whether specific safeguards exist. Graph risk asks whether dangerous paths remain reachable despite those safeguards. Both views matter. The problem appears when checklist completion is mistaken for path safety. Consider this simplified path: A low-privilege CI worker role is compromised. That worker can assume a deployment role because of an overly broad trust policy. The deployment role can update production service configuration. The updated configuration then enables data export capability. Each step may satisfy an individual control requirement, yet the path still enables serious impact. Graph analysis surfaces this by evaluating composability of permissions, not just local control posture. [ Trust graphs make least privilege measurable ] ------------------------------------------------------------ Least privilege is easier to reason about when phrased as path constraints. Instead of asking "does this role look broad," ask: Which high-value nodes become reachable if this node is compromised, how many hops are required, which edges involve delegation or policy mutation, and which paths bypass normal approval workflows. This framing supports quantitative risk signals such as privileged path count, shortest critical path length, and delegation density. Those metrics are imperfect, but they are more actionable than role inventories alone. | Graph metric | What it indicates | Why it matters | | --- | --- | --- | | Critical path count | Number of routes to sensitive nodes | Higher count means more attack options | | Delegation density | Frequency of authority transfer edges | High density increases transitive risk | | Policy-mutation reachability | Who can change trust rules | Indicates governance fragility | | Cross-tenant edge count | Tenant boundary exposure | Signals isolation weakness | [ Incident response gets faster with graph-first triage ] --------------------------------------------------------------- During incidents, time is lost when teams cannot rapidly answer "what else can this principal reach?" Graph-backed response playbooks reduce this delay. A graph-first triage loop is straightforward: Identify the compromised node and credential lineage, enumerate immediate outbound trust edges, expand reachable paths to sensitive nodes, prioritize containment at high-centrality edges, and then re-run reachability after each containment action. This workflow shifts incident response from static asset inventory to dynamic relationship containment. Without graph visibility, teams often over-contain entire environments because they cannot separate likely propagation paths from low-risk adjacency. [ Delegation is the most under-governed edge class ] ------------------------------------------------------------ Delegation is operationally necessary. Humans delegate to automation, services delegate to downstream services, and control planes delegate execution authority. The issue is not delegation itself. The issue is undocumented delegation growth. Delegation risk compounds when: grants are broad and long-lived, chains are difficult to inspect, revocation impact is unpredictable, and ownership for delegation review is unclear. The corrective pattern is explicit delegation contracts: who can delegate, to whom, for what scope, for what duration, with what audit obligations. Treat delegation like code change control, not a convenience feature. [ Walkthrough: mapping trust edges in a SaaS control plane ] ------------------------------------------------------------------ In the canonical SaaS system, trust graph mapping revealed that a background reconciliation service could assume a maintenance role intended only for break-glass operations. That edge existed because of a historical migration script and survived long after the migration ended. No single control failed. The path failed. Once the graph was mapped, remediation was precise: The team removed the stale assume-role edge, split the maintenance role into read and write variants, required an explicit approval token for write operations, and added policy linting for delegation anomalies. The fix was less expensive than broad network lockdown and produced measurable blast-radius reduction. [ Designing graph maintenance into daily operations ] ------------------------------------------------------------ Graph models only stay useful if they are continuously refreshed. Static diagrams decay as quickly as architecture slides. Practical programs tie graph data updates to deployment events, IAM policy changes, and service onboarding workflows. This creates a living model rather than a quarterly snapshot. Teams also need decision-grade outputs, not only visualization. Good graph programs produce alerts for new high-risk delegation edges, reports on critical-path growth, and review queues for policy-mutation reachability changes. These outputs connect graph analysis directly to engineering actions. In production environments, this integration often starts small. One team maps control-plane privilege paths first, then expands into tenant-boundary paths and automation identities. The scope can scale over time, but the operating principle remains constant: trust relationships are part of runtime architecture and should be monitored with the same rigor as reliability signals. [ Practical limits and how to handle them ] ------------------------------------------------------------ One objection is that graph models are too complex to maintain. They can be if built as one giant static map. Practical implementations focus on high-value domains first: identity, policy mutation paths, and sensitive data access. Another objection is data quality. Relationship data is often inconsistent across systems. That is true, but imperfect graph models are still useful if they prioritize high-confidence edges and iterate coverage over time. A third objection is tooling cost. You do not need perfect graph databases to start. Teams can begin with relationship exports and targeted path analysis around critical assets. [ Starting without a dedicated graph platform ] ------------------------------------------------------------ Teams often delay graph work because they assume they need a full graph database from day one. In practice, many programs start with periodic exports from IAM, service registry, and policy systems joined in lightweight analysis jobs. The first goal is not completeness. It is visibility into critical trust paths that are currently implicit. A pragmatic starter scope is to map principal-to-role delegation, role-to-resource authorization, and policy-mutation permissions for high-value systems. Even this limited model usually surfaces surprising transitive paths. As confidence grows, teams add richer context such as tenant boundaries, environment tags, and runtime behavior signals. This incremental approach keeps graph work aligned with operational outcomes. Instead of building a large abstract model, teams build decision support for concrete engineering questions: what can this compromised principal reach, which path should be cut first, and where does ownership need to change. [ Example trust graph ] ------------------------------------------------------------ ```mermaid graph TD U["User"] -->|"auth"| APP["App Service"] APP -->|"delegation"| JOB["Worker Job"] JOB -->|"assume role"| CP["Control Plane"] CP -->|"policy update"| IAM["Policy Store"] IAM -->|"authorize"| DB["Sensitive Data Store"] ``` [ Why this matters for cryptography migration ] ------------------------------------------------------------ When you model security as a trust graph, hidden propagation paths become visible engineering work instead of surprise incident narrative. The next essay examines one domain where this graph perspective is especially important: cryptography migration that spans years or decades across heterogeneous infrastructure.