Block Unapproved AI Tools Allowlisting and Egress Control for Shadow AI

Why Shadow AI Leaks Data Where Your Firewall Cannot See It

Every wave of unsanctioned technology before this one left a file behind. AI usage leaves a sentence, a screenshot, a pasted record, or a credential, and none of those trip a file share alarm.

Shadow AI is the use of artificial intelligence tools inside an organization outside the visibility and approval of the security and compliance teams. It is not a hypothetical. Cloudflare's 2026 Security Signals Report, as cited in its own learning material, puts unsanctioned app use at 98 percent of employees across shadow AI and shadow IT cases, and the Netskope Cloud and Threat Report 2026 finds that while the share of AI users working from personal accounts fell from 78 percent to 47 percent, prompts sent to SaaS generative AI apps grew sixfold in a single year. The direction is better and the volume is worse at the same time.

The distinguishing feature of this class of risk is that the data leaves in a form no traditional control was built to inspect. A data loss prevention rule written for email attachments has no opinion about a paragraph typed into a web form. A firewall rule that allows HTTPS to the internet has no opinion about which SaaS application sits behind that connection. An endpoint antivirus product has no opinion about a browser tab. The leak paths that matter are specific, and each one needs its own answer.

Talk to an engineer before you buy another blocking subscription. Call 919-348-4912

Four Leak Channels Where You Have to Block Unapproved AI Tools

A control that works on one channel does nothing on the next. This is why single-tool shadow AI programs fail an assessment even when the tool works.

Channel 1: the prompt and the paste

A chat box accepts anything a human can type. The OWASP Top 10 for Large Language Model Applications names this exposure as a top risk category, LLM02 Sensitive Information Disclosure, with sensitive business data disclosure listed among its common examples. Nothing about the transfer looks unusual at the network layer: it is an HTTPS POST to a well-known SaaS domain, indistinguishable from the ordinary web traffic around it. The signal that matters is the content, and content is what data loss prevention evaluates, which is why layer four of the stack exists.

Channel 2: the file upload

Uploads are the same problem with a larger container. An accounting team uploading a reconciliation workbook, a design team uploading a customer research deck, a legal team uploading a redlined agreement: each is a document transfer to a processor nobody assessed, under terms nobody read. Unlike email, there is usually no record on your side after the browser tab closes, and unlike a file share, there is no permission model to review later. If the destination is a personal account, it also bypasses single sign-on and centralized logging. Retention policy and any agreement about model training stop applying as well.

Channel 3: the browser extension

Extensions are the channel with the worst visibility. A writing assistant with read and modify permission on every page sees the customer record system and the electronic health record exactly as the user does. The December 2024 supply chain compromise is the case to study: attackers phished extension developers and pushed a malicious update to the Cyberhaven Chrome extension and a set of others, with researcher reporting putting the total at 33 extensions and more than 2.6 million users. No new application was installed by those users. The install happened months earlier, when the extension was benign, which is the whole lesson. Approving an extension once is not a control. An allowlist without version and permission constraints is a weaker control than it looks.

Channel 4: API keys, tokens, and agentic connectors

The newest channel does not involve a human pasting anything. An API key pasted into a notebook or committed to a repository is a standing, unmonitored data path. An OAuth grant authorized with one click gives a third-party AI application standing read access to mail, to files, and to calendar. The grant persists after the experiment ends. Netskope reports that 60 percent of insider threat incidents involve personal cloud app instances, and that 70 percent of organizations connect to the OpenAI API endpoint while 30 percent use Anthropic's APIs, which is non-browser AI traffic that no extension policy will ever see. Application allowlisting does not govern a server-side call from a script. That is why egress control and token hygiene are separate layers and not alternatives to endpoint policy.

Application Allowlisting on the Endpoint

Allowlisting inverts the default. Nothing runs unless policy says it may, which is the only configuration where "the AI app is not installed" is a statement you can actually verify.

Microsoft describes the shift plainly: application control changes Windows from a place where all code runs unless antivirus predicts it is bad, to a place where code runs only if your policy says so. That inversion is what makes an allowlist defensible in an examination, because the evidence is the policy plus the device state, not a hope that nobody installed anything.

App Control for Business and AppLocker on Windows

Microsoft offers two technologies, and the differences matter for design. AppLocker controls which applications are allowed to run and was introduced with Windows 7. App Control for Business, formerly Windows Defender Application Control, enforces code integrity and can govern what runs in the kernel as well. Microsoft's own guidance is that customers who can implement application control with App Control for Business rather than AppLocker should do so, noting that AppLocker will keep receiving security fixes but will not undergo new feature improvements. The feature availability table is blunt about one practical consequence: kernel mode policies are available for App Control and listed as not available for AppLocker.

Edition support is the other trap. App Control for Business policies are available on Windows 10, Windows 11, and Windows Server 2016 or later, and the policies are effective on all editions even though the PowerShell cmdlets are absent on Home edition. AppLocker policies on Windows 10 builds older than version 2004, including Windows Server 2019, are supported through Group Policy only on Enterprise and Server editions, while MDM-deployed policies work on all editions. A design that assumes every managed laptop is Enterprise is a design with an uncontrolled remainder, and nobody can tell you how large it is until the audit-mode data arrives. Deployment routes for App Control are Intune, Microsoft Configuration Manager, Group Policy, and script, and Smart App Control on Windows 11 version 22H2 and later gives a signed-or-predicted-safe baseline for smaller environments.

macOS and Apple platforms

Apple's equivalent has moved from a restriction key to declarative management. The App settings declarative configuration, which requires iOS 27, iPadOS 27 or macOS 27 at minimum, lets a device allow or deny apps by bundle identifier. Binaries are allowed or denied by signing information. Explicit settings cover allowed apps and allowed binaries, and they also cover always allow managed apps. Denied apps and denied binaries get their own entries. The older restrictions key that many MDM profiles still carry, allowListedAppBundleIDs, is now deprecated in favor of the declarative configuration, and it restricts which apps the system shows or can launch. If your fleet standard is "the user cannot install anything we did not approve," the control that delivers it is device management policy, not a request in a handbook.

Why this maps to control language your assessor will accept

Application control is not a boutique position. The Australian Cyber Security Centre's Essential Eight makes it a maturity level one requirement, restricting executables, libraries, scripts, installers, compiled HTML, HTML applications, and control panel applets to an organization-approved set, and extends the restriction to drivers at maturity level three. On the American control side, NIST SP 800-171 requirement 3.4.8 asks for exactly this: apply a deny-by-exception policy to prevent unauthorized software, or a deny-all, permit-by-exception policy to allow only authorized software, and the requirement's own discussion notes that whitelisting is the stronger of the two. The full control mapping is in the compliance section below.

Browser and Extension Allowlisting

Most shadow AI never becomes an installed program. It arrives as a tab, a bookmark, or an extension, which means the browser is where the second layer of enforcement belongs.

Chrome Enterprise gives you granular extension control through the ExtensionSettings policy. Each extension is addressed by its identifier, and the installation mode accepts these values: allowed, blocked, force installed, normal installed, removed. Three companion settings do the work that an allowlist alone cannot. Blocked permissions stop installation or execution of extensions that request API permissions you disallow, for example cookie access, and a previously installed extension that requires one of those permissions stops loading. Minimum version required disables extensions, including force-installed ones, below a version you specify, which addresses the supply chain case where a dormant extension turns malicious in an update. Install sources limits where an extension can be installed from. Combined with the ExtensionInstallAllowlist policy, where a blocklist value of star blocks everything except the allowlisted set, you get a default-deny browser rather than a denylist that is always one release behind.

Firefox enterprise policy supports the same shape. Its ExtensionSettings policy accepts an installation mode of blocked. That mode blocks installation and removes the extension from a device where it is already installed, and the wildcard default entry may only be allowed or blocked. If you run more than one browser, describe the outcome you need, then implement it per vendor. A policy that covers Chrome but not the second browser on the machine covers a fraction of the actual usage.

Close the DNS escape hatch inside the browser

Browser-level DNS-over-HTTPS is the quiet way around a network filter. When a browser sends name resolution to a public resolver over HTTPS, it ignores the resolver your network hands out, and a category block at the gateway never sees the query. Chrome Enterprise exposes the DnsOverHttpsMode policy for exactly this reason. Treat resolver settings as part of the browser baseline, alongside the extension policy, so the browser cannot unilaterally choose a resolver your filtering layer does not control.

Do not forget the AI features inside already-approved software

The hardest category to govern is the one you already approved. Office suites and contact centers as well as design tools and CRM platforms add generative features through routine updates. Some of those features arrive enabled by default and some are processed by a subprocessor that is not the one you assessed. Your approved application list ages out from under you without a single new install. The only durable answer is a vendor review step that is triggered by feature release rather than by procurement, and an inventory that names which subprocessor handles which AI feature. That work is governance, not endpoint configuration, and it is the section of an acceptable use policy that most organizations leave unwritten.

Network Egress Control: DNS, Secure Web Gateway, and CASB

The network layer is where you control destinations. It is the widest net you own and the least complete, and knowing which is which is the difference between a control and a false sense of one.

DNS filtering: visibility first, blocking second

DNS filtering blocks resolution of domains and categories so that client devices cannot load them, and Cloudflare's own guidance is that it is a lightweight way to restrict access and a first line of defense that should not be relied upon for complete protection. The reason it earns its place anyway is visibility. Because it logs which AI app domains resolve, it turns shadow AI from an unknown into an inventory you can prioritize, and it lets you attach an approval status per application and enforce allow or block from that status rather than maintaining a list by hand. The gap is that a resolver policy only sees names it is asked to resolve. A connection to a literal IP address bypasses it. So does traffic on a cellular hotspot, and so does any device the policy does not cover.

Secure web gateway and the SSE stack

A secure web gateway inspects and enforces policy on web traffic, and a cloud access security broker monitors and controls access to cloud applications to prevent data leaks and unauthorized use. Since Gartner introduced the security service edge model in 2021, those functions have been sold together with zero trust network access and firewall as a service, as one cloud-delivered stack. The practical benefit for AI control is that the same policy engine that governs SaaS application categories can classify a generative AI destination and then apply a block or a coaching page. It can log the attempt with an identity attached. The practical requirement is that the agent or tunnel must be on every device you mean to control. That set includes the contractor laptop and the home machine. Otherwise the control covers only the traffic that happens to be on network.

CASB categories versus named applications

The major CASB and SSE catalogs carry a generative AI category you can filter on, with a per-application risk score attached. Microsoft's Defender for Cloud Apps catalog, for example, lets you select Generative AI as a category filter to discover and then monitor or block those applications, and Netskope scores each catalog app from 0 to 100 and places it in one of five confidence levels, with GenAI-specific risk attributes feeding that score. Category blocking is efficient and it is also coarse: it will block a legitimate research tool along with a consumer chatbot, and its accuracy depends on a vendor's catalog being current. Named-application policy is precise and needs maintenance, because new front ends appear constantly. The pattern that holds up is category blocking as the default for unreviewed services, an explicit approved list for what business needs, and a review cadence that moves applications between the two on evidence rather than on request volume. Netskope's 2026 data supports the blocking side of this: 90 percent of organizations block at least one generative AI app outright and the average organization actively blocks 10, with AI-detection services among the most commonly blocked because they require users to submit full text or source code for analysis.

TLS inspection: what it buys and what it cannot

Inspection is the difference between knowing a connection went to a hostname and knowing what was posted to it. It is also the layer with the most honest limitations. Zscaler's deployment guidance states that inspecting everything is typically not feasible because of legal liability, regulatory concerns, Sarbanes-Oxley requirements, and personally identifiable information issues, and that it "often sees companies achieve a 60-70 percent TLS inspection rate." Certificate-pinned applications cannot be inspected at all, and the vendor's named examples include Apple, many Microsoft 365 apps, Adobe, Cisco WebEx, and the Dropbox application. Their worked example is worth internalizing: with 15 percent of traffic going to exempted destinations and 20 percent from sources out of scope, nearly 35 percent of traffic is not inspected, so 65 percent is the ceiling. Two consequences for design. First, exempt the health categories deliberately and document why, because a regulator will ask. Do the same for finance and banking. Second, never write a control statement that says all AI traffic is inspected, because it is not true on any real network.

The two protocols that shrink the network layer

Encrypted Client Hello masks the server name in a TLS handshake, so an intermediary cannot tell which hostname a client is visiting on a site that supports it unless it terminates the connection. DNS over HTTPS moves resolution to an external resolver over an encrypted channel, bypassing the resolver policy you set. Neither is a vendor defect; both are privacy features that a business network has to account for. Practical responses are to control the browser's resolver policy, to use a device agent that can see traffic before it leaves the machine, and to accept that the network layer will always be a partial view. That acceptance is what makes the content layer necessary rather than redundant.

Data Loss Prevention for Prompts and Uploads

The endpoint and the browser both control destinations. So does the network. Data loss prevention is the layer that evaluates the content, which is the only layer that can stop a paste to a destination nobody has classified yet.

DLP for AI works when three things are true: the data is classified, the rule can evaluate the action at the moment it happens, and the destination context is available to the policy engine. The first is the prerequisite people skip. A rule cannot match "restricted" if nothing in the organization has defined what restricted means, which is why a data classification policy is a dependency and not a parallel workstream.

Where the enforcement point actually sits

Modern suites can evaluate a paste or an upload in the browser, on the endpoint, or inline in the gateway, and the priorities matter. Microsoft Purview, for example, builds browser DLP for cloud applications into Edge for Business, applies policies that target unmanaged apps to Edge for Business on Windows 10 and Windows 11 devices managed by Intune, and states that if the policy is configured to block, users in scope cannot use unprotected browsers where the policy does not apply. That last clause is the important one: browser DLP is only a control if the other browsers are also governed. Microsoft's own documentation also notes that its Purview browser extension is required to monitor interactions with third-party generative AI sites and for endpoint DLP policies on Windows when Chrome is used, which is a concrete reminder that the coverage of a DLP product depends on what you deployed and where, not on the license count.

Rules worth writing first

• Direct identifiers at the point of paste into an unapproved AI destination: patient identifiers, member numbers, account numbers, and government identifiers, evaluated on the paste rather than on the egress log.
• Controlled unclassified information markers and handling caveats, including the banner text required by 32 CFR 2002.20, matched as content rather than as a filename.
• Source code and repository signatures, since source code is the single largest category in reported generative AI policy violations at 42 percent.
• Credential and key formats, evaluated on both a paste into a web form and a commit to a repository, because a leaked model provider key is a data path that outlives the employee's experiment.
• Bulk extracts: a spreadsheet download followed by an upload to an AI tool is a different risk from a single record, and the rule should count volume and not just content type.

What DLP will not do

It will not catch paraphrased data, it will not catch an image of a screen, and it will not reliably catch a prompt that describes a sensitive fact in ordinary language. It also generates false positives that block legitimate work, which is why every program needs a documented exception path that is faster than the workaround. Treat DLP as a friction layer that catches the honest mistake at scale, and treat the acceptable use policy plus an approved tool as the controls that reduce the number of mistakes in the first place.

Approved Private AI Instead of a Wall of Blocks

Every blocking program eventually meets the same objection: the tool you removed was genuinely useful. The durable answer is to replace it with one you can see.

An egress filter with no sanctioned alternative produces predictable behavior. Staff move the same work to a personal phone, and the data flow continues on a channel you do not control at all, which is a worse compliance position than the one you started in. Netskope's 2026 findings show both halves at once: the share of AI users working from personal accounts fell from 78 percent to 47 percent while organization-managed accounts rose from 25 percent to 62 percent, and total usage rose anyway, with prompts to SaaS generative AI apps up sixfold. Providing a managed option moved the behavior; removing one does not.

Petronella Technology Group, Inc. deploys private AI on infrastructure the client controls, as one of the sanctioned alternatives in this design. The engagement model on our private AI practice covers deployment on a dedicated GPU in our Raleigh cluster, in the client's own colo or on-premises rack, or on regulated cloud. That choice comes from the data class and the latency target, with the capital budget weighed too, rather than from a product preference, with the capital budget as the other input. Prompts and documents stay inside a boundary the client can audit. So do fine-tuned models and outputs. Retrieval can be scoped per user against an identity provider the organization already trusts. Buyers who need the full sizing and hardening picture should read our on-premise AI delivery page along with our private AI solutions page. Organizations earlier in the journey usually start with an AI governance framework and a written AI acceptable use policy before any infrastructure decision.

Where blocking still belongs, even with a private alternative

Blocking does not go away once you host a model. Some services have no legitimate business use in your environment, and Netskope's finding that half of organizations still lack an enforceable policy for generative AI tools is a reminder that "it is allowed because nobody said otherwise" is the state most organizations are actually in. Keep the default deny, keep the category block on unreviewed services, and route the exceptions through a review that produces an owner, a data class, and a retention answer. The private alternative changes what people do with the capability; it does not change what the policy permits.

Pair it with discovery, not instead of it

You cannot allowlist what you have not inventoried. Before enforcement, run discovery across these evidence sources.

• DNS and proxy logs.
• Endpoint application and extension inventories.
• Identity provider OAuth grants.
• The expense system.

Our shadow AI detection work covers the discovery side in more depth, and the two programs are designed to run together. Discovery produces the list. Allowlisting then enforces it, and the private platform absorbs the demand. For the AI-specific risks that remain inside an approved tool, read enterprise AI security. The prompt injection defense material covers the adjacent case.

A Rollout Sequence That Survives Contact With Users

Allowlisting fails for predictable reasons: an audit phase skipped, an exception path nobody documented, and a communication plan that arrived after the first blocked application. This sequence front-loads all three.

Run audit mode longer than you want to

Every application control technology has an evaluation or audit mode, and the entire value of the first weeks comes from using it. Audit mode produces the list of what would have been blocked. That list is your baseline and your user communication. It is also your evidence that the policy is tuned before it becomes an outage. Enforcing from a generic template is the most common way an allowlisting project gets rolled back by an executive whose line-of-business application stopped launching.

Write the acceptable use policy in the same window as the control

The policy and the technology are one artifact in practice. The policy names what is approved and who approves a new tool. It says what data may never enter an unapproved system. It sets how long a request takes and what happens to someone who bypasses it. The technology enforces the shorthands. If the control ships first, users experience a block with no rule to read, and the complaint goes to the blocked employee's manager rather than to the policy owner. Publish the approved list and the request form on day one of enforcement, and publish the exception path with them. Put the escalation number on the coaching page the gateway serves.

Instrument the program, not just the block

Count the blocks by destination and by department, count policy exceptions granted, count repeat attempts after a coaching page, and count usage of the sanctioned alternative. Those four numbers tell you whether the program is working or merely visible. A rising block count with flat sanctioned usage means people are trying and failing, which is a support problem. A falling block count with flat sanctioned usage usually means they found a path you are not logging, which is the outcome to hunt first.

Mapping the Stack to CMMC, NIST SP 800-171, and HIPAA

Controls that were never mapped to a requirement are controls you cannot use as evidence. Here is the mapping this design produces, quoted at the requirement level.

NIST SP 800-171 Rev 2, the CMMC Level 2 control set

CMMC Level 2 is assessed against the 110 requirements of NIST SP 800-171 Rev 2 under 32 CFR Part 170. NIST published Revision 3 of SP 800-171 in May 2024, but the CMMC program rule remains aligned to Revision 2, so the citations below use Rev 2 numbering. The requirements this program produces evidence for:

• 3.1.3, control the flow of CUI in accordance with approved authorizations. The requirement's discussion places enforcement in boundary protection devices including gateways, routers, and firewalls, which is exactly where the egress layer sits.
• 3.1.20, verify and control or limit connections to and use of external systems. An unapproved AI service is an external system, and an approved tenant with a reviewed agreement is the authorized case.
• 3.4.1, baselines and inventories of organizational systems including software. The allowlist is the software baseline, and the extension inventory is the part most organizations are missing.
• 3.4.6, employ least functionality by configuring systems to provide only essential capabilities.
• 3.4.7, restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services. The requirement discussion names program blacklisting and whitelisting directly.
• 3.4.8, apply a deny-by-exception policy to prevent unauthorized software or a deny-all, permit-by-exception policy to allow execution of authorized software. Whitelisting is called the stronger of the two policies in the requirement text.
• 3.4.9, control and monitor user-installed software, which is the requirement the browser extension policy and the user-level install block answer.
• 3.13.1, monitor, control, and protect communications at the external boundaries and key internal boundaries of organizational systems.
• 3.13.6, deny network communications traffic by default and allow it by exception, which is the DNS and gateway default-deny posture in requirement language.
• 3.13.11, employ FIPS-validated cryptography when used to protect the confidentiality of CUI, which governs the inspection and tunnel components you select, not just the endpoint encryption.

Read the full requirement text on our NIST SP 800-171 compliance page, and the assessment context on the CMMC compliance page.

NIST SP 800-53 controls behind the 800-171 requirements

Where an assessor or a client asks for the parent control, the two to cite are AC-4 and SC-7. NIST SP 800-53 Revision 5 AC-4, Information Flow Enforcement, requires enforcing approved authorizations for controlling the flow of information within the system and between connected systems, based on organization-defined information flow control policies. Its enhancement AC-4(4), Flow Control of Encrypted Information, is the one that speaks to the encrypted-bypass problem: prevent encrypted information from bypassing flow control mechanisms. Decrypting it is one accepted procedure; blocking the flow and terminating the sessions are others; the standard also permits another defined procedure. That enhancement is precisely the TLS inspection trade-off described above, and it is worth naming when you explain why some traffic is exempted. SC-7, Boundary Protection, with its SC-7(5) deny-by-default enhancement, is the parent of 800-171 requirements 3.13.1 and 3.13.6.

NIST AI Risk Management Framework

The AI RMF organizes the work into GOVERN, which applies across all stages, plus MAP, MEASURE, and MANAGE. An access control program maps cleanly onto that structure. Discovery is MAP. Block and violation metrics are MEASURE. The exception and enforcement process is MANAGE. GOVERN covers the acceptable use policy. Roles and the review cadence sit under GOVERN as well. Using the framework language in the program charter helps because it gives a security team and a business owner a shared vocabulary for what is being decided.

HIPAA Security Rule

For a covered entity or business associate, the relevant technical safeguards are in 45 CFR 164.312. The access control standard requires technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to persons or software programs granted access rights as specified in 45 CFR 164.308(a)(4). The transmission security standard requires technical security measures to guard against unauthorized access to electronic protected health information transmitted over an electronic communications network. A patient record pasted into a consumer chatbot is a disclosure of electronic protected health information to a third party, and the fact that no human at the vendor read it does not change that. Our HIPAA compliance work covers the risk analysis obligations that sit behind these technical standards, and there is no HHS-issued HIPAA certification for any product, which is why the argument has to be evidence rather than a badge.

What we are not claiming

Petronella Technology Group, Inc. is a Cyber AB Registered Provider Organization, RPO #1449. As an RPO we prepare organizations for assessment. We are not a C3PAO, and a CMMC Level 2 certification assessment is conducted only by an authorized C3PAO. A control design produces evidence; it does not produce a certification, and any vendor who tells you otherwise is selling a badge rather than a program.

How Petronella Technology Group, Inc. Delivers This

The engagement moves from discovery through design to implementation and operation. Each stage ends with a written go or no-go rather than a slide deck at the end.

The AI security assessment that usually starts this work has a published price range on our enterprise AI security page. The final figure depends on the number of AI systems and on how sensitive the data is, together with the compliance requirements in scope. That scope includes tool inventory, risk evaluation, remediation recommendations, and a compliance gap analysis. Network and endpoint changes are quoted after discovery, because they depend on fleet size and on how much identity and endpoint management is already in place. They also depend on how much of the fleet is actually in scope for CUI or electronic protected health information. We do not quote an implementation from a template, and we do not publish a price for work whose size we have not seen.

The 4-Pillars frame we use on security and compliance work

People: the acceptable use policy and role ownership. Awareness training and the named approver for a new AI tool belong here too. Process: the request and exception workflow, the review cadence, the incident path when a violation is detected, vendor risk governance for the subprocessors behind embedded AI features, and the evidence package an assessor will read. Technology: application control, browser policy, endpoint configuration review, egress filtering, DLP, and the sanctioned alternative. Risk: the data classification that drives all of it, the business impact of each exposure path, and a prioritized remediation sequence rather than an undifferentiated finding list. That four-pillar lens is the one we apply across assessment work, including cybersecurity risk assessments. Programs that skip the risk pillar build controls that block the wrong things, which is the failure mode that ends allowlisting projects.

What we operate continuously

For clients who want the control maintained rather than handed over, our managed security services team and our managed detection and response team run monitoring and endpoint management. Both collect compliance evidence as an ongoing service. That matters for an AI control program specifically because the threat surface changes monthly: new front ends, new extension capabilities, new embedded AI features in software you already own. A policy reviewed once is a policy that is wrong within a quarter. The cybersecurity practice and the private AI hub describe the surrounding capabilities, including the enterprise private AI cluster we operate in Raleigh.

Blocking Unapproved AI Tools: Frequently Asked Questions

Sources and Standards Cited

Related guides: how to block ChatGPT and other AI tools on your network, and allowlisting vs DLP vs CASB for AI data exfiltration.

• Cloud and Threat Report: 2026 - Netskope (netskope.com)
• AI Data Security Risks: 39.7% of AI Use Involves Sensitive Data (cyberhaven.com)
• Cost of Data Breach (ibm.com)
• ZIA SSL/TLS Inspection Leading Practices Guide, Zscaler (help.zscaler.com)
• Encrypted Client Hello - the last puzzle piece to privacy (blog.cloudflare.com)
• OWASP LLM02: 2025 Sensitive Information Disclosure (genai.owasp.org)
• NIST SP 800-171 Rev. 2: Protecting Controlled Unclassified Information in Nonfederal Systems (nvlpubs.nist.gov)
• 45 CFR 164.312 -- Technical safeguards. (ecfr.gov)
• Application Control for Windows (learn.microsoft.com)
• ExtensionInstallAllowlist: Configure extension installation allow list (chromeenterprise.google)
• ExtensionSettings policy, Chrome Enterprise (chromeenterprise.google)
• ExtensionSettings (firefox-admin-docs.mozilla.org)
• Learn about Data Loss Prevention for Cloud Apps in Edge for Business (learn.microsoft.com)
• AC-4: Information Flow Enforcement - CSF Tools (csf.tools)

About the Author

Craig Petronella is the founder and principal of Petronella Technology Group, Inc., a Raleigh, North Carolina firm operating since 2002. He holds the CMMC Registered Practitioner credential from The Cyber AB, is a Cisco Certified Network Associate and a Certified Wireless Network Expert, and is a North Carolina Licensed Digital Forensic Examiner, license 604180-DFE. He completed the MIT Sloan School of Management course AI Implications for Business Strategy in 2019 and is the author of 16 books, including an Amazon number one best-selling title on HIPAA. His work on this topic comes from scoping AI access and boundary controls for defense contractors and healthcare organizations. It also covers law firms and financial services firms that cannot send protected data to a public model.