Allowlisting vs DLP vs CASB: Stopping AI Data Exfiltration

Three controls get recommended for the same job, and they are not the same job. Application allowlisting, data loss prevention and a cloud access security broker all appear in the answer to "how do we stop people putting company data into AI tools", and each one is correct at a different point in the path that data takes.

The practical question for a small business or a regulated firm is not which of the three is best. It is which one catches the case you actually have, and what each one is blind to. It is also a question of where you stop spending. This allowlisting vs DLP vs CASB comparison states what each control can see, cites the documented limits rather than a marketing claim, and ends with a decision table you can take to a budget conversation.

The path data takes, and where each control sits on it

Exfiltration through an AI tool is not one event. It is a sequence, and every control in this comparison intercepts a different step.

• Something runs on the endpoint. A downloaded client, a portable executable, a browser extension, a script. Application allowlisting acts here.
• A destination is reached. A domain resolves, a connection opens, a request is sent. DNS filtering, a firewall and an inline secure web gateway act here.
• A payload is created. A file is uploaded, text is pasted, an image is attached. Content inspection acts here, at the endpoint or at the proxy.
• Data crosses the boundary. The service on the other side now has a copy. Identity controls decide whether the app was ever authorized to be connected to your tenant in the first place.
• Something is left behind. A log entry, an audit record, a session. Monitoring acts here, and it is the only place where you find out what happened after the fact.

NIST's zero trust guidance is the cleanest language for the composition. NIST SP 800-207 describes trust as never granted implicitly but continually evaluated, and places a policy enforcement point between a subject and a resource. That point enables the connection and monitors it, then terminates it when policy says so. Allowlisting, DLP and a CASB are three enforcement points on one connection. None of them is the architecture; the architecture is that there is more than one.

Application allowlisting: what it catches, and its hard limit

Allowlisting answers one question with unusual precision: may this program execute on this machine. CIS Critical Security Controls v8.1 puts that in Safeguard 2.5, using technical controls such as application allowlisting so that only authorized software can execute or be accessed. NIST SP 800-53 CM-7, Least Functionality, is the same requirement stated from the control catalog side.

On Windows the mechanisms are mature and the rule types are well documented. AppLocker enforces by Publisher, Path and File hash, and Microsoft recommends the publisher condition because a digital signature survives an application update and a move to a different directory. A path or hash rule breaks on both. AppLocker covers packaged apps, executables, Windows Installer files, scripts and DLLs. Its edition requirements have shifted: before Windows 10 version 2004, Group Policy deployment worked only on Enterprise and Server editions, while MDM deployment worked on all editions.

App Control for Business, commonly called WDAC, is the stronger control and controls drivers as well as applications. Its managed installer option trusts binaries laid down by an approved installer such as the Intune management extension, and Intune manages those policies through the ApplicationControl configuration service provider. That combination is what makes allowlisting survivable at scale: without a trusted installer path, every application update becomes a support ticket.

Other platforms have real equivalents, not merely similar products. Google's open source Santa is a binary and file access authorization system for macOS, shipped as a system extension plus daemon and distributed by MDM. On Red Hat Enterprise Linux, fapolicyd allows only trusted applications, including those listed in the RPM database and an explicit allow list, and Red Hat publishes an Ansible system role to configure it.

What allowlisting catches that the other two do not. A user who downloads a desktop AI client and installs it catches nothing at the network if the client calls an endpoint the category vendor has not seen yet. Allowlisting refuses the client before it ever opens a socket. The same applies to a portable executable on a USB stick, an unsigned helper a contractor emailed, and an installer that bundles an assistant nobody asked for. This is why allowlisting is the strongest single control against the local client class, and why CIS Controls v8.1 names it as its own safeguard (2.5) rather than leaving it as a nice to have.

The hard limit. Allowlisting cannot see a browser tab. Chrome, Edge, Firefox and Safari are approved applications by definition; a user typing a customer list into a chatbot is using an authorized program to reach an unauthorized destination. The same gap covers the assistant built into an operating system, which in Microsoft's case is a policy switch rather than an application: Windows 11 Copilot is controlled by the WindowsAI policy setting TurnOffWindowsCopilot at user scope on Pro, Enterprise, Education and IoT Enterprise editions, and Edge Copilot is controlled through Microsoft365CopilotChatIconEnabled, HubsSidebarEnabled and EdgeEntraCopilotPageContext. Those are administrative toggles sitting beside the allowlist, not part of it.

Browser extensions are the third case. Chrome's enterprise policy documentation describes an extension install blocklist that accepts a wildcard. With a wildcard, every extension is blocked by default. Installed extensions are disabled, and users cannot re enable them. That is a browser policy, and a program that only does allowlisting will not have it set.

Data loss prevention: content at the point of egress, and four documented blind spots

DLP answers a different question: does this specific content match something I have decided must not leave. Everything about the control follows from the word "match".

Microsoft's Purview implementation is the most thoroughly documented example. A sensitive information type is a pattern classifier with four components: a primary element, which can be a regular expression with or without checksum validation, a keyword list, a keyword dictionary, or a function; supporting elements that act as corroborating evidence; a confidence level that runs from high through medium down to low; and proximity, the character distance allowed between the primary and supporting elements. Exact data match types go further and match against a hashed table of your own records rather than a generic pattern. Microsoft publishes separate guidance on reducing false positives with sensitive information types and with exact data match. Trainable classifiers get their own guidance, and so does document fingerprinting. The existence of that guidance is itself the honest summary of DLP: precision is a tuning problem you work on continuously.

Endpoint DLP has an unusually specific activity list, which is the best available map of where it acts. Microsoft documents monitoring and enforcement for the following activities.

• Upload to a restricted cloud service domain, or access from an unallowed browser.
• Paste to supported browsers, where the evaluation is performed on the pasted content itself regardless of how the source item was classified.
• Copy to clipboard.
• Copy to USB removable device.
• Copy to a network share.
• Print.
• Copy or move using an unallowed Bluetooth app.
• Copy or move using a remote desktop session.

The paste rule matters most for the AI case, because pasting text into a chatbot has no file for a file based control to inspect.

For generative AI specifically, endpoint DLP carries a preconfigured sensitive service domain group for generative AI websites, and only a documented list of AI sites is supported. Purview DSPM for AI ships pre built policies on top of it, including a policy that blocks sensitive information from being submitted to AI apps in Edge and one that blocks elevated risk users from submitting prompts at all. The prerequisites are the part people miss: devices must be onboarded to Purview, and the Purview browser extension must be deployed to Windows users for third party generative AI site discovery and for endpoint DLP when the browser is Chrome. OCR scanning of images for sensitive information exists but is an optional feature that must be enabled at the tenant level.

What DLP catches that the others do not. It is the only one of the three that can tell the difference between two uploads to the same destination: one containing a spreadsheet of account numbers and one containing a public price list. A destination based control treats both identically. Content inspection also gives you the audit artifact that matters in an incident, which is what was in the payload, not merely where it went.

Blind spot one: encryption. Microsoft states that endpoint DLP does not decrypt protected files to scan for sensitive content, so when policies rest on sensitive information types, encrypted files are not inspected. The engine has a different lever, a condition for a password protected attachment, which reacts to the container rather than reading inside it.

Blind spot two: the analog hole. Once data is rendered on a screen, a photograph of that screen produces no file transfer for a file level control to inspect. DLP monitors file transfers and network traffic; it cannot see a phone camera pointed at a monitor.

Blind spot three: content the pattern does not describe. Sensitive information types are formats, and exact data match is your own records. A strategic plan, a novel mechanical design, or an original code snippet that matches neither is not sensitive to the matcher until someone builds a classifier for it. Trainable classifiers reduce the gap and do not close it, and they add their own error rate.

Blind spot four: the channel it cannot see. A copy of a document on a personal device, in a personal cloud account, or sent from a personal mailbox produces no telemetry in your DLP console. That is not a tuning problem; it is a scope boundary.

CASB: cloud service governance, and why the deployment mode decides everything

The category name hides the most consequential difference in the market. Gartner's definition, as vendors publish it, describes cloud access security brokers as on premises or cloud based security policy enforcement points placed between cloud service consumers and cloud service providers. Those points combine and interject enterprise security policies as cloud resources are accessed. That definition describes a position, not a mechanism. The mechanism is what determines whether the product can stop your actual case.

API and app connector mode. The CASB uses the SaaS provider's own API. Microsoft documents the consequences directly: each connected cloud service has its own framework and API limitations such as throttling, API limits and dynamic time shifting windows; operations such as scanning all the files in a tenant require many API calls and are spread over a longer period; and some policies run for hours or days. API mode is excellent at finding what already exists in a service you own, retroactively and at depth. It has a defining constraint: there must be a service to connect to. A user's personal consumer chatbot account, created with a personal email address, has no connector and no API for you to call.

Inline and forward proxy mode. The CASB sits in the traffic path and sees requests as they happen, which is what allows a decision before the upload lands. Netskope positions its own CASB as inline, delivered through its secure web gateway and SSE offerings, and it also offers API modes. It contrasts this with vendors that offer API only deployment. This is the mode that can act on a consumer account, because it does not need the service's cooperation.

Reverse proxy and Conditional Access App Control. The broker sits between users and specific cloud applications rather than routing all traffic. Microsoft documents Conditional Access App Control as providing in session controls through Edge for Business or the Defender for Cloud Apps reverse proxy, and its coexistence guidance with Entra Internet Access distinguishes browser based reverse proxy controls from a forward proxy.

The discovery capability is where the category is strongest and most underrated. Microsoft Defender for Cloud Apps maintains a cloud app catalog of over 31,000 discoverable apps scored on more than 90 risk factors, with a Generative AI category. Each app can be tagged as sanctioned or unsanctioned, and a third tag, monitored, sits between the two. That is the reconnaissance layer that tells you which conversation to have next.

What a CASB catches that the others do not. It works in real time, on a per service basis, and it carries context for the user and for the session, for services it can see. It answers which AI app is involved. It also answers who the user is and which tenant is involved, whether the destination is sanctioned and, with in session controls, what the user is doing inside the app rather than only whether they got there. That combination, discovery plus destination plus session, is not available from allowlisting or from endpoint DLP alone.

The limit, stated plainly. An API only deployment cannot stop a personal account on a consumer service, and an inline deployment cannot stop anything that does not traverse it. Neither mode can evaluate a payload it cannot decrypt, so the TLS inspection decision determines whether the CASB sees destinations or contents. And the discovery data is a map, not a control: marking an app unsanctioned changes nothing until something enforces the mark. Microsoft's own documentation makes that dependency explicit, since unsanctioned apps are blocked automatically only when the tenant also runs Defender for Endpoint network protection or one of the named third party integrations, and otherwise a block script is exported for the customer to apply.

The identity controls that decide whether the question arises

One class of exposure is not a network event at all. A user clicks through an OAuth consent screen and grants an application access to their mail and their files, as well as their calendar. The grant persists after the tab closes. Microsoft documents this as consent phishing, pairs it with app governance as the control, and provides the settings: restrict or disable user consent to applications in Entra ID, and enable the admin consent workflow so users can request approval for an application they cannot consent to themselves.

Conditional Access adds device level conditions, and Microsoft attaches an important warning to one of them: the device platform condition is evaluated from the user agent string, so a policy blocking unknown or unsupported platforms should be paired with a device compliance or app protection policy to reduce the risk of a spoofed agent. A policy that can be defeated by a spoofed user agent string is a weak control presented as a strong one, and it is worth knowing which of your controls have that property.

For organizations running Google Workspace instead of Microsoft 365, the equivalent levers are administrative: Gemini feature access can be turned off per service in the Admin console, and additional Google services can be switched on or off individually for the domain. Turning off the tenant controlled assistant while leaving the consumer website reachable produces a policy that reads well and changes nothing.

None of that is allowlisting, DLP or CASB, and all of it belongs in the same program. Identity controls remove the sanctioned path to an unsanctioned grant, which reduces how much traffic the other three have to catch.

Allowlisting vs DLP vs CASB: the side by side comparison

The table below is the summary. Every row traces to a source in the sections above; nothing in it is a vendor claim about completeness.

• The question it answers. Allowlisting: may this program run. DLP: is this content something that must not leave. CASB: is this cloud service sanctioned, and what is the user doing inside it.
• Where it enforces. Allowlisting on the endpoint, before execution. DLP at the endpoint activity or at the proxy, on the payload. CASB inline in the traffic path or through the provider API, at the service.
• Catches a downloaded AI client. Allowlisting yes, at execution. DLP only if the client sends classified content and the path is visible. CASB only if the destination is known and the traffic passes through it.
• Catches a browser tab to a consumer chatbot. Allowlisting no. DLP yes with network or endpoint paste rules against a listed AI site. CASB yes in inline mode, limited in API only mode.
• Catches a personal account on a personal device. None of the three from the corporate side.
• Sees content or only destination. Allowlisting neither, it sees the binary. DLP content, by design. CASB destination by default, content with TLS inspection.
• Works retroactively on data already in a SaaS service. Allowlisting no. DLP limited to the vendor's own connectors. CASB yes, this is what API mode is for.
• Fails on an encrypted archive. Allowlisting not applicable. DLP yes, documented. CASB with TLS inspection cannot inspect the payload either.
• Fails on a screenshot. All three. The analog hole defeats file level detection.
• Evidence it produces. Allowlisting an execution log per endpoint. DLP the matched payload with the rule that fired. CASB the destination, user, session and, where enabled, the captured generative AI prompt.
• Typical effort to first useful result. Allowlisting weeks, because audit mode and an exception process come first. DLP weeks to months, because sensitivity tuning never ends. CASB days for discovery, then enforcement work.

Two rows in that list are worth reading twice. The first is the personal account on a personal device, where all three fail, because no control reaches a phone on a cellular network. The second is the screenshot, where all three fail for a different reason: there is no digital artifact to match.

Decision table: allowlisting vs DLP vs CASB for a small business

A small business, meaning roughly under 100 staff without a dedicated security team, should buy the cheap layers first. The expensive ones can wait until discovery justifies them.

• Always: DNS filtering with a generative AI category, plus browser and Windows policy. Cloudflare Gateway publishes an Artificial Intelligence domain category, Cisco carries a Generative AI category through Talos in Umbrella and Secure Access, and DNSFilter ships a Generative AI category it says blocked more than 60 million generative AI requests in March 2025. On the endpoint, set the Chrome and Edge extension blocklist, disable browser DNS over HTTPS by policy so name resolution stays in your resolver, and use the WindowsAI policy to turn off Copilot where it is not wanted.
• Always: Entra user consent restriction plus the admin consent workflow. This is a setting, not a purchase, and it prevents the OAuth grant that no network control can undo.
• Next: application allowlisting, in audit mode first. On Windows this is AppLocker or App Control for Business, on macOS Santa, on Linux fapolicyd. The reason to do it early is that it is the only control here that catches a local client the category vendor has never seen, and the reason to do it slowly is that an allowlist rolled out without an exception process becomes a rebellion.
• Next: DLP scoped to the two or three data types that actually matter. Start with exact data match on the customer or patient identifiers rather than the full sensitive information type catalog, because a broad policy with a high false positive rate gets switched off. Use the pre built generative AI domain group and the paste rule, and accept that tuning continues.
• Defer: a full CASB platform. Buy it when discovery shows a measured problem with services you do not control, or when you need in session controls on sanctioned SaaS. If your stack is Microsoft 365 with Defender for Endpoint, the Defender for Cloud Apps catalog plus the automatic block of unsanctioned apps through network protection may already cover the discovery and destination job without a new vendor.

The most common small business mistake is buying the enterprise CASB first because it demos well, then discovering that the personal accounts it cannot reach were the actual traffic. The second most common is doing nothing because the full stack looks unaffordable, when the two always rows cost almost nothing.

Decision table: allowlisting vs DLP vs CASB for a regulated firm

A regulated firm is choosing controls it has to evidence rather than controls it merely has to run, whether it handles controlled unclassified information or electronic protected health information or cardholder data or customer financial records. The framework requirement usually names the control class for you.

Defense contractors and CMMC. NIST SP 800-171 Rev. 2 requirement 3.1.3 requires controlling the flow of controlled unclassified information in accordance with approved authorizations, and its discussion names enforcement points such as gateways and routers. It also names guards and encrypted tunnels, plus firewalls, including message filtering by content. Requirement 3.13.1 covers monitoring and protecting communications at external and key internal boundaries. CMMC Level 2 requirements are identical to NIST SP 800-171 R2 under 32 CFR 170.14, and a Level 2 self assessment produces a CMMC Status of Final Level 2 (Self) or Conditional Level 2 (Self) submitted to SPRS under 32 CFR 170.16. For that scope, an inline boundary control with content inspection is the control the requirement describes, and allowlisting supports the least functionality expectation. A CASB that only reports is not an enforcement point in the sense 3.1.3 uses the term.

Healthcare and HIPAA. 45 CFR 164.312 requires access control and audit controls. It also requires integrity protection and person or entity authentication, along with transmission security for electronic protected health information. The audit controls standard is the one DLP and network logging answer most directly, because it requires mechanisms that record and examine activity in systems that contain or use that information.

Financial services and GLBA. The Safeguards Rule at 16 CFR 314.4(c) requires access controls that authenticate and permit access only to authorized users, limits on each authorized user's access to what their duties need, encryption of customer information in transit over external networks and at rest. Multi factor authentication is part of the same rule. So is monitoring and logging of authorized user activity to detect unauthorized access and unauthorized use, as well as tampering. That combination maps across all three controls. Allowlisting restricts what can run. DLP protects the data in transit. A CASB or gateway covers the destination and the monitoring.

Cardholder data and PCI DSS. PCI DSS v4.0.1 Requirement 3.5.1 requires the primary account number to be unreadable wherever it is stored, and 3.5.1.1 requires keyed cryptographic hashes of the entire number when hashing is the method. That is a storage requirement rather than a transfer one, and it matters here because it defines what an exact data match policy should be looking for.

The program shape for a regulated firm is therefore: allowlisting for the least functionality evidence, DLP with exact data match for the content evidence, and an inline boundary control with a CASB function for the boundary evidence, with identity controls closing the OAuth path. The order of implementation is still cheap to expensive; the difference is that a regulated firm cannot stop after the cheap layers, because the requirement does not stop there.

Detection is not prevention, and both are needed

One failure mode deserves its own section because it is the most expensive one, and it is a purchase mistake rather than a configuration mistake. Detection tells you which AI services are in use and by whom. Prevention stops data crossing the boundary. Buying the first and believing you bought the second is how an organization ends up with a dashboard full of AI usage and no change in exposure.

The numbers argue for doing both, in that order. IBM's 2025 Cost of a Data Breach research with the Ponemon Institute, across 600 organizations, found that 13 percent had experienced a breach of an AI model or application and 8 percent did not know whether they had; among those compromised, 97 percent reported lacking AI access controls. A high level of shadow AI added USD 670,000 to the global average breach cost, and 63 percent of the organizations studied had no AI governance policies at all. Netskope's 2025 generative AI report found the top 25 percent of organizations use at least 13 generative AI apps and the top 1 percent at least 40, more than 99 percent enforce policies to reduce generative AI risk, and 83 percent block some apps.

Discovery produces the inventory those numbers describe. Prevention produces the change. The bridge between them is an approved path, because a block without an alternative moves the traffic rather than removing it. If a workload has to handle controlled or regulated data, the durable answer is often a model inside your boundary rather than a policy exception for a browser tab, which is the case for on premise AI deployment and the wider private AI solutions practice.

The honest limit of all three controls is worth stating once more, in OWASP's framing rather than ours: LLM02 in the OWASP Top 10 for LLM Applications is sensitive information disclosure, and the mitigations it lists are process and design mitigations as much as tooling. The NSA, CISA and FBI joint guidance on AI data security, published in May 2025 through the NSA AI Security Center with international partners, takes the same position: securing the data that trains and operates AI systems is a discipline spanning governance, access and monitoring rather than a single product.

For the network build itself, step by step, see how to block ChatGPT and other AI tools on your network. For the managed version, see our service for blocking unapproved AI tools.

Related reading

• AI-Powered DLP: Protect SaaS, Cloud, Email
• Zero-Trust GenAI: DLP and Prompt Injection
• Data Loss Prevention Strategy for 2026
• Data Layer Zero Trust for Quicker Breach Containment

FAQ

Which control stops AI data exfiltration: allowlisting, DLP or CASB?

None of them alone. Application allowlisting decides which programs may run, so it stops a local AI client but not a browser tab. Data loss prevention inspects content, so it catches known data patterns leaving through a channel it can see, but not a screenshot or an encrypted archive. A CASB governs cloud service use, so it is strong for reconnaissance and for services it can connect to, and weakest against a consumer account it has no API for. Each covers a different part of the same path, which is why the composition matters more than the product choice.

Can a CASB block a user typing into a personal ChatGPT account?

It depends entirely on the deployment mode. An API connector only works with a service you can connect to, and a personal consumer account has no connector and no API for you to call. An inline or forward proxy deployment sees the traffic in real time and can block the destination or, with TLS inspection, the request body. That is also why vendors describe their own roadmap as inline, and why the question to ask a CASB vendor is which mode enforces the control, not whether the feature exists.

Does application allowlisting stop AI tools from being installed?

It stops the executable forms: a downloaded desktop AI client, a portable executable, an unsigned utility. It does not stop an approved browser from reaching an unapproved website, because the browser is a legitimate allowlisted application. Allowlisting closes the local execution hole and leaves the browser hole untouched, which is why browser policy and extension control are separate settings rather than part of the same control.

What does DLP miss when someone exfiltrates data through an AI chatbot?

Four things are documented and repeatable. A screenshot of data on screen carries no file transfer to inspect. Encrypted or password protected files are not decrypted by endpoint DLP to be scanned. Content that matches no pattern, such as a strategy paragraph or a novel design description, is not sensitive to a pattern matcher. And a channel the agent cannot see, such as a personal device on a personal network, produces no telemetry at all.

What should a small business deploy first?

Start with the controls that are already paid for or nearly free: DNS filtering with a generative AI category, browser and Windows policy to remove the built in assistants, Entra user consent restrictions with an admin consent workflow, and audit logging that tells you what is on the network. Application allowlisting is next because it is the strongest single control for local execution, and it is cheap on Windows through AppLocker or App Control for Business policies managed by Intune. Pay for a CASB or an enterprise DLP suite when discovery shows a real, measured problem the free controls do not cover.

How does a regulated firm choose between the three?

Choose by the control you have to evidence, not by the category name. If you must demonstrate that only authorized software executes, allowlisting is the control and CIS Safeguard 2.5 is the citation. If you must demonstrate that controlled data cannot leave, DLP with exact data match is the control. If you must demonstrate boundary control over what the organization reaches, an inline gateway with a CASB function is the control. Most regulated programs need at least two of the three, mapped to NIST SP 800-171 3.1.3, 3.13.1 or the equivalent framework requirement.

Is detecting AI use the same problem as stopping data loss?

No, and confusing the two is common. Detection tells you which AI services are in use and by whom; it is a discovery activity, usually network or endpoint telemetry. Stopping data loss is prevention, and needs a control at the point where the data would cross the boundary. Discovery is the right first step because it tells you where prevention is worth spending, but buying detection and calling it prevention leaves the exposure in place.

Build the layers in the order your exposure demands

The useful summary of this comparison is that the three controls are not competitors. Allowlisting is the execution gate. DLP is the content gate. A CASB is the destination and session gate. A program with one of them has a hole shaped like the other two, and the hole is easy to demonstrate: a browser tab defeats allowlisting, an encrypted archive defeats DLP, and a personal consumer account defeats an API only CASB.

Petronella Technology Group, Inc. works this as a sequence rather than a purchase: discovery first with shadow AI detection, then the enforcement points that fit the exposure, through data loss prevention, managed firewall services and zero trust security design. The AI practice hub covers the option that removes the problem instead of policing it, and the network segmentation work is what keeps a single policy failure from reaching every system at once.

For a regulated program, the same work has to map to a framework you are assessed against, which is where the CMMC Level 2 self assessment and CMMC Registered Provider Organization pages are relevant, alongside the 2026 security awareness training that makes the policy something employees understand rather than route around.

If you want to know which of the three you are actually missing, start with the measurement. Call Penny at 919-348-4912, or use the contact form. A network security assessment produces the inventory. It also produces the egress paths and the gap list that a decision table like this one needs to be applied to your environment rather than in the abstract.

Sources

• Cost of a Data Breach Report 2025, IBM X-Force (ibm.com)
• The AI Tools Your DNS Can't See (dnsfilter.com)
• OWASP LLM02: 2025 Sensitive Information Disclosure (genai.owasp.org)
• NIST SP 800-207: Zero Trust Architecture (nvlpubs.nist.gov)
• 2.5: Allowlist Authorized Software - CSF Tools (csf.tools)
• NIST SP 800-171 Rev. 2: Protecting Controlled Unclassified Information in Nonfederal Systems (nvlpubs.nist.gov)
• 45 CFR 164.312 -- Technical safeguards. (ecfr.gov)
• 16 CFR § 314.4 - Elements. (law.cornell.edu)
• Santa - Open source macOS security agent (northpole.security)
• App Control and AppLocker Overview (learn.microsoft.com)
• Cloud app catalog and risk scores - Microsoft Defender for Cloud Apps (learn.microsoft.com)

Get the Private AI Infrastructure Blueprint

Reference build sheets, a hardening checklist for open-weight model hosting and a data-sovereignty map for running AI on your own hardware.

Get the free guide