PaperlayerView exact revision on arXiv

Source-linked AI summary

Organizational Context for the Enterprise Security Brain

Eden Yavin, Ariel Zadok, Gal Engelberg, Elad Elouz, Leon Goldberg

arXiv:2610.12540v1cs.CR

TL;DR

Correct security judgments depend on organizational knowledge that is often outside machine state, yet agents need that context resolved to live entities. The paper models it as claims with source evidence in a tier of the enterprise security brain, and evaluates extraction and agent judgments across security tasks. On a production environment, the agent detects stale documented findings in 0.97 of tasks and reaches answer correctness of 0.83 to 0.86 across policy and architecture tasks.

  • Problem

    Machine state alone does not capture organizational facts such as ownership, business function, obligations, and accepted risks that can change the correct judgment about an asset.

    Source: §1 · p. 1

  • Method

    The paper adds an organizational-context tier that represents distinct claims with source-specific attestations and resolves them onto entities in the asset graph.

    Source: §1 · p. 2, §4 · p. 4, §5 · p. 5

  • Results

    On a production environment, the agent detects stale documented findings in 0.97 of tasks and reaches answer correctness of 0.83 to 0.86 across policy and architecture tasks.

    Source: §7 · p. 7, §9 · p. 8, §8 · p. 8

  • Takeaways & Limitations

    Organizational knowledge can be represented as evidence-bearing claims alongside machine state, resolved to entities for security reasoning.

    Source: §1 · p. 2, §9 · p. 8

    The evaluation covers one production environment and 78 inference tasks, excludes tickets and conversations, and lacks comparison with alternative context representations.

    Source: §8 · p. 8

Abstract

from arXiv · show

Agents that investigate and decide on enterprise security reason over a machine-readable view of the environment: its assets, identities, configurations, relations, and findings. The correct judgment about an asset also depends on what the organization knows about it: who owns it, what business function it serves, which policy governs it, and which risks were accepted. Part of this knowledge can be inferred from machine state, such as an ownership tag; most of it is recorded by people in policies, audit reports, architecture diagrams, tickets, and conversations, outside machine state. We call this distance the organizational context gap. Closing it poses four challenges: extracting the right claims from heterogeneous organizational data and, at inference time, detecting claims made stale by live state, checking live state against the governing policy, and binding architecture diagrams, which carry the business logic, to live resources. We introduce organizational context as a layer of the enterprise security brain and define it with a taxonomy and six properties its representation must preserve. We then define a context model in which a claim carries one meaning, an attestation records each source that asserts it, strength is derived from live evidence at read time, and claims resolve onto the entities of the asset graph. On a production environment spanning AWS, Okta, Google Workspace, and GitHub, extraction recovers 0.80 of a pooled 1,355-claim ground truth at 0.87 precision, with 0.5% of extracted claims unsupported by their source. An agent reasoning over live state and resolved context raises the conflict in 0.97 of stale-finding tasks, and reaches answer correctness of 0.83 on policy-alignment tasks and 0.86 on architecture tasks.

1 Introduction

Security decisions require organizational knowledge that machine state does not capture, creating a context gap between an environment’s recorded state and what the organization knows. The paper proposes an evidence-based context layer and evaluates extraction and agent reasoning over resolved context.

1 Introduction

  • Organizational context includes ownership, business function, data criticality, governing obligations, and accepted risks that can change the correct judgment about identically configured assets.These facts are often recorded in policies, audit reports, tickets, wiki pages, and conversations rather than machine state.Source: §1 · p. 1
  • Closing the gap requires extracting claims from heterogeneous sources, detecting when live state makes documented claims stale, checking assets against governing policy, and binding architecture components to live resources.The sources repeat facts and differ in authority; diagrams carry business logic about service dependencies and placement.Source: §1 · p. 2
  • The paper defines a context taxonomy and six representation properties, then models claims as distinct meanings with source-specific attestations and resolves claims onto the asset graph.Claim strength is derived at read time, and the proposed security brain computes each abstraction once from the tier below.Source: §1 · p. 2
  • Evaluation separates extraction fidelity from agent judgment over resolved context, testing stale findings, policy alignment, and architecture diagrams in a production environment spanning AWS, Okta, Google Workspace, and GitHub.The evaluation asks whether extracted claims cover document requirements without additions and whether agent judgments use governing evidence and register disagreements with live state.Source: §1 · p. 2

2 Related Work

Prior work addresses organizational memory, security-agent context, provenance, conflict, and document grounding, but does not combine the required properties in a representation resolved onto live security state. This paper makes the claim—not the passage or row—the unit of evidence.

Organizational memory and the company brain

  • Existing organizational and agent memory systems retain procedural knowledge, experience, access policy, or relevance over time, whereas this paper targets declarative assertions about specific entities reconciled with machine state.The related work includes enterprise knowledge graphs, company-brain proposals, governed procedural memory, and temporal memory systems.Source: §2 · p. 2

Context layers for security agents

  • Security-agent context layers and the security brain represent threat knowledge, operational scope, or machine-generated state; this paper specifies the organizational layer that supplies written business-criticality and data-criticality signals.The asset intelligence layer consumes those signals; this paper specifies the layer they come from when people record them.Source: §2 · pp. 2–3

Evidence, time, and conflict

  • Prior work supplies provenance, temporal databases, conflict resolution, entity linking, and grounding techniques, but the missing representation preserves corroboration, authority, time, and disagreement while resolving onto live security state.Unlike passage- or row-centered grounding, the paper uses claims bound to entities and carried with corroboration, authority, and validity.Source: §2 · p. 3

3 Organizational Context

Organizational context is knowledge about what environment entities mean to the organization when that knowledge changes a security judgment. Its representation must distinguish content, origin, and temporality while preserving source evidence and entity references.

3 Organizational Context

  • Organizational context is entity-related knowledge—such as ownership, function, data, obligations, or accepted risks—that changes the correct value of a security judgment.Operationally, two identically configured entities qualify when context can warrant different judgments about them.Source: §3 · p. 3
  • Context varies by content, origin, and temporality: it may describe responsibilities, obligations, or architecture; come from the estate or people; and be evergreen, window-scoped, or ephemeral.A scoped assertion remains true of its window and relevant to questions about that period.Source: §3 · p. 3
  • The representation must preserve redundancy as corroboration, unequal source authority, temporal scope, and disagreement among sources or with live state.The cited properties distinguish organizational context from an undifferentiated corpus of passages.Source: §3 · p. 3
  • Assertions concern specific entities or entity classes and become useful when bound to the entities described by machine state.This includes asset types named in architecture diagrams.Source: §3 · p. 4
  • Judgments must remain traceable to the exact utterance they rely on because false compliance verdicts can mask exposure and false non-compliance verdicts cost analyst time.Provenance must reach the original image or file when the content originated outside native text.Source: §3 · p. 4
  • Similarity-ranked passages alone can retrieve a superseded policy, stale finding, or clause for a different asset class, while infrastructure changes can make findings stale.The model’s temporal and authority distinctions address risks that query similarity does not resolve.Source: §3 · pp. 3–4

4 The Enterprise Security Brain

The enterprise security brain is a tiered substrate for agents, scoring pipelines, and analysts, with each abstraction computed from the tier below and made available before questions arrive. Organizational context adds structured claims with evidence that can be bound to asset-graph entities.

4 The Enterprise Security Brain

  • The brain has raw-data, asset-graph, and context-graph tiers, each resolved before a question arrives and computed from the tier below.The context graph includes abstractions such as attack vectors, blast radius, business function, data criticality, risk scores, ownership, and organizational claims.Source: §4 · p. 4, Figure 1 · p. 4
  • Organizational context turns people’s unstructured knowledge into claims with evidence, binding them to asset-graph entities wherever possible and leaving unbound claims searchable.Bound claims become graph edges alongside technical relations, enabling queries that combine organizational claims with live resources.Source: §4 · p. 4
  • Agents can query available context or investigate it for use-case-specific conclusions, with investigations constrained to shown context, no-conclusion cases leaving subjects unchanged, and full paths recorded.Derived claims keep the provenance and lifecycle of ingested claims and are re-derived when their evidence changes.Source: §4 · p. 4

5 The Context Model

The context model gives each distinct meaning one claim and preserves each source’s assertion as an attestation. It derives claim strength from live evidence, keeps claims through their evidence lifecycle, and resolves them onto asset-graph entities.

Entities

  • A claim holds one distinct meaning, while each attestation preserves a source’s wording, author, time, validity, authority, and locator; resolved claims become queryable asset-graph edges.The figure shows three sources asserting the same meaning, with separate attestations for each occurrence.Source: §5 · p. 5, Figure 2 · p. 6

Strength

  • Claim strength is derived at read time from corroboration, authority, recency, and validity, because attestations can arrive, expire, or disappear.The authority component takes the maximum across live attestations, while validity is a soft signal and strength’s functional form is out of scope.Source: §5 · p. 5

Lifecycle

  • A claim becomes dormant, not deleted, when all attestations pass their validity windows; it can return when a source asserts it again.Removing one source does not remove a meaning held by other sources; deliberate retraction removes it.Source: §5 · p. 5

Ingestion and resolution

  • Ingestion adds an attestation to a known meaning, creates a claim for a new meaning, preserves contradictions, and resolves each claim to the entity or entity class it concerns.A same-source revision supersedes the earlier claim while retaining it as history.Source: §5 · p. 5

Retrieval

  • Retrieval returns claims with derived strength, source and locator details, observation times, and live conflicts rather than returning passages alone.An agent receives disagreement and staleness as data when a claim conflicts with live evidence or has out-of-window attestations.Source: §5 · p. 5

6 Experimental Setup and Evaluation

The evaluation uses a live, multi-platform production environment and organizational documents that include governance material and an architecture document. It tests extraction and tool-using agent inference with human-reviewed task rows and task-specific metrics.

Environment

  • The live production environment spans AWS, Okta, Google Workspace, and GitHub, with tasks that can require resolving identities across platforms.Examples include linking an Okta identity to the IAM role it assumes.Source: §6 · p. 6

Corpus

  • The organizational corpus combines governance documents and audit material with the environment’s architecture document describing services, dependencies, processing, compute, sizing, and data stores.Source: §6 · p. 6

Inference agent and tasks

  • A tool-using agent interleaves SQL queries over the live asset graph with context-store search and returns a verdict justified by live facts and cited documents.Its evaluation uses contradiction, policy-alignment, and architecture tasks expanded from analyst-written seeds; every row has a recorded human review outcome.Source: §6 · p. 6

Extraction evaluation

  • Extraction is scored for pooled recall, precision against a model-generated pooled ground truth, and faithfulness to source text; the 1,355 claims come from six documents.The pool is not an exhaustive human annotation, and requirements missed by every model are invisible to pooled recall.Source: §6 · p. 6

Evaluation metrics

  • Retrieval measures document-section recall and SQL equivalence, while inference measures grounded conflict detection or task-specific answer correctness and alignment faithfulness.Which source the agent trusts when report and live state disagree is a deployment preference, not a scored outcome.Source: §6 · pp. 6–7, Table 1 · p. 7

7 Results

Across the inference task sets, the agent raises stale-finding conflicts and achieves answer correctness on policy-alignment and architecture tasks. Extraction recovers most pooled claims, with most extracted claims fully supported by their sources.

Extraction

  • 0.80 of pooled ground-truth claims were recovered at 0.87 precision; 0.92 of extracted claims were fully source-supported, 0.06 partially supported, and 0.005 unsupported.Source: Table 2 · p. 7, §7 · p. 7

Inference

  • 0.97 of contradiction tasks raised conflict, while answer correctness was 0.83 on alignment tasks and 0.86 on architecture tasks.Source: Table 3 · p. 7, §7 · pp. 7–8

Retrieval

  • Contradiction-task document retrieval recall was 0.98 and SQL equivalence was 0.91; alignment retrieval recall was 0.82, the lowest across sets.The paper says the lower alignment retrieval recall is consistent with governing policy clauses being harder to locate than report findings.Source: §7 · pp. 7–8
  • SQL equivalence was below document retrieval recall in every set: 0.91 versus 0.98 on contradiction, 0.78 versus 0.82 on alignment, and 0.75 versus 0.88 on architecture tasks.The gap was widest when a task required binding a diagram component to a concrete resource.Source: §7 · p. 8

8 Discussion

Across the four challenges, the results show strong claim coverage and stale-finding detection, with lower live-query matching for architecture tasks. The evaluation is limited in scope and design.

8 Discussion

  • 0.80 of pooled requirements are held with 0.5% unsupported claims; stale findings are raised in 0.97 of tasks, while policy and architecture correctness reach 0.83 and 0.86.The extraction errors are omissions rather than inventions.Source: §8 · p. 8
  • 0.75 of architecture live queries match the reference, the evaluation’s lowest score, despite 0.86 answer correctness.Across task sets, the agent finds governing documents more reliably than it writes the live-state query; the study describes this pattern but does not isolate its cause.Source: §8 · p. 8
  • Policy-alignment tasks reach 0.83 answer correctness, 0.82 retrieval recall, and 0.85 faithfulness, with errors linked to clause selection and added requirements.The reported error sources are locating the governing clause among similar clauses and adding requirements that the clause does not state.Source: §8 · p. 8
  • The evaluation covers one production environment, 78 inference tasks, and documents without tickets or conversations.Ground truth and grading rely on models, task sets lack opposite-outcome controls for contradiction and architecture tasks, and only one context representation is tested.Source: §8 · p. 8

9 Conclusion

The paper introduces organizational context as an evidence-bearing layer of the enterprise security brain and evaluates a context model on a production environment. Results span claim extraction, stale-finding detection, and policy and architecture judgments, while alternative representations and conversational sources remain open questions.

9 Conclusion

  • The context model represents organizational knowledge as claims with evidence, derived strength, a lifecycle rule, and resolution onto the asset graph.The paper also defines a taxonomy and six properties for organizational context.Source: §9 · p. 8
  • Extraction recovers 0.80 of pooled ground-truth claims with 0.5% unsupported, while answer correctness reaches 0.83–0.86 and stale findings are detected in 0.97 of tasks.The live query is the weakest stage, with SQL equivalence between 0.75 and 0.91.Source: §9 · p. 8
  • The evaluation leaves open how the context model compares with alternative representations and how it behaves on conversational sources.Source: §9 · p. 8

A Example Tasks

The appendix presents representative agent questions for contradiction, policy-alignment, and architecture tasks. Architecture examples cover four task kinds, and the live state matches the architecture document in every architecture task.

A Example Tasks

  • Contradiction tasks ask whether a reported security finding still holds against live data, including privilege escalation, IMDSv1, and disabled RDS backups.Source: A Example Tasks · p. 11
  • Alignment tasks check live assets against governing policy clauses, including network filtering, data protection, and communication protocols.Source: A Example Tasks · p. 11
  • Architecture tasks cover diagram and specification conformance, partially live-checkable design questions, and component inventory; live state matches the document in every task.Examples include queue timing, Fargate sizing, scaling behavior, and identifying deployed Lambda functions.Source: A Example Tasks · pp. 11–12

Related papers

Loading 2610.12540v1…