NTFS permissions automation: file share access requests with ServiceNow

NTFS permissions automation starts with your reviewed file share access requests. ServiceNow or your own request tool records the suggestion; your approvers decide.

Somewhere in your organization, someone is asking for access to \\fs01\Finance\Budget 2027. They'll get it. They nearly always do.

That's the quiet problem with access requests on Windows file shares. A large company handles thousands a month through ServiceNow or a similar tool, and the great majority are approved. Approvers learn that, and the few requests that deserved a second look get the same one click as the rest.

The request history holds the answer. It records who asked, for which folder, at what access, and what was decided. That's exactly what a model needs to learn from.

For a folder on an NTFS share, the request usually has the same parts:

• Who: the requester's department, title, manager and location.
• What: the folder or share, and the access level: Read or Modify.
• Why: a sentence of justification.
• Outcome: approved or denied, by whom, and which AD group they were added to.

Well-run file shares give access through AD groups rather than to people directly. So approving a request usually means adding someone to a group such as FIN-Budget-RW. The group, not the folder's permissions, is what changes.

Two decisions sit inside each request, and both have a history you can train on:

1. Should this be approved? Learned from past approvals and denials.
2. Which group fulfills it? Learned from the group each approved request was added to.

And there's a third decision, made less often but with more at stake: which groups get a new folder. That one is learned from the folders' current permissions.

We tested the first decision on a public record of real access requests: 32,769 of Amazon's, from 2010 and 2011, each approved or denied by a person. 94.2% were approved.

A model trained on 26,103 of them, and tested on 6,666 it never saw, gave each new request an answer and a confidence. We treated as routine only the requests it was very sure about, and sent the rest to a person:

• At a setting that treated 79% of requests as routine, 73% of the requests a person had denied still reached a person.
• The best rule we built, treating the same 79% as routine, let through 221 of those denials. The model let through 103.

These were application-resource requests, not NTFS folders; folder-request performance remains untested.

What we didn't find matters just as much: no method, the model included, predicted denials well enough to decide on its own. Denials are rare and often depend on things the data doesn't record. That's why the model's job here is to sort, not to decide.

Read the full benchmark →

The model sits inside the process you already have; it doesn't replace it.

1. A request comes in. Your request tool (ServiceNow, Jira Service Management, BMC Helix or another) sends its details to your StayCharted model through the API.
2. The model answers: "looks like ones you approved, 0.97", or "unsure, 0.61". A second model can suggest the group.
3. Your workflow decides what happens:
   • Routine requests for ordinary folders go to the approver as a one-click confirmation. They're approved automatically only if your access policy allows it, for example for Read access.
   • Unsure requests, and anything for a folder you mark as sensitive, get a full review.
4. Fulfillment runs as it does today: your AD integration or runbook adds the person to the group.
5. Every decision becomes a training example. Retrain each month or quarter, and the model follows your current practice.

In ServiceNow, for example, the approver sees the suggestion as a work note on the request (an illustration; the group and confidence depend on your model):

RITM0012345 · Folder access
Requested for   Finance analyst, reports to the Finance controller
Folder          \\fs01\Departments\Finance\Budget 2027
Access          Read
Reason          "Quarterly forecast review"

Work note       StayCharted: suggested approval, 97% confidence. Usual group: FIN-Budget-R.

Route sensitive HR requests for full review regardless of confidence. Unfamiliar requests can still receive a confident wrong answer; the approver decides either way.

StayCharted never connects to your file servers, Active Directory or ServiceNow. It answers a question from your workflow; your workflow and your people act.

When a team creates a project folder, someone decides which groups get Modify and which get Read. Your file shares already record years of those decisions in their permissions.

Export the folders' permissions as one row per folder (using an export suitable for your Windows, SMB or Linux file server), train, and the model suggests the groups for each new folder, with a confidence. You apply the ones you agree with.

Our group-access benchmark on 36,000 people found the same pattern: access follows the team more than the job title, and a model learns that on its own.

Pick one department's share, or one request type in ServiceNow, and export a year of history. Train, and look at two numbers on requests the model never saw:

• how many it would treat as routine at your cutoff;
• how many of your real denials would still have reached a person.

If those two numbers work for your team, connect it to new requests. If they don't, you've spent an afternoon and learned how consistent your access decisions really are.

Explore file and access-request workflows →

ServiceNow is a trademark of ServiceNow, Inc. Jira is a trademark of Atlassian. BMC Helix is a trademark of BMC Software, Inc. StayCharted is not affiliated with them.