Knowledge graph security: row-level permissions across systems

In this article

• Why permissions get harder, not easier, when systems combine
• How permissions travel from source systems into a graph
• The flattening risk
• Role scoping, row scoping, and attribute scoping
• Tenant isolation in a shared platform
• Read-only access as a security boundary
• Where AI inference fits into the security model
• Where SIGNLD fits
• FAQ

Why permissions get harder, not easier, when systems combine

Inside a single system, permissions are usually well understood: a CRM restricts which reps see which accounts, an ERP restricts which employees see which financials, a support tool restricts tickets to the team that owns them. The moment a graph joins entities across these systems, a question that touches an Account, an Invoice, and a Ticket at once now has to satisfy three separate permission models simultaneously, and the person asking the question may only be entitled to see some of what the answer draws on.

For the wider context, see our knowledge graph glossary of 40 terms.

This is not a hypothetical edge case, it is the normal condition of any cross-system question. A regional sales manager who can see their region's accounts in the CRM should not suddenly gain visibility into another region's financial detail just because a graph traversal happened to connect through it while answering a broader question. The graph has to know this and enforce it at the same granularity the source systems did, not at some coarser level that is easier to build but less safe to use.

How permissions travel from source systems into a graph

A knowledge graph that takes permissions seriously reads entitlements from each source system alongside the data itself: who can see which accounts, which records, which fields, and under what role. Those entitlements attach to the corresponding nodes and edges in the graph, so that when a question is answered, the system checks the requesting user's inherited entitlements against every piece of evidence the answer would draw on, not just against a single top-level permission on the whole dataset.

This inheritance has to be kept current, not captured once at connection time and left static. Source system permissions change constantly, an employee changes role, a rep gets reassigned to a different territory, a contractor's access expires, and a graph with stale inherited entitlements becomes a security gap that looks, from the outside, like the graph is working correctly.

The flattening risk

The most serious security failure mode for a knowledge graph is not a breach from outside, it is flattening: combining data from multiple systems into a single unified structure and, in the process, losing the granular permission boundaries each system enforced on its own. A graph that flattens access might expose all financial detail to anyone who can query it at all, because the unification work merged the data but never carried the entitlement logic along with it.

Flattening tends to happen for an understandable but dangerous reason: enforcing fine-grained permissions across a merged, cross-system structure is genuinely harder engineering than enforcing them within a single system's own schema, so a team under deadline pressure sometimes ships a simpler, coarser permission model and treats it as a temporary shortcut. The risk is that a coarse model does not look broken in normal use, it looks broken only when someone who should not see something asks the right question, which is precisely the scenario a business knowledge graph exists to make easy.

Role scoping, row scoping, and attribute scoping

Permission enforcement in a graph context works at three levels of granularity, and a mature system needs all three, not just one.

Role scoping restricts access based on a user's role or group membership, the equivalent of "sales reps see accounts, sales reps do not see payroll." This is the coarsest level and the easiest to implement, but on its own it cannot express "this rep sees their own accounts but not another rep's," which is a row-level distinction.

Row scoping restricts access to specific records within a type the user's role otherwise has access to, matching how most CRMs and ERPs already enforce territory or ownership-based visibility. A graph needs to preserve this distinction when it merges accounts from a CRM into the broader graph structure, so that a rep's role grants them access to the Account entity type in general, while row scoping still limits them to their own accounts specifically.

Attribute scoping goes a level deeper, restricting visibility to specific fields on a record a user can otherwise see. A support agent might be allowed to see that a customer has an open invoice without being allowed to see the invoice amount, a common requirement in regulated or finance-sensitive contexts. A graph without attribute-level scoping either has to withhold the entire record, which breaks legitimate use cases, or expose the sensitive field, which breaks security.

Tenant isolation in a shared platform

For any knowledge graph platform serving more than one customer, tenant isolation is a separate and equally important boundary: one customer's graph, data, and inferred ontology must be fully separated from every other customer's, with no shared storage or processing path that could allow data to cross between tenants. This matters independently of row and attribute scoping within a single company's graph, because it addresses a different question, not "which employee at this company can see which record," but "can anything belonging to one company ever be visible to a different company on the same platform."

Tenant isolation should be verifiable, not just claimed, which is why independent controls frameworks like SOC 2 Type II exist: they require an auditor to test that the isolation and access controls a vendor describes are actually implemented and operating over time, not just documented in a policy.

Read-only access as a security boundary

One of the simplest and most effective security decisions a knowledge graph platform can make is connecting to source systems in read-only mode. A read-only connection can retrieve data to build and update the graph, but it cannot write back to the source system, create records, modify records, or delete them. This removes an entire category of risk, a compromised or misconfigured connection cannot alter a customer's CRM, ERP, or financial system, because the connection was never granted the ability to write in the first place. It is a boundary enforced by the nature of the connection itself, not by a policy that could be misconfigured or bypassed.

Where AI inference fits into the security model

Once a graph feeds answers through an AI layer, the security question extends to how that inference runs. Two things matter here specifically. First, whether inference runs on shared, multi-tenant infrastructure or on infrastructure isolated to a single customer, since a single-tenant deployment removes any possibility of another customer's queries or context leaking into the model's processing for this one. Second, whether the model is trained on customer data at all. A model that is never trained on customer data cannot memorize and later surface fragments of one customer's information to another, which is a different and more precise guarantee than vague claims about data never leaving an environment. Neither of these should be confused with a claim that no data ever leaves a customer's own infrastructure, which is a distinct and much stronger claim that most knowledge graph platforms, including ones built on cloud AI infrastructure, are not making and should not make.

Comparison: permission scoping levels

Scope level	What it restricts	Source system analogy	Failure mode if missing
Role scoping	Access to entire entity types	Department or job-function permissions	Everyone in a role sees everything that role touches, no finer control
Row scoping	Access to specific records within a type	Territory or ownership-based CRM visibility	Users see records belonging to peers, not just their own
Attribute scoping	Access to specific fields on a visible record	Field-level masking in finance systems	Sensitive fields exposed on records a user is otherwise entitled to see
Tenant isolation	Separation between different customer organizations	N/A, platform-level concern	One company's data becomes reachable from another company's account

Where SIGNLD fits

SIGNLD connects to source systems in read-only mode across 800+ integrations, so connections retrieve data without ever gaining the ability to write back to a customer's CRM, ERP, or other systems. Tenant isolation separates each customer's knowledge graph and data fully from every other customer's, and this is backed by SOC 2 Type II controls that are independently audited rather than self-asserted. AI inference runs on a single-tenant AWS Bedrock instance, isolated to each customer, and the underlying models are never trained on customer data. SIGNLD does not claim zero egress or that data never leaves the customer's environment, because that would not be an accurate description of how a cloud-based AI platform operates, and accuracy here matters more than a stronger-sounding claim. Full detail is at /security.

Related reading in this series: Knowledge graph vs master data management and Knowledge graph vs vector database for business questions.

Key takeaways

• Inside a single system, permissions are usually well understood: a CRM restricts which reps see which accounts, an ERP restricts which employees see which financials, a support tool restricts tickets to the team that owns them.
• The most serious security failure mode for a knowledge graph is not a breach from outside, it is flattening: combining data from multiple systems into a single unified structure and, in the process, losing the granular permission boundaries each system enforced on its own.
• One of the simplest and most effective security decisions a knowledge graph platform can make is connecting to source systems in read-only mode.
• Row scoping controls which specific records a user can see within a type they otherwise have access to, like a rep seeing only their own accounts.
• SOC 2 Type II requires an independent auditor to test that described controls, including tenant isolation and access management, are actually operating correctly over an extended period, not just documented as policy.

FAQ

Does a knowledge graph automatically inherit source-system permissions?

Not automatically in a naive implementation. Inheriting permissions correctly requires the platform to read entitlement data from each source system alongside the actual records, and to keep that entitlement data current as roles and access change. A graph that only imports data without importing the corresponding permissions will flatten access by default.

What is the difference between row scoping and attribute scoping?

Row scoping controls which specific records a user can see within a type they otherwise have access to, like a rep seeing only their own accounts. Attribute scoping controls which fields on a record a user can see, allowing a user to see that a record exists without seeing every field on it, such as a specific dollar amount.

Is read-only access enough to make a knowledge graph secure?

Read-only access removes the risk of a connection modifying source data, which matters, but it does not by itself solve permission inheritance, tenant isolation, or AI infrastructure isolation. All of these are separate controls that address different parts of the security model and are needed together.

What does single-tenant AI inference actually protect against?

It ensures that one customer's queries and data context are processed on infrastructure isolated from every other customer's, removing the possibility of cross-customer leakage at the inference layer. It is a narrower and more verifiable claim than saying data never leaves a company's own environment.

Why does SOC 2 Type II matter more than a vendor's own security description?

SOC 2 Type II requires an independent auditor to test that described controls, including tenant isolation and access management, are actually operating correctly over an extended period, not just documented as policy. It converts a vendor's claims into something a customer's security team can verify.

Try SIGNLD free to see permission inheritance and tenant isolation in practice, or see how it works. Related terms are covered in the knowledge graph glossary.