Your ProxySG's policy contains a rule (or rules) which should only match for users who do not belong to a particular AD group, or for all users except a specific named user or users. To achieve this, the rule contains a source-object which is defined by first matching the stated group or user-name, and then negating the condition.
When users who aren't authenticated connect through the proxy, the action for the rule isn't applied, and a policy trace marks the rule with 'n/a', rather than 'MATCH' or 'miss'.
This behaviour is by design. When authentication is bypassed for a given transaction, all AD user information remains unknown to the proxy, and as a result membership or non-membership of a given group cannot be evaluated one way or another.
Policy should either be written in such a way that authentication is always enforced for traffic which will need to be filtered through the layer containing the negated group-condition, or in such a way that a positive group-membership test can be applied instead which will exclude or include the relevant AD users as required.
1. Negated group-condition as guard-rule for a Web access layer
In the following policy, rule 1 in the Web Access layer is intended to block only users who aren't members of the AD group 'bad_group'.
However, since users connecting from the subnet 10.91.17.0/24 won't be authenticated, the negated group-condition in the guard layer will evaluate as 'n/a', so those user will also be blocked. To prevent this from happening, the policy could be re-written as follows:
2. Negated user-condition within a policy layer
In the following policy, all users except 'bad_user' are intended to be denied access to sites in CombinedDestination1. However, since users connecting from the subnet 10.91.17.0/24 won't be authenticated, all users connecting from this subnet would in practise also be blocked, because the source-condition in rule 2 would evaluate as 'n/a', and only the destination condition would be matched (user 'bad_user' would also be blocked, as intended, if he connected from a subnet other than 10.91.17.0/24).
An alternative method of writing this policy would be as follows: