The argument, up front

Thesis

An enterprise graph unifies data of many sensitivities into one connected, reasoning surface. So you cannot rely on each source’s own security — the moment the data is joined and inferred over, new exposure appears that no source could see. Security, access control and privacy have to be first-class parts of the graph’s design, enforced at the graph, not just under it.

Three disciplines, easily confused, must all be present. Security protects the platform and the data — authentication, encryption, audit. Access control decides who may do what to which part of the graph. Privacy governs personal data specifically — minimization, purpose, consent, and the rights of the people the data describes. This brief takes each in turn, and focuses on what makes a graph harder than a table.

01 — WHY A GRAPH IS DIFFERENT

Four properties that make it harder

Row-and-column security assumptions break on a knowledge graph. Four of its defining traits are exactly the traits that complicate protecting it.

aggregation

The whole exceeds the parts

Facts that are each harmless can combine into something sensitive — a mosaic. A graph is built to combine, so it manufactures exposure that no single source contained.

inference

You can derive what you can’t see

A reasoner turns permitted facts into new ones. If a sensitive fact is entailed by facts you allowed, you have effectively disclosed it — access control must cover the inferred graph, not only the asserted one.

granularity

Protection must reach a single fact

Sensitivity lives at the level of one statement, and connectivity leaks: even a hidden node can be exposed by the edges that point at it. Coarse, table-level controls are not enough.

federation

Enforcement spans layers

In a virtualized graph, a query is answered from live sources. Security must hold at the graph layer and propagate down to each source — or the graph becomes a hole straight through them.

02 — THREE PILLARS

Security, access control, privacy

Keep the three distinct — they need different owners, controls and evidence — even though they reinforce each other.

Pillar 1

Security — protect the platform & the data

Authenticate every principal, encrypt in transit and at rest, manage keys and secrets, harden the endpoints, and log every access to an immutable audit trail. The floor everything else stands on.

Pillar 2

Access control — who may do what, to which slice

Authorization at graph granularity: from whole datasets down to a single triple, decided by roles, attributes, relationships or classification labels, and enforced at every query.

Pillar 3

Privacy — govern personal data specifically

Lawful basis, purpose limitation, data minimization, de-identification, consent, and the rights of data subjects — including the hardest one, erasure. Access control is necessary but not sufficient for privacy.

03 — AUTHENTICATION & IDENTITY

Carry the real principal all the way down

Before you can authorize, you must know who is asking — and keep knowing it through every layer. Users authenticate with OIDC / OAuth2 / SAML; services and pipelines with mutual TLS or workload identity; automated agents (including LLM-driven ones) get their own first-class identities, never a human’s.

The super-user pitfall

The most common — and most dangerous — mistake in a federated graph is to query every source through one privileged service account. The graph then bypasses all the source-level security beneath it, and every user sees everything the graph can reach. Propagate the end-user’s identity (token exchange, delegation) so each source enforces its own controls against the real principal. Identity that stops at the graph’s front door is no identity at all.

04 — ACCESS CONTROL

Models and granularity

Two decisions define access control: how fine the unit of protection is, and by what logic a decision is made.

The granularity ladder

Pick the coarsest level that meets the need. Named graphs — one per source or sensitivity tier, granted as a unit — are the default boundary. Drop to predicate or statement level only where a real requirement demands it, because the cost of evaluating and maintaining fine-grained rules is real.

The decision models

Model	Decides by	Fit for a graph
RBAC	the subject’s roles	Simple, coarse baseline — roles granted named graphs
ABAC	attributes of subject, resource, action & context	Fine-grained and flexible; scales to many nuanced rules
ReBAC	relationships in the graph itself	Natural fit — “see records connected to your team” is a traversal
Label / MAC	classification labels vs. clearances	Strong for sensitivity tiers and compartmentalization
Policy-as-code	externalized policy (OPA, XACML, ODRL)	Testable, auditable, versioned; decouples policy from the engine

How enforcement actually happens

Named graphs as the boundary. Partition by source and sensitivity; grant read/write per graph. Coarse, fast, and enough for most needs.
Query rewriting / result filtering. The endpoint injects constraints so a principal only ever sees permitted triples — the graph equivalent of row-level security.
Classification labels. Tag resources or statements (public / internal / confidential / restricted) and check them against the principal’s clearance.
An authorization graph. Model policies as data — who may do what, to which slice, for which purpose — and evaluate them at query time.

@prefix odrl: <http://www.w3.org/ns/odrl/2/> .
@prefix ex:   <https://example.org/> .

# Policy as data: a role may READ one named graph, for one purpose.
ex:policy/support-read a odrl:Policy ;
  odrl:permission [
    odrl:assignee ex:role/SupportAgent ;          # who
    odrl:action   odrl:read ;                       # what
    odrl:target   ex:graph/customer-contacts ;      # which slice
    odrl:constraint [
      odrl:leftOperand  odrl:purpose ;
      odrl:operator     odrl:eq ;
      odrl:rightOperand ex:purpose/CustomerSupport ] ] .   # for what purpose

05 — THE HARD PART

Inference and aggregation

This is where graph security genuinely departs from everything else. Controlling access to the triples you stored is not the same as controlling access to the facts a user can obtain.

You cannot protect a fact you let someone derive

If a restricted conclusion is entailed by facts a principal may read, filtering the conclusion alone achieves nothing — they can re-derive it. Decide deliberately whether reasoning runs before or after authorization, and treat inferred triples as at least as sensitive as their inputs. Secure the inference pipeline, not just the store.

aggregation / mosaic

Small answers, large disclosure

Many low-sensitivity results combine to reveal a protected whole. Mitigate with query auditing, volume and rate limits, minimum-count thresholds on aggregates, cell suppression, and noise for statistics.

re-identification

Structure betrays identity

“Anonymized” nodes are re-identified through their edges and quasi-identifiers — the same connectivity that powers entity resolution powers attack. Generalize, apply k-anonymity thresholds, and test against re-identification before you publish.

06 — PRIVACY & PERSONAL DATA

Governing the data about people

Access control keeps the wrong people out; privacy governs what may exist and be done at all. It starts with knowing where personal data is in the graph — which classes and predicates carry it — and classifying accordingly.

The principles, applied to a graph

Minimize. Don’t ingest or materialize personal data you have no purpose for — every copy is a liability, and a graph copies eagerly (inference, caching, materialized views).
Bind to purpose. Record the purpose and lawful basis for holding data, and check queries against it — purpose can be modeled as data and enforced at access time.
Limit retention. Expire and delete on schedule; a graph with no forgetting accumulates risk indefinitely.

Subject rights — where graphs help, and where they hurt

Right	In a graph
Access (subject request)	easy Fetch every triple where the person’s IRI is subject or object — graphs excel at this.
Rectification	Update the asserted facts; re-run any inference and refresh caches.
Portability	Export the person’s subgraph in a standard encoding.
Restriction / objection	Flag the data and enforce the flag at query time.
Erasure (“right to be forgotten”)	hardest Must remove asserted and inferred/materialized triples, cached results, provenance copies and backups — and prove it.

Design for erasure before you need it

Erasure is where a graph fights back: a fact can survive deletion as an inferred triple, a cached answer, a provenance record, or a copy in a downstream materialization. Design for it up front — minimize what you materialize about people, keep provenance so you can find every copy, prefer pseudonymization so “forgetting” can mean destroying one crosswalk key, and decide your tombstone-vs-hard-delete policy deliberately.

De-identification techniques

Technique	What it does	Watch out
Pseudonymization	Replace direct identifiers with pseudonymous IRIs; keep a protected crosswalk	Reversible — the crosswalk is now the crown jewels
Anonymization	Irreversibly strip identity	Re-identification via structure & quasi-identifiers is real
Masking / redaction	Hide or partially reveal a value at query time	Must also block the inference path to it
Generalization	Coarsen (exact date → year; address → region)	Balance utility against disclosure
k-anonymity / differential privacy	Thresholds or noise on aggregate results	Costs accuracy; needs a privacy budget

Model the policy, don’t just code it

Privacy and permission concepts have standard vocabularies you can reuse rather than reinvent: ODRL for permissions, prohibitions and duties; the Data Privacy Vocabulary (DPV) for personal-data categories, processing, purposes and legal bases; XACML for attribute policies. Expressing policy as data makes it queryable, testable and auditable alongside the graph it governs (see reusing standard ontologies).

07 — CROSS-CUTTING CONTROLS

Encryption, audit, and policy as code

encryption

In transit & at rest

TLS everywhere; encrypt the store and backups; manage keys centrally; consider field-level encryption for the most sensitive values so even an operator can’t read them.

audit

Log every access, immutably

Record principal, query, purpose and what was returned, to an append-only trail — the same provenance machinery that records lineage. It is your evidence for compliance and your forensics after a breach.

secrets

Keep source credentials out of mappings

Connection secrets belong in a vault used by the adapter or virtualization layer — never checked into a mapping file or an ontology.

policy as code

Externalize, version, test

Keep authorization policy out of application code, in a decision point (OPA, XACML) or an authorization graph. Then it can be reviewed, versioned and tested like any other artifact.

08 — WHERE TO ENFORCE

Defense in depth

No single control is enough. Stack them, so a gap in one is caught by the next.

edge

Gateway & authentication

Establish the principal at the perimeter; terminate TLS; apply coarse rate limits.

decision

Policy decision point

Evaluate the request against externalized policy — roles, attributes, labels, purpose — and return an allow/deny plus any constraints.

query

Enforcement at the endpoint

Rewrite or filter so only permitted triples are returned; apply aggregation thresholds and query auditing.

source

Source-level enforcement

In a virtual graph, propagate identity so each source applies its own row and column security. Materialized graphs need their own controls — source security no longer helps once the data is copied.

throughout

Encryption & audit

Encrypt in transit and at rest, and log every access immutably, at every layer.

Materialized vs. virtual changes the burden

A virtual graph can lean on source security — if, and only if, it propagates the real identity — but must still protect the integrated and inferred view the sources never saw. A materialized graph has copied the data, so it must reproduce every control itself; the source’s permissions do not travel with the triples.

09 — IN PRACTICE

Recommendations

Classify first. You cannot protect what you have not labeled. Tag sources, graphs, classes and sensitive predicates before you expose anything.
Deny by default; least privilege. Grant the narrowest slice for the stated purpose, and review grants periodically.
Named graphs as the default boundary. Go finer — predicate or statement — only where a real requirement justifies the cost.
Account for inference and aggregation, not just stored triples. Secure the entailed graph and throttle the mosaic.
Propagate the real identity to sources. Never query everything through one privileged account.
Privacy by design and by default. Minimize personal data, bind it to purpose, and design erasure in from day one.
Policy as data / as code. Externalize it, version it, test it, and audit against it — reuse ODRL and DPV rather than inventing your own.
Log immutably. Every access, with principal and purpose, to an append-only trail.

The one habit to keep

Before exposing any slice of the graph, ask three questions: who is the real principal, what can they infer from this, and is any of it personal data? Coarse per-source security answers none of them. A graph that was designed to connect everything must be designed, just as deliberately, to withhold.