Using the accessWord limitation (as documented) may end up on an erraneous list of results.
Indeed, the policies criteria seems to be taken in account but badly post-filtered if the final user finally doesn't have the proper read right on the result object.
This behavior then comes against accessWord logic, which should allow to bypass user policies.

As a post-filter, this also result in some inconsistency between search count and search results, as some "denied" contents are finally in count but removed from result list.
Check steps below to reproduce.

Just removing the post filter in search plugin (ezsolr.php) will make it work again (cf attached patch). Wonder why was this test for, as limits are handled in requests it doesn't seem to be needed anymore (weight of history?)

Steps to reproduce

• Create two contents (ie articles)
• Place one in a standard section and the other in a restricted section
• Make sure that the restricted section is not accessible by anonymous users
• In a template, fetch some results, for an example based on their classID

  {def $srch=fetch('ezfind', 'search', hash(
             'query', '',
             'class_id', '2',
             'limitation', hash( 'accessWord', 'yes' ),
             ))}
  <pre> Results ({$srch.SearchCount}) : <br />
  {foreach $srch.SearchResult as $s}
     {$s.name}<br />
  {/foreach}

• As an anonymous user, check the results view.
  You then expect that, as an accessWord is set, the user will see both contents in results.
  But indeed it won't be the case : you'll have two contents found (searchCount) but only one result to be displayed (searchResults), then comes an inconsistency.
  Logged in as accredited user, results will be fetched properly, this will only happen when user lacks the proper read policy.