One of the V1 decisions we made was to not allow partially trusted callers in our policy framework. Since we're expecting the vast majority (if not all) checkin policies to be installed on the client machine, this isn't too big of a deal.
However, when you register a policy, the registry key's value (a string) points to the location of the assembly - while it'll typically be a local filesystem location, it could also be a UNC path or even a URL (whatever Assembly.LoadFrom supports). UNC shares and URL's help give you an option for how to get the policies installed on the client - you don't need them there, you can have them reference a single central entity.
However, since we're not using APTCA, the default CAS policies won't allow using these assemblies. If you want the checkin policy to be at a UNC/URL kind of path, you'll need the client(s) to FullTrust the particular path for that assembly. For instance, if I wanted to be able to load the ForbiddenPatternsPolicy.dll from a given url, I could run this (as an administrator) to change current security policy on the client machine.
%WinDir%\Microsoft.NET\Framework\v2.0.50727\CasPol -m -ag 1.2 -url http://vsnc/Trusted/ForbiddenPatternsPolicy.dll FullTrust
Then you could have the registry point to that location:
reg add "HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies" /v "ForbiddenPatternsPolicy" /d http://vsnc/Trusted/ForbiddenPatternsPolicy.dll
Obviously this has a security impact by giving full trust to code not on your local disk (those CAS default policies are like that for a reason! :), so I don't recommend this kind of approach in the typical case - distributing/installing the assemblies and subsequent updates to the local disk is safer. However, there may be specific scenarios were this becomes useful for a particular customer.