--- title: "AI Activate - Understanding Permission Enforcement" slug: "ai-activate-understanding-permission-enforcement" description: "Learn how AI Activate's permission-aware indexing differs from SMB access, ensuring secure file retrieval while enforcing NTFS permissions effectively." tags: ["Active Directory", "AI Activate", "Best Practices", "Configuration", "Permissions", "SMB"] updated: 2026-10-01T20:07:46Z published: 2026-10-01T20:07:46Z canonical: "docs.nasuni.com/ai-activate-understanding-permission-enforcement" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.nasuni.com/llms.txt > Use this file to discover all available pages before exploring further. # AI Activate - Understanding Permission Enforcement ## How AI Activate Access Differs from the SMB Experience AI Activate makes your file content available to AI tools through a permission-aware index that enforces each file’s own permissions. Before you enable AI Activate, understand that AI Activate enforces each file’s permissions, but reaches the files differently from users who access the files over SMB (such as through Windows Explorer or macOS Finder). In most environments, AI Activate access aligns with SMB access. In some environments, AI Activate access differs from SMB access, but some simple controls help to align the two access methods. This document explains how permissions work and what, if anything, you should do. ## How AI Activate Enforces File Permissions When an AI tool sends a query, before returning content, the MCP server uses SSO and Active Directory to verify the user's identity, then evaluates the user's permissions for every candidate file. Content that the user is not permitted to see is excluded at the data layer, so the AI model never receives it. Two details matter for accuracy: - AI Activate evaluates each file's own NTFS permissions (ACLs). AI Activate honors both *ALLOW* and *DENY* entries, and always enforces *DENY* over *ALLOW.* - AI Activate resolves group membership at query time. If you remove a user from a group, that user loses access to that group's files in near real time. If you add a user to a group, that user gains access in near real time. Changes to a file's own ACL are a separate case and are covered in [Additional Technical Details](/v1/docs/ai-activate-understanding-permission-enforcement#additional-details2) below. AI Activate enforces NTFS permissions. AI Activate does not support volumes that use NFS and POSIX permissions. ## Why AI and SMB Can Show Different Results Access over SMB is path-dependent. What a user can reach depends on which share the user connects through, and which folders the user can list along the way. For example, a user who enters a volume through a share several levels deep never sees the folders above that point. Nasuni volumes might have several shares, providing different levels of entry. By contrast, AI Activate takes a flat approach. AI Activate works from the volume root by using the include and exclude paths that you define. AI Activate does not use shares or entry points, and evaluates each file solely by the file's permissions. Because AI Activate and SMB evaluate access differently, AI results can diverge from what a user sees when browsing over SMB, in both directions: - AI can return a file that a user could not reach over SMB. The most common cause is a broad *ALLOW* entry such as *Everyone* or *Domain Users* on a file the user would never navigate to. Even though the user's normal access path does not reach the file, the file's ACL grants access. - AI can withhold a file that a user could reach over SMB. This happens only if you use the *Ignore SIDs* feature and ignore a principal at query time that a file legitimately depends on. This can also happen briefly after you edit a file's ACL, until that file is next activated. This image illustrates how access to a file can differ. ![](https://cdn.document360.io/2adf6ce2-c120-4520-b135-0fc4463ddde3/Images/Documentation/figure1_smb_vs_index_divergence(1).svg?sv=2026-02-06&spr=https&st=2026-10-15T01%3A22%3A58Z&se=2026-10-15T02%3A22%3A58Z&sr=c&sp=r&sig=LX%2FzI2stvEDO9DipgWyDs9eWUDdLdEubKz9uZDZdXx0%3D) ## How to Assess Your Environment Most environments fall into one of three situations. Use the following guidance to identify the applicable situation: - **Your file permissions already reflect who should see each file.** Named users and groups control access, and broad principals like *Everyone* are rare. This configuration likely requires no changes. - **You rely on broad principals or folder location rather than file permissions to limit access.** AI might surface more content than users expect. Use scoping and, where needed, the *Ignore SIDs* feature. - **Your content is protected primarily by its position in the tree rather than by its ACL.** This situation has the greatest divergence. Scope tightly, and consider correcting the permissions. ## Three Ways to Align AI Access with the SMB Experience Try the following methods in order, from least to most involved: 1. **Dataset scoping:** Expose to AI tools only the folders that you choose. Configure dataset scoping per volume in the Portal. Dataset scoping is the cleanest first step and does not change permissions. 2. **Ignore SIDs:** Configure AI Activate to ignore broad *ALLOW* principals, such as *Everyone* or *Authenticated Users*, when evaluating a file. Enter each principal as the raw SID. Configure Ignore SIDs per volume in the Portal. Ignore SIDs applies to AI (MCP) results, and AI Activate always enforces *DENY*. Ignore SIDs does not change stored volume permissions, and you can enable or disable Ignore SIDs at any time. If you enter a SID incorrectly, the SID matches no principal. AI Activate does not ignore the principal, and the file remains visible to AI. AI Activate does not display an error for an incorrect SID, so verify each SID before relying on the Ignore SIDs configuration. 3. **Re-permissioning:** Correct the underlying file permissions. Re-permissioning is the most thorough and time-consuming option and is rarely the place to begin. This chart illustrates the differences between these three methods. ![](https://cdn.document360.io/2adf6ce2-c120-4520-b135-0fc4463ddde3/Images/Documentation/figure2_mitigation_levers(1).svg?sv=2026-02-06&spr=https&st=2026-10-15T01%3A22%3A58Z&se=2026-10-15T02%3A22%3A58Z&sr=c&sp=r&sig=LX%2FzI2stvEDO9DipgWyDs9eWUDdLdEubKz9uZDZdXx0%3D) **Bottom line:** **AI Activate enforces the real permissions on your files.** Because AI Activate reaches files via ACLs rather than by share and path, you decide how closely AI results should mirror the SMB experience, using scoping and the *Ignore SIDs* feature to tune the fit without a re-permissioning project. --- ## Additional Technical Details ### How SMB Access Depends on Share and Path Most users reach Nasuni volumes over SMB through a mapped drive. A volume can have one or more shares, and a share can sit anywhere in the volume, at the root or several levels down. The share location, folder permissions, and share-level permissions determine what a user can see and read. - The connected share and the share's location in the volume affect access. If the user enters at the root, the user might see every top-level folder. If the user enters through a share several levels deep, the folders above the entry point are not part of the user's view. - The permissions on the folders along the path. To browse into a folder and list its contents, a user needs the relevant read and list rights on that folder. - Share-level permissions can further restrict user actions independently of the underlying file permissions. The practical result is that two users with identical file permissions can have very different experiences depending on how each user enters the volume. No single correct view exists, and the file system alone does not show how each user typically connects. ### How AI Activate Evaluates Access AI Activate works from the volume root, following the include and exclude paths that you configure. AI Activate is share-agnostic: AI Activate does not model share mount points or session entry points and does not evaluate directory traversal. For each file, AI Activate records and later evaluates that file's own permissions. AI Activate cannot reliably reconstruct each user's path-dependent view because the view depends on runtime factors, including the share and session. These runtime factors are not file-system properties. Therefore, AI Activate enforces the unambiguous, authoritative permissions on each file. ### Two Ways that AI Results Can Differ from SMB **AI returns more than SMB browsing would show.** Consider a file whose ACL includes *Everyone* with read access, residing in a part of the volume that a given user never navigates to. Because the user's normal access path does not include the file's share and folder location, the user would not find the file over SMB. Through AI Activate, the file's ACL grants access, so a relevant query can return the file. Broad *ALLOW* principals, such as *Everyone* and *Domain Users,* are the most common drivers. In many environments, broad *ALLOW* entries are unintentional and might indicate that permissions require cleanup. Share-level restrictions are a second driver. Because AI Activate reads only file permissions, AI Activate cannot detect a restriction at the share level. **AI returns less than SMB browsing would show.** AI returning less than SMB is not the default behavior. If the *Ignore SIDs* configuration ignores a principal that provides legitimate file access, a user who qualifies only through that principal cannot access the file through AI. After you change a file's ACL, AI might also return less content until the next activation pass captures the change. ### How DENY Entries and Ignore SIDs Work Together The *Ignore SIDs* feature affects *ALLOW* evaluation only. AI Activate always enforces *DENY* entries, regardless of which principals you choose to ignore. You cannot accidentally expose a file that a DENY entry protects by ignoring a principal. A raw SID identifies each principal, for example S-1-1-0 for *Everyone*. AI Activate does not accept friendly names or account names such as *Everyone* or jsmith@yourdomain.com; enter the SID that identifies the principal you want to ignore. ### What Changes Immediately and What Waits for Reactivation AI Activate evaluates two different types of information at different times, and the distinction matters when you are remediating access: - **Group membership is resolved at query time.** If you add or remove a user from a security group in Active Directory, AI results reflect the change in near real time. Membership-based changes are the fastest way to adjust access. - **A file's permissions are evaluated against the copy captured when the file was activated.** If you edit a file's ACL, AI results reflect the change after the next activation, according to the volume's snapshot and sync schedule. When re-permissioning, plan for the access change to take effect during the next activation. ### Choose the Right Approach for Your Environment A few questions help you decide where to invest: - Do your file permissions express who should have access, or do you rely on folder structure and share placement to control access? The more your real control lives in the ACLs, the closer your AI results match intent. - How common are *Everyone* and *Domain Users* as *ALLOW* entries on content you would not want broadly surfaced? Frequent broad principals point toward the *Ignore SIDs* feature, scoping, or cleanup. - Is your most sensitive content segmented by permission or by location? Location-based segmentation is the case that benefits most from tight scoping up front. For most customers, the sequence is straightforward: 1. Scope AI access to the content you actually want available. 2. Apply the *Ignore SIDs* feature where broad principals would otherwise over-surface results. 3. Treat re-permissioning as a longer-term improvement rather than a prerequisite.