--- title: "AI Activate - Using the Ignore SIDs filter" slug: "ai-activate-ignore-sids-flter" description: "Learn how AI Activate's Ignore SIDs filter customizes file access for AI tools while maintaining Windows permissions, ensuring precise content visibility." updated: 2026-10-02T17:59:22Z published: 2026-10-02T17:59:22Z canonical: "docs.nasuni.com/ai-activate-ignore-sids-flter" --- > ## 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 - Using the Ignore SIDs filter AI Activate makes your file content available to your AI tools while enforcing each file's own Windows permissions (NTFS ACLs). The Ignore SIDs filter lets you tell the AI Activate MCP server to disregard specific ALLOW permissions when it decides what a user is allowed to see through AI. This guide explains what the filter does, when to use the filter, how to find the correct values to enter, and how to confirm that the filter is working. This guide assumes that you are familiar with how AI Activate enforces permissions. For the full picture of how AI Activate reaches files, why AI results can differ from SMB browsing, and how scoping, Ignore SIDs, and re-permissioning compare, see the [Understanding permission enforcement](/v1/docs/aia-understanding-permission-enforcement) overview. ## What Ignore SIDs does Every principal in Active Directory (a user, a group, or a well-known identity such as Everyone) has a unique Windows security identifier, or SID. When you add a SID to the Ignore SIDs list, the MCP server evaluates every file's ALLOW permissions as if that SID were not present. The effect is targeted in these ways: - A user who could see a file **only** because of the ignored SID loses access to that file through AI. - A user who can see the same file through any other ALLOW permission (the user's own account or another group that includes the user) keeps access. - Ignore SIDs does not affect search or browsing over SMB. Ignore SIDs applies to AI (MCP) results only. The feature exists because AI Activate evaluates each file by the file's own ACL, so broad ALLOW permissions, such as Everyone or Authenticated Users, can surface content to AI that a user would never reach by browsing. Ignoring those broad principals brings AI results back in line with what you intend people to see. ## When to use Ignore SIDs, and when to scope instead Ignore SIDs is a blunt instrument by design. Ignore SIDs stops honoring a principal across the **entire volume**, not in one folder. Choose Ignore SIDs when the same broad principal over-surfaces content in many places, and you want to stop honoring that principal wholesale. If, instead, you want to keep a specific folder or set of paths out of AI results, use dataset scoping (include and exclude paths), not Ignore SIDs. Scoping is the cleaner tool for a location, and dataset scoping does not change permissions. A good sequence for most environments is to scope first, then apply Ignore SIDs only where broad principals still over-surface results. ## How Ignore SIDs works A few details to understand before you rely on the feature: - **ALLOW only.** Ignore SIDs affects the evaluation of ALLOW permissions only. Ignore SIDs never affects DENY. - **DENY always wins.** You cannot expose a file that a DENY entry protects by ignoring a principal. If a file denies a user, that user cannot access the file through AI, regardless of how you configure the Ignore SIDs list. - **Per volume.** Configure the Ignore SIDs list separately for each volume, so that you can tune volumes independently. - **Immediate.** Adding or removing a SID takes effect at the next query. Because Ignore SIDs changes how the server evaluates a captured ACL rather than changing the ACL, you do not need to wait for a new activation pass. This immediate evaluation makes Ignore SIDs the fastest way to adjust AI access. ## Ignore SIDs does not change your data or permissions Ignore SIDs is an access-evaluation setting, not a change to your files. Ignore SIDs affects only how the AI Activate MCP server evaluates ALLOW permissions when the server decides what to return through AI. Ignore SIDs does not do any of the following: - Ignore SIDs does not modify the NTFS permissions (ACLs) stored on your files. - Ignore SIDs does not change anything on the volume, and nothing is written back to your storage. - Ignore SIDs does not perform or require re-permissioning. The setting is fully reversible. Remove the SID, and permission evaluation returns to normal at the next query, with no changes to the stored permissions or data. ## Important cautions before you begin Read this section carefully. Ignore SIDs is powerful and does not protect you from mistakes. **The field accepts any value and does not validate the entry.** The Portal does not validate a SID or confirm which principal the SID matches. If you enter a value that is malformed, mistyped, or belongs to a different domain, the server simply finds no match. The server ignores nothing, displays no error, and leaves the affected files visible to AI. In other words, a wrong SID fails silently. Always verify your result with a real query, as described in [Verify that a SID is being ignored](/v1/docs/ai-activate-ignore-sids-flter#verify-that-a-sid-is-being-ignored) below. **Friendly names do not work.** The field accepts text such as `Everyone` or `DOMAIN\Domain Users`, but the server matches on the raw SID only, so *the server finds no match for a friendly name and silently ignores the entry.* Therefore, *enter the SID, not the name.* **Ignoring a principal can hide content you share on purpose.** Because the effect covers the whole volume, any file that a user reaches *only* through the ignored principal disappears from that user's AI results. If you deliberately grant broad read access to some content, expect that content to drop out of AI for the affected users. When you want a narrower effect, scope first. ## Where to find Ignore SIDs in the Portal 1. In the [Portal](http://portal.nasuni.com), go to **AI Activate**. 2. Open **MCP Server**. 3. Select the **volume** you want to configure. 4. Choose **Edit Config**. The Ignore SIDs panel shows an **Add SID** field and, after you have added values, a list of the SIDs currently configured. When the list is empty, the panel reads *No SIDs configured. The MCP server honors every ALLOW permission at query time.* ## Adding a SID 1. In the **Add SID** field, enter one complete SID, for example, `S-1-1-0` for Everyone. 2. Confirm the entry to add the SID to the list. The SID appears in the configured list. 3. Repeat for each principal that you want the server to ignore. The example shown inside the empty **Add SID** field is placeholder text that illustrates the format of a SID. Do not enter the placeholder text itself. Build the correct SID for your environment using the reference below. The change takes effect at the next query. No reactivation is required. ![Instructions for adding Windows security identifiers to ignore in the MCP server settings.](https://cdn.document360.io/2adf6ce2-c120-4520-b135-0fc4463ddde3/Images/Documentation/Screenshot 2026-09-10 at 13.18.59.png?sv=2026-02-06&spr=https&st=2026-10-15T02%3A35%3A16Z&se=2026-10-15T03%3A35%3A16Z&sr=c&sp=r&sig=gzR38f3XwiY1lOJL%2F6w%2FL%2B8XvQ1ArzGtD39XK6MoOFo%3D) ## Removing a SID Each configured SID in the list appears with a small **X**. Click the **X** to remove that SID from the list. The server resumes honoring that principal's ALLOW permissions at the next query. ## Finding the SID for a principal Some SIDs are the same on every Windows environment. Others are specific to your domain, and you must look up those SIDs. Use the right approach for the principal you want to ignore. ### Common universal SIDs The following well-known SIDs are identical in every environment, so you can enter the SIDs directly. | Principal | SID | | --- | --- | | Everyone | `S-1-1-0` | | Authenticated Users | `S-1-5-11` | Everyone and Authenticated Users are the two principals most often responsible for over-surfacing content, so they are a common starting point. ### Domain principals and their RIDs Groups that belong to your domain, such as Domain Users, do not have a fixed SID. Each domain principal SID combines your domain's identifier with a fixed suffix called a relative identifier, or RID. A full SID has the following format: ```plaintext        S-1-5-21-- ``` The domain identifier is a long string of numbers unique to your domain. The RID at the end is the same everywhere for a given built-in group: | Domain principal | RID (suffix) | | --- | --- | | Domain Users | `513` | | Domain Admins | `512` | | Domain Guests | `514` | For example, if your domain identifier is `S-1-5-21-1004336348-1177238915-682003330`, then the SID for Domain Users is `S-1-5-21-1004336348-1177238915-682003330-513`. You cannot copy another environment's domain SID. Look up your own domain identifier with one of the methods below. ### Finding a SID with PowerShell The following methods progress from those requiring no extra tools to the Active Directory module. Use any one method. - **Method 1: whoami (no extra tools).** Sign in to a Windows computer as a user who is a member of the group you want to ignore, open Command Prompt or PowerShell, and run: ```plaintext        whoami /groups ``` Find the group in the **Group Name** column and read the corresponding value from the **SID** column. This works well for broad principals such as Everyone, Authenticated Users, and Domain Users, because the signed-in user belongs to these groups. - **Method 2: translate a name to a SID (no RSAT required).** On any domain-joined machine, run the following command in PowerShell. The command inserts your current domain automatically, so you can use the command as written for Domain Users. *If you want a different group, change only the group name.* ```powershell        $account = New-Object System.Security.Principal.NTAccount("$env:USERDOMAIN\Domain Users")        $account.Translate([System.Security.Principal.SecurityIdentifier]).Value ``` The command prints the full SID for the named principal. To look up a group in a different domain, replace $env:USERDOMAIN with that domain's short (NetBIOS) name. If you see the message "Some or all identity references could not be translated," the name did not resolve: check the domain and group name, and confirm that you are signed in with a domain account. - **Method 3: Active Directory module (requires RSAT).** If the Active Directory PowerShell module is installed, run: ```powershell        Get-ADGroup "Domain Users" | Select-Object Name, SID ``` To retrieve only your domain identifier, so that you can append a RID yourself: ```powershell        (Get-ADDomain).DomainSID.Value ``` ## Verify that a SID is being ignored A real query is the only way to be sure that your configuration took effect. Verify every SID you add. 1. Identify a file that appeared in AI results because of the broad principal that you are ignoring, for example, a file whose only ALLOW permission is Everyone. 2. Choose a test user who could reach that file **only** through that principal, and not through any other group or through the test user's own account. 3. As that user, query your AI tool for the file's content and confirm that AI returns the file. This establishes the starting point. 4. Add the SID in the Portal. 5. Run the same query again. AI should no longer return the file. Because the change is immediate, you can run the second query right away. If the file still appears, see the [Troubleshooting](/v1/docs/ai-activate-ignore-sids-flter#troubleshooting1) steps below. ## Troubleshooting - **I added a SID, but the file still appears in AI results.** The most common cause is an incorrect SID. Re-check the value against the reference above, and confirm a domain SID uses your own domain identifier and the correct RID. Another cause is that the test user can also reach the file through a different ALLOW permission, so ignoring one principal does not remove the test user's access. Confirm that your test user qualifies for the file only through the ignored principal. - **A user lost access to content that the user should still see through AI.** Ignoring a broad principal removes the principal across the whole volume, so a user who relied on that principal for legitimate content access might now have no access to that content. Remove the SID to restore access immediately, then consider dataset scoping for a narrower effect. Alternatively, correct the file's permissions so access no longer depends on the broad principal. - **I entered a friendly name, but nothing changed.** The field matches on the raw SID only. Replace the name with the SID and verify again. - **A DENY did not behave as I expected.** Ignore SIDs never affects DENY. If a DENY entry applies to a user, the denial remains regardless of the Ignore SIDs list. Ignore SIDs changes ALLOW evaluation only.