Policy: Allow Specific Git-Related Applications to Access Files

This example shows a File Access policy that explicitly allows file access for a defined set of applications (in this case, two Git-related app identifiers). It’s useful for demonstrating how to create an allow policy for trusted developer tooling so it continues to work even when other File Access controls are more restrictive.

---

What this Policy Does

When a user on any in-scope endpoint runs one of the specified applications, the policy:

• Matches the request based on user, machine, and application

• Applies an ALLOW control on success

• Does not require the user to acknowledge the notification

In practice, this policy is typically used to “punch a hole” (explicitly permit behavior) for trusted tools—so they aren’t impacted by stricter deny/approval rules elsewhere.

---

Why it Behaves this Way

This policy is designed as an allowlist:

• Enforced: The policy is active and will apply its controls.

• Allow on success: The success action is ALLOW, so when the policy matches, the activity is permitted.

• All users: A wildcard user scope means any user can benefit from this allow rule (on in-scope endpoints).

• Application-scoped: Instead of *, the policy lists two specific application identifiers. Only those applications match.

• Built-in checks: Standard checks are present (user, machine, file/app, date/time/day, certificate). With date/time/day/cert constraints left empty, the policy primarily hinges on whether the user, machine, and application match.

---

Revise to Apply to Multiple Endpoints

Right now, machine targeting is set to a single endpoint. To apply this same allow behavior across multiple endpoints, update machine targeting so it includes more than one endpoint identifier (or use your endpoint grouping approach). For example:

• Before: machine targeting lists one endpoint.

• After: machine targeting contains multiple endpoint identifiers.

No other changes are required to broaden endpoint coverage.

---

What the User Experiences

• When using the specified Git-related applications on an in-scope endpoint, users won’t see additional prompts or blocks from this policy.

• If other File Access policies exist that would otherwise deny or require approval, this allow rule can be used to ensure these trusted tools remain functional (depending on how precedence/conflict resolution is configured in your policy set).

---

Important Notes and Common Adjustments

• Keep the message accurate: The current notification text references “monitor mode” and mentions MFA/justification/request, but this policy is enforced and uses ALLOW. For production, update the message so it reflects what the policy actually does (or remove the message entirely).

• Narrow by user/group if needed: Replace the wildcard user targeting if only certain users should be allowed to use these tools.

• Add certificate/publisher constraints: If you want stronger assurance, restrict the allowlist to known signed binaries (where supported), not just application identifiers.

Example JSON

{
	"PolicyName": "_4_AllowGitFiles",
	"PolicyType": "FileAccess",
	"PolicyId": "N0N1N2N3N4N5N6N7N8N9N",
	"Status": "enforce",
	"Actions": {
		"OnSuccess": {
			"Controls": [
				"ALLOW"
			]
		},
		"OnFailure": {
			"Command": ""
		}
	},
	"NotificationMessage": "A policy has been set to monitor mode.  When this policy is enabled, [mfa, justification, request] will be required to run this process as an administrator.",
	"NotificationRequiresAcknowledge": false,
	"RiskLevel": 50,
	"Operator": "And",
	"Rules": [
		{
			"RuleName": "UserCheck",
			"ErrorMessage": "This user is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckUser()"
		},
		{
			"RuleName": "MachineCheck",
			"ErrorMessage": "This Machine is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckMachine()"
		},
		{
			"RuleName": "ApplicationCheck",
			"ErrorMessage": "This application is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckFile(false)"
		},
		{
			"RuleName": "DateCheck",
			"ErrorMessage": "Current date is not covered by this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckDate()"
		},
		{
			"RuleName": "TimeCheck",
			"ErrorMessage": "Current time is not covered by this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckTime()"
		},
		{
			"RuleName": "DayCheck",
			"ErrorMessage": "Today is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckDay()"
		},
		{
			"RuleName": "CertificateCheck",
			"ErrorMessage": "Certificate hash is not included in this policy",
			"RuleExpressionType": "BuiltInAction",
			"Expression": "CheckCertificate()"
		}
	],
	"UserCheck": [
		"*"
	],
	"MachineCheck": [
		"NSBYFNaHnhkIgVIazYhFXA"
	],
	"ApplicationCheck": [
		"wNyeIdZ6pXMfenXwA_So4Q",
		"7ORi4j81jU1g8NhE4zAs5g"
	],
	"DayCheck": [],
	"DateCheck": [],
	"TimeCheck": [],
	"CertificationCheck": [],
	"Extension": {}
}