AI Apps | The .NET Blog

SQL Server 2025 als database die klaar is voor agents: beveiliging, back-up en MCP in één engine

Emiliano Montesdeoca — Sun, 26 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Voor de originele versie, klik hier.

Ik heb de Polyglot Tax-serie van Aditya Badramraju met veel interesse gevolgd. Delen 1-3 bouwden een overtuigend verhaal voor SQL Server 2025 als een echt multi-model database — JSON, graph, vector en relationele data allemaal in één engine met een uniforme queryplanner. Deel 4 sluit de serie af met de onderdelen die echt bepalen of je deze architectuur in productie zou vertrouwen.

Spoiler: het productieverhaal is sterk.

Eén Beveiligingsmodel voor Alle Datamodellen

Dat is het lastige aan polyglot stacks: wanneer een auditor vraagt “bewijs dat Tenant A de data van Tenant B niet kan zien”, moet je die vraag voor elke database apart beantwoorden. Vijf databases, vijf beveiligingsmodellen, vijf bewijzen.

Met SQL Server 2025 definieer je één Row-Level Security-policy en die dekt alle datamodellen:

CREATE FUNCTION dbo.fn_TenantFilter(@TenantID INT)
RETURNS TABLE WITH SCHEMABINDING
AS RETURN SELECT 1 AS fn_result
WHERE @TenantID = CAST(SESSION_CONTEXT(N'TenantID') AS INT);

CREATE SECURITY POLICY TenantIsolation
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Customers, -- Relational
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Events, -- JSON data
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Relationships, -- Graph edges
ADD FILTER PREDICATE dbo.fn_TenantFilter(TenantID)
ON dbo.Embeddings -- Vector data
WITH (STATE = ON);

Vanaf dat moment wordt elke query — relationele joins, JSON-path queries, graph traversals, vector similarity searches — automatisch per tenant gefilterd. De engine injecteert de predicate in het execution plan voordat er data uit storage vertrekt. Je aanroepende code hoeft niet overal WHERE TenantID = @id te schrijven. Je test de policy één keer.

De lagen werken ook samen: Dynamic Data Masking voor kolommen die niet de volledige waarde aan bepaalde rollen mogen tonen, Always Encrypted voor end-to-end encryptie (zelfs DBA’s kunnen het niet lezen), en stored procedures als permissiegrens zodat agents alleen aanroepen wat je expliciet hebt vrijgegeven.

Dit is het deel van de architectuur dat het belangrijkst is voor compliance-zware SaaS. Eén policy, één bewijs.

Geconsolideerde Back-up = Atomisch Herstel

Eén statement, alle datamodellen, één consistent punt in de tijd:

BACKUP DATABASE MultiModelApp
TO URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH COMPRESSION, ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

RESTORE DATABASE MultiModelApp
FROM URL = 'https://storage.blob.core.windows.net/backups/MultiModelApp.bak'
WITH STOPAT = '2026-02-01 10:30:00';

In een polyglot stack betekent point-in-time recovery over vijf databases dat je vijf restore-operaties moet coördineren en maar moet hopen dat de timestamps binnen een seconde of twee overeenkomen. Voor financiële data is die tweeseconden-inconsistentie onacceptabel. Met één database, één transaction log en één restore is recovery per definitie atomisch.

Ledger-tabellen voor Manipulatiebestendige Audittrails

Voor gereguleerde sectoren heb je meer nodig dan “we hebben logs”. Je hebt cryptografisch bewijs nodig dat die logs niet zijn aangepast:

CREATE TABLE FinancialTransactions (
 TransactionID INT PRIMARY KEY,
 AccountID INT NOT NULL,
 Amount MONEY NOT NULL,
 TransactionType NVARCHAR(20),
 TransactionDate DATETIME2 DEFAULT SYSUTCDATETIME()
)
WITH (SYSTEM_VERSIONING = ON, LEDGER = ON);

Elke insert, update en delete wordt cryptografisch gehashed in een blockchain-achtige structuur. Je kunt een auditor wiskundig aantonen dat een rij niet is gemanipuleerd sinds die is geschreven. In een polyglot stack bestaat die mogelijkheid niet uniform over al je databases.

MCP-integratie: Agents Zonder Handmatig Geschreven Middleware

De serie werkte hier naartoe: SQL Server 2025 ondersteunt SQL MCP Server direct, wat betekent dat je agents de database kunnen aanroepen via natuurlijke tool calls zonder dat je voor elke operatie middleware hoeft te schrijven.

Combineer dat met stored procedures als permissiegrens en Row-Level Security op engine-niveau, en je krijgt een model waarin:

De agent een tool aanroept, bijvoorbeeld “haal de klantcontext op voor account 12345”
MCP dat vertaalt naar de stored procedure die jij hebt gedefinieerd
De SQL-engine tenant-isolatie en column masking automatisch afdwingt
De agent precies de data krijgt die hij mag zien

Geen middlewarelaag. Geen risico op ad-hoc query injection. De engine verzorgt de autorisatie, niet de agent.

Waarom Dit Belangrijk Is Voor .NET-ontwikkelaars

Als je .NET-services bouwt en SQL Server je primaire opslag is, dan is de boodschap van deze serie: je hoeft geen Redis toe te voegen voor caching, geen graph database voor relaties en geen vector store voor embeddings. SQL Server 2025 doet dat allemaal — met betere operationele consistentie dan een polyglot stack en met uniforme beveiliging die echt auditeerbaar is.

De MCP-integratie betekent dat je Semantic Kernel-agents of Microsoft Agent Framework-workflows via dezelfde SQL MCP Server met je datalaag kunnen communiceren, met dezelfde beveiligingsgaranties die je ook op menselijke queries zou toepassen.

Afronding

De Polyglot Tax-serie is de moeite waard om van begin tot eind te lezen. Delen 1-3 bewijzen het queryplannerverhaal. Deel 4 bewijst het productieverhaal. Voor .NET-ontwikkelaars die agent-first of AI-augmented applicaties op Azure SQL bouwen, verdient deze architectuur serieuze overweging.

Originele post van Aditya Badramraju: The Polyglot Tax – Part 4.

68 Minuten per Dag Code Opnieuw Uitleggen aan Copilot? Daar is een Oplossing voor

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Dit bericht is automatisch vertaald. Klik hier voor de originele versie.

Ken je dat moment waarop je Copilot-sessie /compact bereikt en de agent compleet vergeet waar je mee bezig was? De volgende vijf minuten leg je opnieuw de mapstructuur, de mislukte test en de drie benaderingen die je al hebt geprobeerd uit. Daarna gebeurt het weer. En weer.

Desi Villanueva timede het: 68 minuten per dag — alleen al aan heroriëntatie. Niet aan code schrijven. Niet aan PR’s reviewen. Alleen de AI weer bijpraten over wat hij al wist.

Blijkt dat daar een concrete reden voor is, en een concrete oplossing.

De leugen van het contextvenster

Je agent komt met een groot getal op de doos. 200K tokens. Klinkt enorm. In de praktijk is het een bovengrens, geen garantie.

Dit is de echte rekensom:

200K totale context
Minus ongeveer 65K voor MCP-tools die bij startup worden geladen (~33%)
Minus ongeveer 10K voor instructiebestanden zoals AGENTS.md of copilot-instructions.md

Dat laat je ongeveer 125K over voordat je ook maar een woord typt. En het wordt erger — LLM’s degraderen niet netjes terwijl de context volloopt. Ze lopen vast rond 60% van de capaciteit. Het model begint dingen te verliezen die 30 turns geleden zijn genoemd, spreekt eerdere antwoorden tegen en hallucineert bestandsnamen die het 10 minuten eerder nog vol vertrouwen noemde. De industrie noemt dit het “lost in the middle”-probleem.

Effectieve limiet: 45K tokens voordat de kwaliteit inzakt. Dat zijn misschien 20-30 actieve gespreksbeurten voordat de agent begint af te dwalen. Daarom zit je elke 45 minuten op /compact — niet omdat je 200K tokens hebt volgepropt, maar omdat het model al bij 120K begint te verpieteren.

De compactiebelasting

Elke /compact kost je flow state. Je zit diep in een debugsessie. De gedeelde context is in 30 minuten opgebouwd. De agent kent de mapstructuur, de mislukte test en de hypothese. Dan verschijnt de waarschuwing.

Negeer het → de agent wordt geleidelijk dommer en gaat oude state hallucinerend invullen
Draai /compact → de agent krijgt een samenvatting van twee alinea’s van een onderzoek van 30 minuten

In beide gevallen verlies je. In beide gevallen ben je je eigen project aan het navertellen alsof je een nieuwe collega op dag één bent.

Het venijnige deel? Het geheugen bestaat al. Copilot CLI schrijft elke sessie weg naar een lokale SQLite-database op ~/.copilot/session-store.db — elk aangeraakt bestand, elke turn, elk checkpoint. Alles staat op schijf. De agent kan het alleen niet lezen.

auto-memory: een recall-laag, geen geheugensysteem

Dat is het kernidee achter auto-memory: bouw geen nieuw geheugensysteem — bouw een read-only querylaag bovenop wat er al is.

pip install auto-memory

Ongeveer 1.900 regels Python. Geen afhankelijkheden. Installeert in 30 seconden.

In plaats van de context te overspoelen met grep-resultaten, geef je de agent chirurgische toegang tot wat echt belangrijk is:

Operatie	Tokens	Wat je krijgt
`grep -r "auth" src/`	~5,000–10,000	500 resultaten, waarvan de meeste irrelevant zijn
`find . -name "*.py"`	~2,000	Alle Python-bestanden, zonder context
Heroriëntatie van de agent	~2,000	Jij legt uit wat hij eigenlijk al had moeten weten
`auto-memory files --json --limit 10`	~50	De 10 bestanden waaraan je gisteren hebt gewerkt

Dat is een verbetering van 200x. De agent slaat het archeologische graafwerk over en gaat meteen naar wat ertoe doet.

De aanbevolen flow: als je richting 50-70% contextgebruik gaat, draai dan /clear en prompt vervolgens met: “bekijk de laatste sessies waarin we onderwerp X bespraken”. In plaats van 12K tokens te verbranden aan blinde zoekopdrachten, haalt auto-memory de relevante context in 50 tokens op.

Waarom dit belangrijk is voor .NET-ontwikkelaars

Als je GitHub Copilot CLI gebruikt voor .NET-werk — services scaffolden, EF Core-queries debuggen, itereren op Blazor-componenten — dan raakt het context rot-probleem je net zo hard. Complexe oplossingen met meerdere projecten, gedeelde libraries en diepe call chains zijn precies het soort codebase waar de agent het snelst de draad kwijt raakt.

De installgids legt uit hoe je Copilot CLI erop laat wijzen. Het is een eenmalige setup.

Eerlijk? 68 minuten per dag terugkrijgen is geen klein quality-of-life-tweak. Dat is bijna 6 uur per week.

Afsluiting

Context rot is een echte architecturale beperking, geen bug die zomaar gepatcht gaat worden. auto-memory omzeilt dat door je agent een goedkope, precieze recall-mechaniek te geven in plaats van een dure, lawaaierige herverkenning. Als je serieus AI-ondersteund ontwikkelt met GitHub Copilot CLI, is die installatie van 30 seconden het waard.

Bekijk het: auto-memory op GitHub. Oorspronkelijke post van Desi Villanueva: I Wasted 68 Minutes a Day Re-Explaining My Code.