در بسیاری موارد (مانند سیستم‌های Multi Tenant) لازم هست تا مانع از این شویم که داده‌های کاربران با هم تداخل پیدا کند و یا آن‌ها بتوانند به داده‌های هم دسترسی داشته باشند. مثلا می‌خواهیم کاربران هر شعبه از سازمان، تنها به اطلاعات شعبه خودشان دسترسی داشته باشند. یک کار ساده، پردردسر و بسیار بد آن است که از برنامه نویس‌ها بخواهیم در هر کوئری عبارتی را اضافه کنند که سطح دسترسی را چک کند. اما اگر برنامه نویس جایی فراموش کرد چی؟ اگر سیاست دسترسی پیچیده‌تر بود و مبنی بر پارامتر‌های مختلف محاسبه می‌شد چه خواهد شد؟ این راهکار در حجم بزرگ غیر مطمئن و غیرقابل نگهداری است.

در EF6 قابلیتی به نام Interception وجود دارد که با استفاده از آن می‌توان سیاست دسترسی به داده را در لایه‌های پایینی طراحی کرد. در این روش برنامه نویس لایه هایی بالا، بدون آنکه درگیر مفاهیمی مانند Tenant و سیاست‌ها بشود، می‌تواند به راحتی کوئری هایش را تولید کند. سپس EF به طور خودکار تغییری در کوئری‌ها خواهد داد تا دسترسی‌های لازم رعایت کرده باشد. برای اینکار می‌توانید از کتابخانه EntityFramework.DynamicFilters استفاده کنید.

این روش هم علی رغم همه مزایا معایبی هم دارد. اگر بخواهیم از همین پایگاه داده استفاده کنیم ولی در محیط دات نت نباشیم و یا از EF6 استفاده نکنیم، دوباره مشکلات اغاز می‌شوند. سیاست‌ها را باید در همه جا کپی کنیم و در صورت لزوم هم، مجددا همه را تغییر دهیم.

در SQL Server 2016 قابلیتی به نام Row Level Security وجود دارد، که به ما اجازه می‌دهد سیاست‌های دسترسی با داده را در لایه پایگاه داده متمرکز کنیم. در این صورت اپلیکشن‌ها هیچگونه آگاهی ایی نسبت به سیاست‌ها نخواهند داشت و درگیر این مفاهیم در سطح کد نخواهیم بود. همچنین در صورت لزوم به تغییر سیاست ها، فقط لازم است تغییراتی را در پایگاه داده بدهیم. با این روش، به هر طریقی و از هر ابزاری که به پایگاه داده کوئری هایمان را ارسال کنیم، سیاست‌های دسترسی به داده اعمال خواهند شد و امنیت بالا و البته ریزدانه ای (granular) را خواهیم داشت.

در مثال زیر خواهیم دید که چگونه می‌توان با استفاده از EF6 از ویژگی RLS بهره برد. این مثال یکی دیگر از کاربرد‌های Interception را نیز توضیح می‌دهد.