Why Graphs Matter: A Simple Model for Complex Org Reality

The Problem with Single-Dimension Security

Most security and identity platforms operate in isolation. They ingest data from a single source, such as an IDP like Okta or Microsoft Entra ID, a cloud provider like AWS, an HR system like Workday, and produce findings based only on what that one system can see. The result is a flat, row-based view of reality: one account, one status, one recommendation.

This approach worked when enterprises had a handful of systems. It breaks down when a single human identity can span dozens of platforms, own applications and certificates, access sensitive data, provision other accounts, and carry dependencies that ripple across the organization. An insight that looks correct in one platform’s silo can be dangerously wrong when you factor in the full picture.

There's a fundamentally different approach: building a context graph that reflects reality across every connected platform. In this post, I want to walk through why that matters, through concrete scenarios that security teams encounter every day. Throughout the examples, I'll share how we've implemented this approach at Surf.

Row-Based Models vs. Context Graphs

A row-based model is essentially a spreadsheet view of your environment. Each row represents an account or resource on a single platform. You can filter, sort, and flag, but you can’t trace connections. You can’t answer questions like: “If I disable this account, what else breaks?” or “Is this account truly inactive, or is the person behind it active somewhere else in the org?”

A context graph, by contrast, connects entities across platforms. Accounts, identities, applications, certificates, permissions, provisioning relationships, and activities all become nodes and edges in a unified structure with edges that capture not just the existence of a relationship, but its nature, direction, and frequency. When Surf AI connects to your IDP, your cloud environments, your HR systems, your SaaS tools, and your security systems, it is not just collecting rows of data, it builds a living, multi-dimensional map of how everything relates.

This is the difference between seeing a single data point and understanding a system. And it’s the foundation that makes accurate, automated security decisions possible.

Example: The Dormant Account That Isn’t

Consider a common goal in identity security: cleaning up dormant accounts. In a traditional, single-platform model, the logic is simple. If a user hasn’t logged into their Okta account for 60 days, flag it as dormant. Recommend disabling it.

But what happens when we look at the full graph?

Suppose the user’s Okta account has been idle for two months, but their GCP account, provisioned through Okta, shows daily activity. The person is clearly active; they just haven’t needed to log into Okta directly. A single-platform view would generate a dormant account finding. The context graph recognizes that the underlying subject is active and that a provisioning relationship links the two accounts. Disabling the Okta account wouldn’t just remove an unused credential, it could break the user’s access to GCP entirely.

This is a textbook false positive: a finding that looks correct in isolation but is wrong when you have the full context. Multiply this across hundreds or thousands of accounts, and you begin to see why single-dimension tools generate so much noise and why security teams learn to distrust their own automation.

Example: The Ripple Effect of Disabling an Account

Perhaps the most powerful illustration of why graphs matter is what we call the ripple effect: understanding the downstream consequences of a security action before you take it.

Let's return to the dormant account scenario, but add cross-platform complexity. Imagine a user whose identity account is dormant, but who also owns a device registered in your endpoint management platform. That device hosts a production server managed through a separate infrastructure platform. In a single-platform view, the dormant identity looks like a straightforward cleanup target. But the graph reveals that disabling this user's account could revoke access to the device, potentially causing downtime for a production service that lives in an entirely different system.

Now add another dimension. A second administrator also has access to that device and the production server it hosts. If both administrators are dormant, the cleanup recommendation holds, the server's ownership chain is effectively broken, and remediation is appropriate. But if the second administrator is active, the picture changes entirely. The production server is still maintained, the device is still managed, and the first user's dormancy doesn't justify any action that could disrupt the service.

These are three distinct scenarios, same dormant account, same application, but three different correct actions depending on the context. A row-based model sees one account and one status. The graph sees the full web of ownership, access, and activity, and can model what happens when you pull on any single thread.

Example: Identifying the Right Owner for a Security Task

One of the most common friction points in security operations is figuring out who should act on a finding. A traditional platform might flag an issue on an account and assign it to whoever is listed as the account owner in that system. But that person may have changed roles, left the team, or never been the right contact in the first place.

A graph-based approach resolves this by tracing ownership across systems. Starting from the flagged account, the graph can follow edges to the underlying subject, then to their manager, their team, their role, and other accounts they own. If the original owner is unavailable, the graph can identify the next-best stakeholder, perhaps a team lead who owns related resources, or a colleague who shares access to the same application.

This is task ownership identification, and it's only possible through completeness: assembling the full picture of an entity by pulling together pieces from various sources: HR systems, identity providers, cloud platforms, and application access logs. Each system holds a fragment of ground truth. The graph connects those fragments into a complete view that reveals not just who owns an account on paper, but who has the real context and authority to act on it. Without this completeness, you're making security decisions based on incomplete puzzles.

The Bottom Line

Security automation has been held back by a business context problem, not a tooling problem. The tools exist to respond to security alerts, remediate findings, and improve overall posture. What’s been missing is the context to know when those actions are safe, necessary, and complete.

Graph-based representations solve this by making relationships, dependencies, and influence paths first-class citizens in the data model. They turn isolated data points into connected intelligence and they’re the reason Surf AI can automate security posture decisions with the confidence that a human analyst would demand.

If you’re evaluating how to bring automation into your security operations, the first question to ask isn’t which actions the platform can take. It’s how well the platform understands the reality it’s acting on.