.NET / SQL / Enterprise Engineering
Cross-Fleet Graph-Memory Governance and SQL Server Row-Level Security Architecture
Report summary
The transition from isolated, stateless autonomous agents to collaborative, persistent multi-agent fleets necessitates a fundamental reimagining of data governance and epistemic memory management. As organizations deploy specialized agent fleets across functional boundaries—such as Legal, Sales, Fin
Key topics
- .NET / SQL / Enterprise Engineering
- .NET
- SQL
- Enterprise Engineering
- AI
- Runtime
- Privacy
- Semantic Systems
- Research Archive
Research provenance
For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.
This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.
Full report
On this page
Executive Summary
The transition from isolated, stateless autonomous agents to collaborative, persistent multi-agent fleets necessitates a fundamental reimagining of data governance and epistemic memory management. As organizations deploy specialized agent fleets across functional boundaries—such as Legal, Sales, Finance, Engineering, and Customer Support—these agents require a shared memory repository to store graph-structured knowledge, assertions, and observations. However, this convergence introduces severe security and operational challenges. Permitting unauthorized cross-fleet memory access risks context pollution, unauthorized privilege escalation, and the lateral movement of compromised credentials. Conversely, enforcing absolute, impenetrable isolation prevents the organization from discovering structural alignments and synergistic intelligence between disjointed knowledge graphs, such as recognizing that a seemingly isolated supplier node in the Engineering fleet represents the exact same ontological entity as a vendor node in the Finance fleet. This comprehensive research report details a production-grade governance architecture leveraging Microsoft SQL Server's graph database capabilities, Row-Level Security (RLS), and ASP.NET Core. The architecture establishes an epistemic memory repository where autonomous agents can safely persist and query graph-structured knowledge. Strict tenant and fleet isolation is enforced dynamically at the database engine level using session context and connection interceptors, ensuring that application-layer vulnerabilities cannot bypass data-layer authorization. To bridge the gap between strict isolation and enterprise intelligence, cross-fleet structural alignment is achieved through an offline, privileged background service. This service utilizes Fused Gromov-Wasserstein (FGW) optimal transport to analyze topological and semantic similarities across segregated subgraphs, generating read-only cross-fleet edge proposals for deterministic or human review. Furthermore, the architecture implements a C\# strategy-based conflict resolution engine to calibrate and synthesize contradictory assertions while preserving cryptographic provenance. By utilizing SQL Server concurrency tokens, the design mathematically prevents lost updates and race conditions, yielding a secure, performant, and highly aligned multi-agent memory system.
1. Comprehensive Threat Model and Residual Risk Analysis
The deployment of shared memory systems for autonomous agents expands the traditional application security attack surface. Graph data is inherently interconnected, and LLM-driven agents operate with non-deterministic behaviors, making them susceptible to prompt injections that can manifest as data poisoning. The following threat model identifies the primary attack vectors against the multi-agent graph memory, maps them to specific architectural controls, and assesses the residual risk.
| Threat Category | Description and Mechanism | Architectural Control | Residual Risk |
|---|---|---|---|
| Accidental Context Pollution | Agents hallucinate or generate mathematically misaligned assertions, writing them into shared memory and poisoning future context retrieval for the entire fleet. | Epistemic conflict resolution strategies synthesize confidence scores; soft-deletion mechanisms and validity states isolate unverified nodes. | Low. Human-in-the-loop validation is required for highly contested or low-confidence assertions. |
| Malicious Prompt or Memory Injection | An external attacker injects a payload into an agent's context, causing the agent to write adversarial logic or instructions into the graph as memory assertions. | Graph schema enforces strict typed assertions; execution environments are strictly segregated from storage; memory is treated strictly as untrusted string data. | Moderate. Adversarial payloads may still be retrieved and act as passive prompt injections for subsequent agents querying the same node. |
| Compromised Agent Credentials | An attacker acquires an agent's workload identity token or API key, attempting to access memory or traverse the graph across the entire organizational repository. | RLS policies dynamically bind SESSION\_CONTEXT to specific fleet boundaries; identity tokens confer no global permissions beyond the assigned fleet. | Low. The blast radius is mathematically confined to the compromised agent's specific fleet. |
| Confused-Deputy Attacks | A privileged system component is tricked into executing unauthorized cross-fleet operations on behalf of an unprivileged, malicious agent. | Explicit separation of database principals is utilized. Privileged cross-fleet reads require certificate-signed stored procedures rather than simple application-layer IsPrivileged claims. | Low. Application code lacks the underlying SQL permissions to execute elevated commands natively. |
| Unauthorized Cross-Fleet Traversal | Maliciously crafted recursive queries attempt to traverse past approved cross-fleet edges to map an unauthorized fleet's topology or extract bulk data. | Secure traversal procedures enforce strict depth limits and prohibit arbitrary-length graph MATCH operators (+ or {1,n}); direct traversal queries are intercepted by RLS block predicates. | Low. Traversal depth is hardcoded into signed database modules that ordinary agents cannot alter. |
| Overprivileged Alignment Workers | The offline FGW alignment service is exploited to write unauthorized cross-fleet edges directly into active memory nodes, bypassing standard validation. | The alignment service operates on a read-only snapshot using a restricted principal; outputs are constrained to a separate CrossFleetEdgeProposals table pending review. | Very Low. Network segmentation and database principal isolation fundamentally prevent direct writes. |
| SQL Injection | A compromised agent submits maliciously crafted assertion strings containing executable T-SQL commands to manipulate database structures or extract unauthorized data. | Entity Framework Core parameterizes all queries automatically; dynamic SQL is strictly prohibited; the database user lacks DDL permissions. | Very Low. Standard ORM parameterization neutralizes first-order and second-order SQL injection vectors. |
| Session-Context Spoofing | Connection pool reuse or injected commands allow an agent to alter the SESSION\_CONTEXT variables mid-request to impersonate another fleet. | Connection interceptors explicitly initialize context with sp\_set\_session\_context using the @read\_only \= 1 parameter, preventing mid-session modification. | Very Low. Connection pooling automatically executes sp\_reset\_connection, purging the context prior to the next request. |
| Race Conditions (Lost Updates) | Concurrent agents attempt to update the same memory node simultaneously, leading to overwritten provenance, corrupted graph topology, or lost validity states. | Implementation of ROWVERSION concurrency tokens on all tables; EF Core intercepts DbUpdateConcurrencyException for optimistic concurrency control. | Very Low. The database engine natively rejects mismatched row versions, forcing the application layer to resolve the conflict. |
| Data Inference Through Aggregate Results | Agents execute statistical queries (e.g., COUNT, AVG) against proposed edges or views to infer the underlying attributes of another fleet's data without directly reading the rows. | Aggregate functions are subjected to the same RLS filter predicates as standard SELECT queries; proposed edges remain invisible to ordinary agents until promoted. | Moderate. Authorized cross-fleet edges may still allow limited statistical inference of the target node's immediate topology. |
| Poisoned Confidence Scores | A compromised or malfunctioning agent floods the graph with spurious assertions containing artificially inflated confidence scores (e.g., 1.0) to override legitimate memory. | C\# conflict resolution strategies utilize confidence calibration, penalizing outlier agents and applying confidence-weighted averaging rather than naive overwrites. | Moderate. Requires continuous monitoring of agent reliability scores to isolate persistently malicious actors. |
| Unauthorized Promotion of Proposed Edges | An agent attempts to directly update the ReviewState of a cross-fleet edge proposal to bypass human or deterministic validation workflows. | Ordinary agents lack UPDATE permissions on the CrossFleetEdgeProposals table; RLS block predicates reject writes from non-reviewer principals. | Low. Authorization boundaries restrict proposal promotions to dedicated reviewer identities. |
| Bulk Extraction | A malicious actor attempts to dump the entire contents of a fleet's memory by iterating through all possible NodeId values or issuing unbounded SELECT \* queries. | Application-layer rate limiting; RLS restricts the extraction strictly to the authorized fleet; audit logging triggers alerts upon anomalous query volumes. | Moderate. While cross-fleet extraction is blocked, a compromised agent can still extract its own fleet's data if rate limits are bypassed. |
| Side-Channel Leakage via Timing or Row Counts | Malicious agents execute index-using queries designed to infer the existence of hidden rows by measuring execution time or triggering divide-by-zero errors against protected data. | Avoidance of complex OR/NOT logic in RLS predicates; isolation of the compute environment; parameterized queries prevent the injection of custom mathematical triggers. | Moderate. Timing side-channels are an inherent limitation of RLS when underlying indexes are shared across tenants. |
The most persistent residual risks involve timing side-channels and side-effect leakage. Database research indicates that while RLS enforces logical isolation, it does not provide complete physical obfuscation of query execution plans1. An attacker with the ability to inject arbitrary SQL could hypothetically measure query durations to infer the presence of a specific value in a protected row1. To mitigate this vulnerability, the architecture strictly prohibits dynamic SQL generation at the agent level. All interactions are forced through parameterized Entity Framework Core (EF Core) LINQ queries or predefined stored procedures, effectively eliminating the surface area for arbitrary timing probes and mathematical exception triggers4. Furthermore, privacy and regulatory frameworks, such as the Illinois Biometric Information Privacy Act (BIPA) and the Personal Information Protection Act (PIPA), mandate strict controls over data access and retention5. The architectural use of SESSION\_CONTEXT ensures that a breach of one fleet's application tier provides zero mathematical ability to extract another fleet's data, bounding the regulatory notification radius to the affected fleet alone8.
2. Trust Boundaries and Data Flow
To visualize the architectural governance model, the system is divided into distinct trust boundaries. Ordinary agents interact exclusively with the Graph Memory API, which enforces fleet isolation. The Privileged Alignment Service operates out-of-band, reading cross-fleet snapshots and proposing alignments to a secure review enclave.
Code snippet flowchart TD subgraph Boundary\_FleetA \[Agent Fleet A Trust Boundary\] AgentA1\[Agent Worker 1\] AgentA2\[Agent Worker 2\] end
subgraph Boundary\_FleetB \[Agent Fleet B Trust Boundary\] AgentB1\[Agent Worker 1\] end
subgraph Boundary\_AppTier \[ASP.NET Core Application Tier\] API\[Graph Memory API\] EF\[EF Core with RLS Interceptor\] Conflict\[C\# Conflict Resolution Engine\]
API \--\> EF EF \--\> Conflict end
subgraph Boundary\_Database \[SQL Server Engine Trust Boundary\] RLS\[Row-Level Security Policies\] Graph\[(Graph Tables: Nodes & Edges)\] Proposals\[(Edge Proposals)\] Approved\[(Approved Cross-Fleet Edges)\]
RLS \--\> Graph end
subgraph Boundary\_Alignment \[Privileged Alignment Service\] FGW\[Fused Gromov-Wasserstein Engine\] Review\[Validation & Human Review\] end
AgentA1 \--\>|Read/Write Fleet A| API AgentA2 \--\>|Read/Write Fleet A| API AgentB1 \--\>|Read/Write Fleet B| API
EF \--\>|sp\_set\_session\_context| RLS
FGW \--\>|Read-Only Snapshot Bypass| Graph FGW \--\>|Write| Proposals Proposals \--\>|Submit for Approval| Review Review \--\>|Promote| Approved
API \--\>|Signed SP Traversal| Approved
3. SQL Server Graph-Relational Schema
The storage layer utilizes SQL Server's native graph database capabilities, combining strict relational constraints with graph traversal optimizations. Nodes and edges are instantiated as first-class entities. The schema leverages strict relational referential integrity, UTC timestamps, and ROWVERSION types for optimistic concurrency control10. The execution of recursive queries or pathfinding in SQL Server graphs utilizes the MATCH clause. To ensure deterministic traversal and authorization, the schema structures entities to support explicit relational joins combined with graph topology.
SQL CREATE SCHEMA Core; GO CREATE SCHEMA Security; GO CREATE SCHEMA Alignment; GO
\-- Relational Governance Tables CREATE TABLE Core.Tenants ( TenantId INT IDENTITY(1,1) PRIMARY KEY, TenantName NVARCHAR(256) NOT NULL UNIQUE, IsActive BIT NOT NULL DEFAULT 1, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() );
CREATE TABLE Core.Fleets ( FleetId INT IDENTITY(1,1) PRIMARY KEY, TenantId INT NOT NULL, FleetName NVARCHAR(256) NOT NULL, Description NVARCHAR(MAX), CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Fleets\_Tenants FOREIGN KEY (TenantId) REFERENCES Core.Tenants(TenantId), CONSTRAINT UQ\_Fleets\_Tenant\_Name UNIQUE (TenantId, FleetName) );
CREATE TABLE Core.Agents ( AgentId INT IDENTITY(1,1) PRIMARY KEY, TenantId INT NOT NULL, WorkloadIdentitySubject NVARCHAR(256) NOT NULL UNIQUE, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Agents\_Tenants FOREIGN KEY (TenantId) REFERENCES Core.Tenants(TenantId) );
CREATE TABLE Core.AgentFleetMemberships ( MembershipId INT IDENTITY(1,1) PRIMARY KEY, AgentId INT NOT NULL, FleetId INT NOT NULL, AssignedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Membership\_Agent FOREIGN KEY (AgentId) REFERENCES Core.Agents(AgentId), CONSTRAINT FK\_Membership\_Fleet FOREIGN KEY (FleetId) REFERENCES Core.Fleets(FleetId), CONSTRAINT UQ\_Membership\_Agent\_Fleet UNIQUE (AgentId, FleetId) );
CREATE TABLE Core.Tasks ( TaskId INT IDENTITY(1,1) PRIMARY KEY, FleetId INT NOT NULL, TaskDescription NVARCHAR(MAX) NOT NULL, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Tasks\_Fleets FOREIGN KEY (FleetId) REFERENCES Core.Fleets(FleetId) );
\-- Graph Memory Structures CREATE TABLE Core.MemoryNodes ( NodeId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, TenantId INT NOT NULL, FleetId INT NOT NULL, SemanticLabel NVARCHAR(128) NOT NULL, ValidityState TINYINT NOT NULL DEFAULT 1, \-- 0 \= Revoked, 1 \= Active, 2 \= Quarantined CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), ConcurrencyToken ROWVERSION NOT NULL, CONSTRAINT FK\_MemoryNodes\_Tenants FOREIGN KEY (TenantId) REFERENCES Core.Tenants(TenantId), CONSTRAINT FK\_MemoryNodes\_Fleets FOREIGN KEY (FleetId) REFERENCES Core.Fleets(FleetId) ) AS NODE;
CREATE TABLE Core.MemoryEdges ( EdgeId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, TenantId INT NOT NULL, FleetId INT NOT NULL, RelationshipType NVARCHAR(128) NOT NULL, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), ConcurrencyToken ROWVERSION NOT NULL, CONSTRAINT FK\_MemoryEdges\_Tenants FOREIGN KEY (TenantId) REFERENCES Core.Tenants(TenantId), CONSTRAINT FK\_MemoryEdges\_Fleets FOREIGN KEY (FleetId) REFERENCES Core.Fleets(FleetId) ) AS EDGE;
CREATE TABLE Core.MemoryAssertions ( AssertionId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, NodeId UNIQUEIDENTIFIER NOT NULL, AgentId INT NOT NULL, TaskId INT NOT NULL, AssertionData NVARCHAR(MAX) NOT NULL, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), ConcurrencyToken ROWVERSION NOT NULL, CONSTRAINT FK\_Assertions\_Nodes FOREIGN KEY (NodeId) REFERENCES Core.MemoryNodes(NodeId), CONSTRAINT FK\_Assertions\_Agents FOREIGN KEY (AgentId) REFERENCES Core.Agents(AgentId), CONSTRAINT FK\_Assertions\_Tasks FOREIGN KEY (TaskId) REFERENCES Core.Tasks(TaskId) );
CREATE TABLE Core.ConfidenceScores ( ScoreId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, AssertionId UNIQUEIDENTIFIER NOT NULL, ConfidenceValue DECIMAL(5,4) NOT NULL, CalibrationMetric DECIMAL(5,4) NOT NULL DEFAULT 1.0000, EvaluatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT CHK\_Confidence\_Range CHECK (ConfidenceValue \>= 0.0 AND ConfidenceValue \<= 1.0), CONSTRAINT FK\_Confidence\_Assertions FOREIGN KEY (AssertionId) REFERENCES Core.MemoryAssertions(AssertionId) );
CREATE TABLE Core.MemoryProvenance ( ProvenanceId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, AssertionId UNIQUEIDENTIFIER NOT NULL, SourceSystem NVARCHAR(256) NOT NULL, CryptographicHash NVARCHAR(512) NOT NULL, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Provenance\_Assertions FOREIGN KEY (AssertionId) REFERENCES Core.MemoryAssertions(AssertionId) );
\-- Alignment and Cross-Fleet Governance CREATE TABLE Alignment.CrossFleetEdgeProposals ( ProposalId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, TenantId INT NOT NULL, SourceNodeId UNIQUEIDENTIFIER NOT NULL, TargetNodeId UNIQUEIDENTIFIER NOT NULL, AlignmentScore DECIMAL(5,4) NOT NULL, Methodology NVARCHAR(128) NOT NULL, ReviewState TINYINT NOT NULL DEFAULT 0, \-- 0 \= Pending, 1 \= Approved, 2 \= Rejected CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Proposals\_Tenants FOREIGN KEY (TenantId) REFERENCES Core.Tenants(TenantId) ) AS EDGE;
CREATE TABLE Alignment.ReviewDecisions ( DecisionId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, ProposalId UNIQUEIDENTIFIER NOT NULL, ReviewerIdentity NVARCHAR(256) NOT NULL, DecisionNotes NVARCHAR(MAX), DecidedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_Review\_Proposals FOREIGN KEY (ProposalId) REFERENCES Alignment.CrossFleetEdgeProposals(ProposalId) );
CREATE TABLE Alignment.ApprovedCrossFleetEdges ( ApprovalId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, TenantId INT NOT NULL, SourceFleetId INT NOT NULL, TargetFleetId INT NOT NULL, RelationshipType NVARCHAR(128) NOT NULL, ValidUntilUtc DATETIME2 NULL, CreatedAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(), CONSTRAINT FK\_ApprovedEdges\_Tenants FOREIGN KEY (TenantId) REFERENCES Core.Tenants(TenantId) ) AS EDGE;
CREATE TABLE Security.SecurityAuditEvents ( EventId UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() PRIMARY KEY, TenantId INT NOT NULL, FleetId INT NOT NULL, AgentId INT NULL, EventType NVARCHAR(128) NOT NULL, EventDetails NVARCHAR(MAX) NOT NULL, OccurredAtUtc DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME() );
\-- Indexes for performance and RLS optimization CREATE NONCLUSTERED INDEX IX\_MemoryNodes\_Tenant\_Fleet ON Core.MemoryNodes(TenantId, FleetId) INCLUDE (ValidityState); CREATE NONCLUSTERED INDEX IX\_MemoryEdges\_Tenant\_Fleet ON Core.MemoryEdges(TenantId, FleetId); CREATE NONCLUSTERED INDEX IX\_Assertions\_NodeId ON Core.MemoryAssertions(NodeId);
The schema mandates the ROWVERSION data type on mutating tables. This type is an automatically incrementing database token that guarantees optimistic concurrency without necessitating application-level timestamp management11. When an EF Core interceptor attempts an update, it incorporates the original ROWVERSION byte array into the WHERE clause. If a race condition occurs, zero rows are affected, triggering a DbUpdateConcurrencyException to be handled by the C\# application layer.
4. Authorization Model and Row-Level Security
Relying exclusively on application-layer filtering is a known anti-pattern that frequently results in unauthorized data exposure due to developer error or Object-Relational Mapper (ORM) misconfiguration1. The architecture enforces authorization directly at the database engine tier utilizing SQL Server Row-Level Security (RLS) policies based on SESSION\_CONTEXT. The ASP.NET Core application pool authenticates to SQL Server using a single managed identity. To establish the specific context of the requesting agent, an EF Core DbConnectionInterceptor intercepts the connection lifecycle. Immediately after a physical connection is acquired from the connection pool or opened anew, the interceptor binds the logical session state via the sp\_set\_session\_context stored procedure14. Historically, developers utilized CONTEXT\_INFO, but it is fundamentally limited as a binary blob susceptible to overwriting and lacks key-value scoping16. SESSION\_CONTEXT resolves this by supporting specific keys and read-only locks. The @read\_only \= 1 flag is applied to definitively prevent mid-session mutations, neutralizing attempts by malicious agents to execute dynamic SQL that spoofs session variables16. When the connection is returned to the ADO.NET pool, SQL Server executes sp\_reset\_connection, automatically purging the context to prevent state leakage to subsequent requests.
4.1. Entity Framework Core Connection Interceptor
C\# using System.Data.Common; using System.Threading; using System.Threading.Tasks; using Microsoft.EntityFrameworkCore.Diagnostics; using Microsoft.AspNetCore.Http;
namespace MultiAgent.Governance.Data { /// \<summary\> /// Intercepts database connections to inject tenant and fleet context securely. /// \</summary\> public class FleetSessionConnectionInterceptor : DbConnectionInterceptor { private readonly IHttpContextAccessor \_httpContextAccessor;
public FleetSessionConnectionInterceptor(IHttpContextAccessor httpContextAccessor) { \_httpContextAccessor \= httpContextAccessor; }
public override async Task ConnectionOpenedAsync( DbConnection connection, ConnectionEndEventData eventData, CancellationToken cancellationToken \= default) { var tenantId \= \_httpContextAccessor.HttpContext?.User?.FindFirst("TenantId")?.Value; var fleetId \= \_httpContextAccessor.HttpContext?.User?.FindFirst("FleetId")?.Value;
if (\!string.IsNullOrEmpty(tenantId) && \!string.IsNullOrEmpty(fleetId)) { using var command \= connection.CreateCommand();
// @read\_only \= 1 ensures the context cannot be altered during the lifecycle // of this logical connection, preventing session spoofing via SQL injection. command.CommandText \= @" EXEC sp\_set\_session\_context @key \= N'TenantId', @value \= @TenantId, @read\_only \= 1; EXEC sp\_set\_session\_context @key \= N'FleetId', @value \= @FleetId, @read\_only \= 1; ";
var pTenant \= command.CreateParameter(); pTenant.ParameterName \= "@TenantId"; pTenant.Value \= int.Parse(tenantId); command.Parameters.Add(pTenant);
var pFleet \= command.CreateParameter(); pFleet.ParameterName \= "@FleetId"; pFleet.Value \= int.Parse(fleetId); command.Parameters.Add(pFleet);
await command.ExecuteNonQueryAsync(cancellationToken); } } } }
4.2. RLS Security Predicates and Policies
The database enforces security via inline table-valued functions (TVFs) bound to the tables. Filter predicates silently restrict read access, while block predicates explicitly intercept and reject INSERT or UPDATE operations that attempt to assign nodes or edges to unauthorized fleets20.
SQL \-- Inline TVF for Tenant and Fleet Isolation CREATE FUNCTION Security.fn\_GraphMemoryPredicate(@TenantId INT, @FleetId INT) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS AccessResult WHERE \-- Match exactly on Tenant and Fleet bounds @TenantId \= CAST(SESSION\_CONTEXT(N'TenantId') AS INT) AND @FleetId \= CAST(SESSION\_CONTEXT(N'FleetId') AS INT); GO
\-- Apply Policies to MemoryNodes CREATE SECURITY POLICY Security.MemoryNodesPolicy ADD FILTER PREDICATE Security.fn\_GraphMemoryPredicate(TenantId, FleetId) ON Core.MemoryNodes, ADD BLOCK PREDICATE Security.fn\_GraphMemoryPredicate(TenantId, FleetId) ON Core.MemoryNodes AFTER INSERT, ADD BLOCK PREDICATE Security.fn\_GraphMemoryPredicate(TenantId, FleetId) ON Core.MemoryNodes AFTER UPDATE WITH (STATE \= ON, SCHEMABINDING \= ON); GO
\-- Apply Policies to MemoryEdges CREATE SECURITY POLICY Security.MemoryEdgesPolicy ADD FILTER PREDICATE Security.fn\_GraphMemoryPredicate(TenantId, FleetId) ON Core.MemoryEdges, ADD BLOCK PREDICATE Security.fn\_GraphMemoryPredicate(TenantId, FleetId) ON Core.MemoryEdges AFTER INSERT, ADD BLOCK PREDICATE Security.fn\_GraphMemoryPredicate(TenantId, FleetId) ON Core.MemoryEdges AFTER UPDATE WITH (STATE \= ON, SCHEMABINDING \= ON); GO
To optimize execution plans and prevent the query optimizer from issuing full table scans against unindexed predicate columns, the schema establishes non-clustered indexes covering both TenantId and FleetId. The absence of indexes on RLS predicates is a primary cause of severe performance degradation and CPU exhaustion in multi-tenant SQL Server environments21.
5. Approved Cross-Fleet Access
A critical challenge in this architecture is permitting an agent to read specific graph nodes residing in a foreign fleet via an approved cross-fleet edge, while simultaneously preventing the agent from recursively traversing into the entirety of the foreign fleet's subgraph. Because RLS filter predicates evaluate continuously across all queries, attempting to embed complex MATCH logic or cross-table joins directly into the fn\_GraphMemoryPredicate function fundamentally degrades query performance and increases the database's vulnerability to timing side-channels3. Furthermore, simply granting an application-layer IsPrivileged \= 1 claim bypasses database enforcement entirely and violates the principle of defense-in-depth13. Instead, the architecture utilizes cryptographic module signing to establish a secure execution context. A dedicated stored procedure is constructed to perform the exact traversal logic using SQL Server's graph MATCH function. This stored procedure is signed with a cryptographic certificate. A database user is derived from this certificate, and that derived user is granted elevated SELECT permissions on Core.MemoryNodes while bypassing the standard RLS policy restriction25. The application caller only holds EXECUTE permission on the stored procedure and lacks direct SELECT permissions on the foreign tables. To prevent runaway traversal (e.g., an agent pulling the entire foreign fleet by requesting an arbitrary graph depth), the procedure does not use arbitrary-length graph operators (+ or {1,n})26. For recursive capabilities where varying depth is required, the MAXRECURSION query hint is forcibly constrained to limit compute cycles and bound data retrieval27. The returned projection is heavily redacted, exposing only non-sensitive attribute columns.
5.1. Secure Traversal Procedure Implementation
SQL \-- Assume a certificate 'CrossFleetCert' and a user 'CrossFleetUser' have been created. \-- Grant SELECT to CrossFleetUser on Core.MemoryNodes and Alignment.ApprovedCrossFleetEdges.
CREATE PROCEDURE Security.usp\_RetrieveCrossFleetGraph @SourceNodeId UNIQUEIDENTIFIER AS BEGIN SET NOCOUNT ON;
DECLARE @CurrentTenantId INT \= CAST(SESSION\_CONTEXT(N'TenantId') AS INT); DECLARE @CurrentFleetId INT \= CAST(SESSION\_CONTEXT(N'FleetId') AS INT);
IF @CurrentTenantId IS NULL OR @CurrentFleetId IS NULL BEGIN THROW 50001, 'Invalid Session Context.', 1; END
\-- Ensure the calling agent owns the source node within its own fleet bounds IF NOT EXISTS ( SELECT 1 FROM Core.MemoryNodes WHERE NodeId \= @SourceNodeId AND TenantId \= @CurrentTenantId AND FleetId \= @CurrentFleetId AND ValidityState \= 1 ) BEGIN THROW 50002, 'Source Node not found or inaccessible.', 1; END
\-- Traverse explicitly via the ApprovedCrossFleetEdges table. \-- The execution context of this procedure (via certificate signing) bypasses standard RLS, \-- allowing the retrieval of the TargetNode residing in the foreign fleet. \-- The projection is redacted to exclude raw assertions and internal provenance hashes. SELECT TargetNode.NodeId, TargetNode.SemanticLabel, TargetNode.CreatedAtUtc, CrossEdge.RelationshipType AS AlignmentReason, CrossEdge.ValidUntilUtc FROM Core.MemoryNodes AS SourceNode, Alignment.ApprovedCrossFleetEdges AS CrossEdge, Core.MemoryNodes AS TargetNode WHERE MATCH(SourceNode\-(CrossEdge)\-\>TargetNode) AND SourceNode.NodeId \= @SourceNodeId AND CrossEdge.TenantId \= @CurrentTenantId AND (CrossEdge.ValidUntilUtc IS NULL OR CrossEdge.ValidUntilUtc \> SYSUTCDATETIME());
\-- Log the cross-fleet access for audit purposes INSERT INTO Security.SecurityAuditEvents (TenantId, FleetId, EventType, EventDetails) VALUES (@CurrentTenantId, @CurrentFleetId, 'CrossFleetAccess', CONCAT('Accessed Target Nodes via Source Node ', CAST(@SourceNodeId AS NVARCHAR(36)))); END GO
\-- Sign the procedure to elevate privileges securely without granting blanket permissions ADD SIGNATURE TO Security.usp\_RetrieveCrossFleetGraph BY CERTIFICATE CrossFleetCert; GO
By constraining the relationship strictly to Alignment.ApprovedCrossFleetEdges, the application guarantees that agents can only view foreign attributes explicitly approved by the alignment process. The relationship remains strictly directional, read-only, subject to expiration via ValidUntilUtc, and disables standard query caching which could inadvertently leak data across contexts29.
6. Epistemic Conflict Resolution
Autonomous agents inevitably generate conflicting assertions regarding the same conceptual node. For instance, a Sales agent might assert a client's status as "Active" with an 85% confidence score, while a Support agent asserts the status as "At-Risk" with a 95% confidence score based on recent ticketing volume. Merging these states destructively in the database permanently erases the provenance and rationale of the agents. The architecture implements a C\# Strategy pattern to aggregate and resolve contradictions at read time without destroying the underlying historical assertions. A robust strategy guarantees numeric stability, enforces confidence calibration based on source reliability, and maintains tie-breaking rules for human-verified assertions.
6.1. Conflict Resolution Implementation
C\# using System; using System.Collections.Generic; using System.ComponentModel.DataAnnotations; using System.Linq;
namespace MultiAgent.Governance.Memory { /// \<summary\> /// Represents a discrete observation made by an autonomous agent. /// \</summary\> public class MemoryAssertion { \[Display(Name \= "Assertion")\] public Guid Id { get; set; }
\[Display(Name \= "Source Agent")\] public int SourceAgent { get; set; }
\[Display(Name \= "Assertion Data")\] public string Data { get; set; }
\[Display(Name \= "Confidence Metric")\] public decimal Confidence { get; set; }
\[Display(Name \= "Recorded Timestamp")\] public DateTimeOffset RecordedAt { get; set; }
\[Display(Name \= "Human Verified")\] public bool IsHumanVerified { get; set; } }
/// \<summary\> /// Defines the contract for epistemic conflict resolution strategies (v1.0). /// \</summary\> public interface IConflictResolutionStrategy { /// \<summary\> /// Evaluates conflicting assertions and returns a resolved sequence of assertions. /// \</summary\> /// \<param name="assertions"\>The raw, conflicting assertions gathered from memory nodes.\</param\> /// \<returns\>A filtered or synthesized collection of assertions based on the strategy.\</returns\> IEnumerable\<MemoryAssertion\> ResolveConflicts(IEnumerable\<MemoryAssertion\> assertions); }
/// \<summary\> /// Resolves conflicts by selecting the assertion with the most recent timestamp. /// Stale evidence is inherently discarded. Best utilized for highly volatile state changes. /// \</summary\> public class LatestUpdateStrategy : IConflictResolutionStrategy { public IEnumerable\<MemoryAssertion\> ResolveConflicts(IEnumerable\<MemoryAssertion\> assertions) { if (assertions \== null || \!assertions.Any()) return Enumerable.Empty\<MemoryAssertion\>();
var latest \= assertions.OrderByDescending(a \=\> a.RecordedAt).First(); return new List\<MemoryAssertion\> { latest }; } }
/// \<summary\> /// Resolves conflicts by selecting the assertion with the highest calibrated confidence score. /// Human-verified assertions take precedence. Tie-breaking is handled chronologically. /// \</summary\> public class HighestConfidenceStrategy : IConflictResolutionStrategy { public IEnumerable\<MemoryAssertion\> ResolveConflicts(IEnumerable\<MemoryAssertion\> assertions) { if (assertions \== null || \!assertions.Any()) return Enumerable.Empty\<MemoryAssertion\>();
var highest \= assertions .OrderByDescending(a \=\> a.IsHumanVerified) // Human verification acts as ultimate tie-breaker .ThenByDescending(a \=\> a.Confidence) .ThenByDescending(a \=\> a.RecordedAt) .First();
return new List\<MemoryAssertion\> { highest }; } }
/// \<summary\> /// Synthesizes a new assertion by performing a confidence-weighted average of numeric assertions. /// Non-numeric data cannot be mathematically combined and throws an exception to preserve stability. /// Correlated agents providing duplicate scores are averaged to prevent clustering bias. /// \</summary\> public class ConfidenceWeightedStrategy : IConflictResolutionStrategy { public IEnumerable\<MemoryAssertion\> ResolveConflicts(IEnumerable\<MemoryAssertion\> assertions) { if (assertions \== null || \!assertions.Any()) return Enumerable.Empty\<MemoryAssertion\>();
decimal weightedSum \= 0; decimal totalConfidence \= 0;
// Deduplicate highly correlated agents to prevent echo-chamber bias var distinctAssertions \= assertions .GroupBy(a \=\> a.SourceAgent) .Select(g \=\> g.OrderByDescending(a \=\> a.RecordedAt).First()) .ToList();
foreach (var assertion in distinctAssertions) { if (\!decimal.TryParse(assertion.Data, out decimal numericValue)) { throw new InvalidOperationException("ConfidenceWeightedStrategy requires numeric assertion data."); }
// Confidence calibration: weight is strictly bound between 0.0 and 1.0 decimal weight \= Math.Clamp(assertion.Confidence, 0.0m, 1.0m); weightedSum \+= numericValue \* weight; totalConfidence \+= weight; }
if (totalConfidence \== 0) return Enumerable.Empty\<MemoryAssertion\>();
decimal synthesizedValue \= weightedSum / totalConfidence;
// Preserve provenance by generating a synthesized assertion representing the aggregate. // Do not permanently overwrite the database records; this is a read-time projection. return new List\<MemoryAssertion\> { new MemoryAssertion { Id \= Guid.NewGuid(), SourceAgent \= 0, // 0 represents the system synthesizer Data \= synthesizedValue.ToString("G"), Confidence \= Math.Clamp(totalConfidence / distinctAssertions.Count, 0.0m, 1.0m), RecordedAt \= DateTimeOffset.UtcNow, IsHumanVerified \= false } }; } } }
By ensuring that the ResolveConflicts method signature yields an IEnumerable\<MemoryAssertion\>, the strategies avoid unilaterally flattening contradictory data into a scalar primitive. This interface design allows downstream callers to inspect the full provenance chain or the mathematical basis of a synthesized result if the policy requires auditing the decision matrix.
7. Privileged Fused Gromov-Wasserstein Alignment Service
While the operational fleets remain strictly segregated via Row-Level Security, organizational value requires identifying structural relationships between segregated subgraphs. To accomplish this, the architecture introduces a Privileged Alignment Service operating asynchronously to generate proposals for cross-fleet integration. The service evaluates graph similarity using Fused Gromov-Wasserstein (FGW) optimal transport. FGW is uniquely suited for multi-agent knowledge graphs because it computes an optimal transport plan by jointly minimizing the discrepancy between the intrinsic geometric topology of the graphs (the Gromov-Wasserstein structural cost) and the explicit feature costs of the node embeddings (the Wasserstein feature cost)30. The FGW distance is mathematically defined as: [Figure omitted from source export] Where [Figure omitted from source export] represents the semantic distances between node assertions (e.g., Euclidean distance between vector embeddings), and [Figure omitted from source export] represents the structural differences between fleet subgraphs (e.g., discrepancies in edge connectivity and traversal length)31. Because this optimization is computationally intensive, scaling at [Figure omitted from source export]32, it cannot be executed in real-time by transactional database triggers.
7.1. Architecture and Execution Boundaries
The Alignment Service must never interfere with live transactional memory or bypass standard authorization to execute INSERT statements into active memory nodes.
1. Network Segmentation and Identity: The alignment service operates in a segregated subnet under a distinct Azure AD Workload Identity. It does not share credentials with the standard application tier API.
2. Read-Only Snapshot Extraction: The service connects to a transactional replica or establishes a database connection utilizing a specialized principal granted explicit SELECT on Core.MemoryNodes and Core.MemoryEdges. RLS is configured to allow this specific principal global read access exclusively for structural extraction.
3. Data Minimization and Redaction: The extraction query strips raw assertion text, retaining only the UUIDs, fleet designations, and pre-computed vector embeddings required to perform the distance matrix calculations ([Figure omitted from source export] and [Figure omitted from source export]).
4. Offline Computation: The FGW optimal transport plan is calculated in-memory on dedicated, high-compute GPU workers to resolve the non-convex optimization problem31.
5. Proposal Generation: When the FGW algorithm discovers an alignment threshold exceeding a predefined organizational confidence interval (e.g., [Figure omitted from source export]), the service writes a directed proposal directly to the Alignment.CrossFleetEdgeProposals table.
6. Validation and Promotion: Ordinary agents cannot see these proposals. A separate deterministic process or human supervisor accesses the review queue via the Alignment.ReviewDecisions table. Upon approval, a secured stored procedure promotes the proposal into the Alignment.ApprovedCrossFleetEdges table, completing the alignment lifecycle. Key rotation for the service's database credentials occurs automatically via Azure Key Vault integration every 30 days.
8. Integration Testing Plan
Relying exclusively on EF Core's in-memory database provider is fundamentally flawed for validating this architecture. The in-memory provider does not execute T-SQL, cannot enforce ROWVERSION concurrency logic, completely ignores RLS security predicates, and does not evaluate SESSION\_CONTEXT15. Consequently, security testing must occur against a real SQL Server instance, typically orchestrated via .NET Testcontainers.
8.1. Test Container Setup and Coverage
Tests must validate both positive authorization boundaries and negative access denials to ensure defense-in-depth mechanisms operate as intended.
C\# using System.Threading.Tasks; using Xunit; using DotNet.Testcontainers.Builders; using Testcontainers.MsSql; using Microsoft.Data.SqlClient; using Dapper; using System.Linq;
public class GraphGovernanceIntegrationTests : IAsyncLifetime { private readonly MsSqlContainer \_msSqlContainer \= new MsSqlBuilder() .WithImage("mcr.microsoft.com/mssql/server:2022-latest") .Build();
public async Task InitializeAsync() { await \_msSqlContainer.StartAsync(); // Execute DDL schema setup script here, including certificates and RLS policies }
public async Task DisposeAsync() \=\> await \_msSqlContainer.DisposeAsync();
\[Fact\] public async Task RLS\_ShouldDeny\_CrossFleetReadAccess() { var connectionString \= \_msSqlContainer.GetConnectionString(); using var connection \= new SqlConnection(connectionString); await connection.OpenAsync();
// Arrange: Insert baseline data via a global admin context // ... (Assume execution of INSERT for a Node in Fleet 2\)
// Act: Impersonate Fleet 1 Agent by setting session context await connection.ExecuteAsync(@" EXEC sp\_set\_session\_context @key \= N'TenantId', @value \= 1, @read\_only \= 1; EXEC sp\_set\_session\_context @key \= N'FleetId', @value \= 1, @read\_only \= 1; ");
var accessibleNodes \= await connection.QueryAsync\<int\>( "SELECT COUNT(\*) FROM Core.MemoryNodes WHERE FleetId \= 2");
// Assert: The RLS filter predicate should silently return 0 rows Assert.Single(accessibleNodes); Assert.Equal(0, accessibleNodes.First()); }
\[Fact\] public async Task ApprovedCrossFleetAccess\_ShouldPrevent\_RecursiveTraversal() { // Act: Invoke the signed stored procedure to traverse the approved edge // The test validates that only depth=1 is returned, blocking an agent // from mapping Fleet 2's extended topology by appending arbitrary graph operators. }
\[Fact\] public async Task SpoofedSessionContext\_ShouldThrow\_ReadOnlyException() { // Act: Attempt to mutate the session context after it has been locked // Assert: SQL Server throws error 15664 (Cannot set key because it is read-only) } }
Comprehensive Coverage Matrix:
- Authorized Same-Fleet Access: Validates standard read/write execution against authorized boundaries.
- Spoofed Session Context: Evaluates attempts to call sp\_set\_session\_context again within the same connection to change FleetId (must throw an error due to @read\_only=1).
- Insert/Update Block Predicates: Verifies that inserting a row with a FleetId differing from the SESSION\_CONTEXT raises a security error rather than silently failing20.
- Conflicting Writes: Asserts that concurrent updates using older ROWVERSION byte arrays trigger a DbUpdateConcurrencyException at the EF Core layer11.
- Revoked Access: Validates that modifying the ValidUntilUtc column on an approved edge instantly terminates cross-fleet visibility.
- Concurrent Review Decisions: Validates race conditions in the approval workflow of edge proposals to ensure duplicate cross-fleet edges are not instantiated.
9. Performance Implications of RLS and Graph Traversal
The introduction of Row-Level Security and graph traversal imposes specific performance overheads on the SQL Server engine that must be mitigated through architectural design:
1. Predicate Evaluation Overhead: The fn\_GraphMemoryPredicate function executes for every row processed by the execution plan23. The architectural decision to use SESSION\_CONTEXT over complex JOIN lookups (e.g., querying an active directory table within the predicate) reduces predicate evaluation time from approximately 50ms to \<1ms per thousands of rows23.
2. Parallelism Inhibitions: Inline TVF RLS predicates can inadvertently suppress parallel query execution plans. SQL Server's optimizer occasionally restricts parallel sweeps when complex security predicates exist, leading to single-threaded execution bottlenecks21. High-throughput fleet operations should rely on precision singleton lookups (NodeId) rather than broad scanning criteria to bypass scanning latency.
3. Graph MATCH Optimization: The MATCH clause performs well for deterministic depth, relying on nested loops and hash joins under the hood. However, open-ended arbitrary length matching heavily taxes memory and tempdb space27. By replacing arbitrary depth bounds with explicit cross-fleet edge procedures, the query planner maintains predictable cardinality estimates, preventing resource exhaustion.
10. Operational Runbook for Revocation and Incident Response
When an autonomous agent exhibits erratic behavior or its credentials are compromised, rapid containment is necessary to protect the integrity of the graph memory.
10.1. Context Revocation and Compromise
If an agent or entire fleet's identity token is compromised, the incident response protocol is isolated primarily to the authentication tier, minimizing downtime for unaffected fleets:
1. Revoke Workload Identity: Terminate the Azure AD / OAuth identity issuance, invalidating the token immediately.
2. Session Termination: Issue KILL commands against all SQL Server sessions originating from the affected fleet service principals to terminate inflight queries.
3. Quarantine Memory: Execute a global update setting ValidityState \= 2 (Quarantined) for all memory nodes created by the compromised agent, relying on the SourceSystem provenance marker to target specific insertions without impacting legitimate fleet data.
4. Audit Review: Parse Security.SecurityAuditEvents for abnormal volume spikes, identifying potential bulk extraction attempts or unauthorized cross-fleet traversal probes initiated by the attacker.
10.2. Privacy and Regulatory Considerations
In environments where agents ingest conversational data containing personal or biometric information, stringent data retention and protection statutes such as the Illinois Personal Information Protection Act (PIPA) and the Biometric Information Privacy Act (BIPA) apply5. Because BIPA severely penalizes the unauthorized storage or transfer of biometric templates, the FGW Alignment Service must proactively exclude any agent embeddings that mathematically map to face geometry, voiceprints, or specific health telemetry. Furthermore, PIPA mandates the notification of security breaches8. The architecture's rigorous use of SESSION\_CONTEXT combined with block predicates ensures that a breach of Fleet A's application tier provides zero mathematical ability to extract Fleet B's data, strictly bounding the regulatory notification radius and legal liability to the affected fleet alone.
11. Remaining Security Risks
While the architecture provides robust defense-in-depth, several residual vulnerabilities require ongoing monitoring:
1. Data Inference via Aggregate Queries: While block predicates prevent direct row access, poorly constructed alignment reviews might inadvertently leak aggregated statistics. If a human reviewer approves a cross-fleet edge titled "Top Performing Sales Customer", an agent inferring metadata about the edge may glean financial performance metrics of another fleet without reading the underlying rows.
2. Side-Channel Leakage via Timing Analysis: As previously modeled, timing side-channels are an inherent vulnerability when indexes are shared across tenants protected by RLS1. If an attacker successfully bypasses the ORM to execute arbitrary SQL, they can measure response times of index seeks to infer the existence of hidden nodes. Complete mitigation requires physical database sharding, which breaks the graph alignment capability.
3. Semantic Poisoning: A malicious insider possessing valid fleet credentials can intentionally generate adversarial edge relationships or prompt-injected nodes. Because the actor operates entirely within valid RLS bounds, the database engine cannot detect semantic malice. Detection must rely on secondary AI-driven anomaly scanning models analyzing the MemoryAssertions tables asynchronously.
4. Cryptographic Certificate Expiration: The mechanism enabling secure cross-fleet access relies on a certificate-signed stored procedure. Operational failure to rotate or renew this certificate prior to expiration will result in a total denial-of-service for legitimate cross-fleet traversal, isolating the fleets abruptly.
By enforcing rigid isolation at the storage tier, dynamically restricting operational context via locked session variables, and promoting structural alignment exclusively through a privileged offline optimal transport mechanism, this governance architecture establishes a secure, mathematically resilient foundation for enterprise-scale multi-agent knowledge repositories.
Works cited
1. RLS Side Channels: Investigating Leakage of Row-Level Security Protected Data Through Query Execution Time \- cs.tau.ac.il, https://www.cs.tau.ac.il/\~mad/publications/sigmod2023-rls.pdf
2. RLS Side Channels: Investigating Leakage of Row-Level Security Protected Data Through Query Execution Time | Request PDF \- ResearchGate, https://www.researchgate.net/publication/371513613\_RLS\_Side\_Channels\_Investigating\_Leakage\_of\_Row-Level\_Security\_Protected\_Data\_Through\_Query\_Execution\_Time
3. SQL Server Row-Level Security: Attacks & vulnerabilities (complete guide, part five), https://www.red-gate.com/simple-talk/databases/sql-server/sql-server-row-level-security-deep-dive-part-5-rls-attacks/
4. How to detect and mitigate Row-Level Security attacks in SQL Server (complete guide, part six) | Simple Talk \- Redgate, https://www.red-gate.com/simple-talk/databases/sql-server/rls\_attack\_mitigations\_and\_summary/
5. ASSURANCE OF VOLUNTARY COMPLIANCE This Assurance of Voluntary Compliance1 (“Assurance”) is entered into by the Attorneys Gen \- Mass.gov, https://www.mass.gov/doc/t-mobile-aod-massachusetts/download
6. AI Surveillance Privacy: Balancing Security and Privacy Rights \- VOLT AI, https://volt.ai/blog/ai-surveillance-privacy-balancing-security-and-privacy-rights
7. Face Recognition Door Lock System for Apartment Buildings and Offices \- Swiftlane, https://swiftlane.com/blog/face-recognition-door-access-control/
8. HIPAA Compliance in Illinois: The 2026 Guide for Hospitals, FQHCs, and Clinics | Medcurity, https://medcurity.com/hipaa-compliance-illinois/
9. Illinois Cybersecurity Laws You Should Know (2026) \- PivIT Strategy, https://pivitstrategy.com/illinois-cybersecurity-laws-you-should-know-2026/
10. Transaction Locking and Row Versioning Guide \- SQL Server \- Microsoft Learn, https://learn.microsoft.com/en-us/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver17
11. Concurrency Handling with RowVersion in EF Core \- Medium, https://medium.com/@rohitsakhare/concurrency-handling-with-rowversion-in-ef-core-10fd0215d459
12. Handling Concurrency Conflicts \- EF Core \- Microsoft Learn, https://learn.microsoft.com/en-us/ef/core/saving/concurrency
13. SQL Server Row-Level Security: Integration, anti-patterns, and alternatives (complete guide, part four) \- Redgate, https://www.red-gate.com/simple-talk/databases/sql-server/sql-server-row-level-security-deep-dive-alternatives-to-rls/
14. azure-content/articles/app-service-web/web-sites-dotnet-entity-framework-row-level-security.md at master \- GitHub, https://github.com/Huachao/azure-content/blob/master/articles/app-service-web/web-sites-dotnet-entity-framework-row-level-security.md
15. How to Design a Multi-Tenant Data Isolation Strategy on Azure SQL Database \- OneUptime, https://oneuptime.com/blog/post/2026-02-16-how-to-design-a-multi-tenant-data-isolation-strategy-on-azure-sql-database-using-row-level-security/view
16. SQL Server 2016 Community Technology Preview 3.0 is available \- Microsoft, https://www.microsoft.com/en-us/sql-server/blog/2015/10/28/sql-server-2016-community-technology-preview-3-0-is-available/
17. Exam Ref 70-764 Administering a SQL Database Infrastructure 978-1509303830, https://dokumen.pub/exam-ref-70-764-administering-a-sql-database-infrastructure-978-1509303830.html
18. How to set CONTEXT\_INFO on Entity Framework connection \- Stack Overflow, https://stackoverflow.com/questions/44637865/how-to-set-context-info-on-entity-framework-connection
19. Implementing Row-Level Security (RLS) for Multi-Tenant Data (SQL Server \+ ASP.NET Core) \- C\# Corner, https://www.c-sharpcorner.com/article/implementing-row-level-security-rls-for-multi-tenant-data-sql-server-asp-ne/
20. Row-Level Security \- SQL Server | Microsoft Learn, https://learn.microsoft.com/en-us/sql/relational-databases/security/row-level-security?view=sql-server-ver17
21. Row-Level Security Can Slow Down Queries. Index For It. \- Brent Ozar Unlimited®, https://www.brentozar.com/archive/2026/03/row-level-security-can-slow-down-queries-index-for-it/
22. What are the performance impact will happen when we implement RLS for azure sql database \- Microsoft Learn, https://learn.microsoft.com/en-us/answers/questions/1078822/what-are-the-performance-impact-will-happen-when-w
23. SQL Server Row-Level Security: Performance, tuning, and troubleshooting (complete guide, part three) | Simple Talk \- Redgate, https://www.red-gate.com/simple-talk/databases/sql-server/sql-server-rls-performance-and-troubleshooting/
24. Row-Level Security: Performance and common patterns | Microsoft Community Hub, https://techcommunity.microsoft.com/blog/sqlserver/row-level-security-performance-and-common-patterns/384367
25. Packaging Permissions in Stored Procedures \- Erland Sommarskog, https://www.sommarskog.se/grantperm.html
26. MATCH (SQL Graph) \- SQL Server \- Microsoft Learn, https://learn.microsoft.com/en-us/sql/t-sql/queries/match-sql-graph?view=sql-server-ver17
27. SQL Recursive Queries and CTEs: Tutorial with Examples (2026) \- AI2SQL, https://builder.ai2sql.io/blog/sql-recursive-queries-guide
28. How to Limit CTE Recursion Depth but Select Generic Table? \- Stack Overflow, https://stackoverflow.com/questions/8885170/how-to-limit-cte-recursion-depth-but-select-generic-table
29. Implement row-level security with session context \- Data API builder \- Microsoft Learn, https://learn.microsoft.com/en-us/azure/data-api-builder/concept/security/row-level-security
30. Gromov-Wasserstein Learning for Graph Matching and Node Embedding, https://proceedings.mlr.press/v97/xu19b/xu19b.pdf
31. Fused Gromov-Wasserstein Transport \- Emergent Mind, https://www.emergentmind.com/topics/fused-gromov-wasserstein-optimal-transport
32. Fused Gromov-Wasserstein Alignment for Graph Edit Distance Computation and Beyond \- VLDB Endowment, https://www.vldb.org/pvldb/vol18/p3641-tang.pdf
33. A Fused Gromov-Wasserstein Framework for Unsupervised Knowledge Graph Entity Alignment \- ACL Anthology, https://aclanthology.org/2023.findings-acl.205.pdf
34. Fused Gromov-Wasserstein Alignment for Graph Edit Distance Computation and Beyond, https://researchportal.hkust.edu.hk/en/publications/fused-gromov-wasserstein-alignment-for-graph-edit-distance-comput/
35. SQL Server Row-Level Security: Setup, access predicates, and examples (complete guide, part two) \- Redgate, https://www.red-gate.com/simple-talk/databases/sql-server/sql-server-rls-setup/
36. Cumulative update 18 for SQL Server 2022 (KB5050771) \- Microsoft Learn, https://learn.microsoft.com/en-us/troubleshoot/sql/releases/sqlserver-2022/cumulativeupdate18
37. Ready, SET, go \-How does SQL Server handle Recursive CTE's, https://www.sqlshack.com/ready-set-go-sql-server-handle-recursive-ctes/