Knowledge Graphs for Operationalizing Information Risk — From Siloed Artifacts to Connected…

Knowledge Graphs for Operationalizing Information Risk — From Siloed Artifacts to Connected AssuranceImage generated by AI“Learning gives creativity. Creativity leads to thinking. Thinking provides knowledge. Knowledge makes you great.” — Widely attributed to Dr. A.P.J. Abdul Kalam, a celebrated…

Knowledge Graphs for Operationalizing Information Risk — From Siloed Artifacts to Connected AssuranceImage generated by AI“Learning gives creativity. Creativity leads to thinking. Thinking provides knowledge. Knowledge makes you great.” — Widely attributed to Dr. A.P.J. Abdul Kalam, a celebrated scientist and former President of India.I had the opportunity to see Dr. Kalam in person during my university years, and this reflection on learning and knowledge has stayed with me ever since. It also captures the journey behind this applied research initiative: learning from established security practices, questioning how they work together, and exploring whether the knowledge produced by one activity can create greater value across the information risk lifecycle.Information risk practices continuously generate valuable knowledge through risk registers, threat models, control assessments, compliance mappings, privacy reviews, vulnerability findings and evidence requests. Yet these outputs are often created and consumed within individual activities, teams or systems. Their value may remain confined to the artifact for which they were originally produced.Threat modeling provides a useful example of this challenge. I have been involved in threat modeling for many years, and I have often observed that the final report is treated as a reference document rather than an actionable input to downstream security validation. The challenge, therefore, is not necessarily a lack of security information. It is the fragmentation of security knowledge. This work explores whether knowledge graphs can transform threat-modeling outputs into connected, reusable assurance knowledge for penetration testing and potentially for other information risk activities.Why Connected Knowledge?Information risk artifacts already contain valuable knowledge. A threat model may identify threats, affected components, data flows, weaknesses, expected controls, assumptions, and evidence requirements. A risk register may capture business impact and ownership, while a control assessment or vulnerability report may provide additional validation. The problem is that these insights are often distributed across separate documents, tools, and teams.The relationships among them usually remain implicit. A practitioner may need to manually determine which weakness contributes to an attack scenario, which components and data flows are affected, which controls are expected to mitigate the risk, and what evidence is required to validate those controls.Knowledge graphs make these relationships explicit.Threat → Attack Scenario → Component and Data Flow → Weakness → Control Gap → Evidence RequirementThis connected representation does not create new security knowledge by itself. Instead, it preserves context and makes existing knowledge easier to trace, query, and reuse. The same information can then be viewed differently depending on the practitioner’s objective.Who Benefits from Connected Knowledge?a) Threat modelers can trace identified threats to affected components, data flows, weaknesses, controls, and unresolved evidence requirements.b) Penetration testers can use the same context to define focused test scenarios, prioritize attack paths, and validate whether expected controls are implemented effectively.c) Assurance practitioners can connect risks and control gaps to evidence requirements, findings, and applicable standards.d) Risk leaders can identify recurring weaknesses, highly affected components, and scenarios requiring priority review or validation.The value, therefore, lies not in creating another security artifact, but in allowing different practitioners to navigate and reuse the same assurance knowledge according to the decisions they need to make.From siloed information risk artifacts to connected assurance knowledge and practitioner actionFrom Assurance Artifact to Knowledge GraphThe implementation began with a multi-agent threat-modeling capability built around fictional reference architecture. It analyzed application components, data flows, identities, assets, trust assumptions, and security context to identify candidate threats and control gaps.The output was not limited to a conventional report. It also produced a structured, machine-readable assurance artifact containing information such as:threats and attack scenarios;affected components and data flows;weaknesses and expected controls;assumptions and open questions;control gaps and evidence requirements;review actions and relevant standards mappings.This distinction was important. A human-readable report explains the analysis, while a structured artifact makes it possible for another system to interpret, connect, and reuse the underlying knowledge.Representative excerpt from the structured assurance artifact for Threat T3a) From Structure to MeaningStructured data alone does not make a knowledge graph. The application still needs to understand what each entity represents and how it relates to the others.To support this, I applied three related concepts:Semantics defined what terms, properties, and relationships meant.Classification taxonomy and controlled vocabularies organized threats, weaknesses, controls, evidence, and components into consistent categories.A conceptual domain ontology defined how these concepts could relate.For example, a threat may affect a component, contribute to an attack scenario, involve a weakness, expose a control gap, require evidence, or map to relevant security guidance. The purpose was practical rather than academic. It ensured that the same concept was interpreted consistently and that relationships normally buried inside a report became explicit.The ontology was implemented as a conceptual property-graph model using labels, properties, and relationship types. It was not a complete formal ontology with machine-enforced cardinality, domain and range constraints, or OWL/SHACL validation. Some deterministic validation and stable-identifier rules were applied, while stronger formal enforcement remains an area for future work.The property-graph model represented assurance concepts as nodes, their connections as typed relationships, and contextual information as propertiesSome examples of the meaning of relationships include:· AFFECTS: a threat affects a component.· USES_FLOW: an attack scenario uses a data flow.· INVOLVES_WEAKNESS: a scenario involves a weakness.· NEEDS_EVIDENCE: a control gap requires evidence.b) Constructing the Graph through Agentic EngineeringI built a standalone knowledge-graph application using Agentic engineering principles. The objective was not simply to draw connections between report entries. The application performed a sequence of structured tasks:Parse the assurance artifact.Normalize entity names and formats.Assign stable identifiers.Apply deterministic semantic-enrichment rules.Create nodes, properties, and relationships.Generate Neo4j Cypher queries.Produce reviewer-oriented summaries and reusable query patterns.Agentic engineering made this architectural prototype faster and more practical to implement. It helped orchestrate multi-step processing, structured state management, semantic enrichment, and query generation. It did not make knowledge graphs possible; rather, it reduced the effort required to prototype the workflows surrounding them.The application also provided different views of the same assurance state:a security-insight overview;a graph explorer;attack-scenario coverage;Cypher and CSV exports;and a library of curated, read-only queries for practitioner use.These views were intended to help practitioners move from a high-level assurance posture to the underlying nodes, relationships, assumptions, and evidence requirements.c) Exploring the Graph in Neo4j AuraThe generated Cypher was manually executed in Neo4j Aura, where the resulting graph could be explored visually and through targeted queries.Neo4j Aura visualization of the assurance knowledge graph, showing connected threats, components, controls, weaknesses, data flows, and review actionsA whole-graph visualization can appear complex at first glance, but its value is not in viewing every node simultaneously. The value comes from asking focused questions of the graph:Which threats affect a particular component?Which attack scenarios depend on the same data flow?Which scenarios involve control gaps or missing evidence?Which components are affected by the greatest number of threats?Which high-priority scenarios should be considered for security validation?The prototype generated curated, read-only Cypher patterns for questions such as these.MATCH (t:Threat)-[:AFFECTS]->(c:Component)RETURN c.name AS component, count(DISTINCT t) AS threat_countORDER BY threat_count DESCLIMIT 10;The implementation flow can therefore be summarized as:Structured assurance artifact → normalization → semantic enrichment → conceptual graph model → Cypher generation → exploration in Neo4j AuraOnce this assurance information was represented as connected knowledge, the next question was whether the graph could help translate a specific design-time threat hypothesis into a more actionable penetration-testing scope.From Threat Hypothesis to Penetration-Test ScopeTo examine whether the knowledge graph could support downstream security validation, I selected one threat from the synthetic threat model:Threat T3: Excessive access to CRM capabilitiesThe threat was connected to a more specific attack scenario:Attack Scenario AS3: A lower-privileged user, agent, or tool context invokes CRM actions through the tool-execution path.This distinction is important. A threat describes the broader security concern, while an attack scenario provides a more concrete hypothesis that can be validated. In this case, the concern was not simply “CRM access risk.” It was a tool-invocation privilege risk. The Tool Registry and Tool Execution Service could potentially enable access to CRM functions beyond the intended authorization boundaries. The knowledge graph preserved the path connecting this hypothesis to the application architecture:Agent Orchestrator → Tool Execution Service → CRM APIIt also connected the scenario to:the relevant data flows;the weakness Excessive Tool Privilege;an identified control gap;assumed controls such as authentication, authorization, least privilege, access review, and audit logging;an evidence requirement to confirm whether those controls were implemented;and an inferred mapping to applicable security guidance.a) Moving Beyond Generic TestingWithout this context, a penetration tester may begin with broad CRM API testing. The graph provided a more focused starting point: validate the authorization and privilege boundaries across the tool-invocation path.This translated the original threat into practical testing questions:· Can a lower-privileged user/agent/tool context invoke CRM-capable tools?· Are authorization checks enforced before Tool Execution Service calls the CRM API?· Are least-privilege scopes applied separately to each tool and action?· Are denied invocation attempts logged and monitored?· Is there sufficient evidence that access to CRM-capable tools is periodically reviewed?The knowledge graph did not automatically perform penetration testing or determine whether the threat was exploitable. Instead, it helped transform a design-time hypothesis into a traceable test scope containing the affected components, flows, weakness, expected controls, and required evidence.This establishes a clearer relationship between the two activities:Threat modeling identifies what could go wrong.Penetration testing gathers evidence to validate whether it can occur in the implemented system.Threat T3 connected to the application components included within the proposed penetration-test scope.b) Prioritizing Validation Across the GraphThe same graph queries could also examine multiple attack scenarios collectively. For example, practitioners could identify:high-priority scenarios with unresolved control gaps;components affected by several threats;commonly reused data flows;scenarios with missing or unconfirmed evidence;and weaknesses recurring across different parts of architecture.This broader view is important because penetration-test planning is rarely based on one threat alone. The graph can help practitioners move from individual findings toward a risk-informed view of where validation effort may be most valuable.The prototype demonstrated the ability to create this traceability and prioritization context. Whether it reduces planning time, improves test coverage, or decreases clarification effort would need to be evaluated through practitioner-led pilots.Connected assurance path translating Threat T3 into an actionable security-validation contextKnowledge-graph-derived handoff containing the context required to develop a focused pentest planHigh-priority penetration-test candidates identified through scenario priority, control gaps, affected flows, and validation status.Together, these views demonstrate how connected assurance knowledge can support both focused threat validation and cross-scenario prioritization.What the Knowledge Graph RevealedThe architectural prototype showed that the value of a knowledge graph does not come from visualization alone. Its value lies in preserving the relationships that are often implicit or difficult to navigate within conventional assurance artifacts.How the knowledge graph made assurance knowledge more contextual, queryable, and actionableThe graph also demonstrated that prioritization need not depend on severity alone. A scenario becomes more meaningful when its priority is considered alongside affected components, relevant flows, weaknesses, control gaps, and evidence status. These relationships provide a richer basis for deciding where security-validation effort may be most valuable.The architectural prototype therefore demonstrated several capabilities: threat-to-test traceability, path-based scoping, evidence identification, and cross-scenario prioritization. Potential benefits such as faster test planning, broader coverage, and reduced clarification effort would still require validation through practitioner-led pilots.The most important insight was that the knowledge graph did not create another standalone security artifact. It created a reusable assurance layer through which existing security knowledge could be explored, connected, and applied to different information risk decisions.Looking Ahead: From Connected Knowledge to Context GraphsThis technical exploration demonstrated that the value of a knowledge graph lies not merely in visualizing security information, but in preserving how assurance knowledge flows across activities. Threat modeling identified a hypothesis; the graph connected it to components, flows, weaknesses, controls, and evidence; and penetration testing received a more contextual validation scope. In that sense, the work also provided a form of value-stream mapping for security knowledge, showing where information is created, how it is transferred, and where context may otherwise be lost.This was intentionally learning-oriented. A production implementation would require stronger entity resolution, provenance, versioning, graph-quality validation, formal constraints, validated standards mappings, and automated but controlled integration with graph infrastructure. Its operational benefits would also need to be evaluated through practitioner pilots rather than assumed.A valuable next step would be to close the feedback loop:Threat hypothesis → validation activity → evidence → security decision → updated assurance knowledgeThe model could then expand beyond threat modeling to include risk registers, control assessments, vulnerability findings, privacy reviews, compliance mappings, and remediation outcomes.Over time, this could evolve from a knowledge graph into a context graph, one that preserves not only connected security concepts, but also when evidence was collected, why decisions were made, which assumptions changed, and how risks evolved. Such context could provide more relevant grounding for future agentic workflows while keeping practitioners responsible for validation and decision-making.The broader learning is that information-risk teams may already possess substantial knowledge. The opportunity is to connect that knowledge, so it remains traceable, reusable, and valuable across the assurance lifecycle.This story is published on Generative AI. Connect with us on LinkedIn and follow Zeniteq to stay in the loop with the latest AI stories.Subscribe to our newsletter and YouTube channel to stay updated with the latest news and updates on generative AI. Let’s shape the future of AI together!Knowledge Graphs for Operationalizing Information Risk — From Siloed Artifacts to Connected… was originally published in Generative AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Source: Generative AI Pub — Published July 21, 2026 at 00:41 UTC — Category: Image AI