Se iniziate ad utilizzare il modello ad oggetti client-side di SharePoint 2010 per applicazioni Silverlight e provate ad istanziare un nuovo oggetto di tipo "ClientContext" passando come parametro al costruttore principale l'indirizzo di un sito SharePoint remoto (senza far girare l'applicazione Silverlight all'interno del contesto di SharePoint) ... 

ClientContext context = new ClientContext("http://sharepoint2010");

//…

context.ExecuteQueryAsync(...); //errore

vi troverete a fare i conti con questo errore:

{System.Security.SecurityException ---> System.Security.SecurityException: Security error.
at System.Net.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.BrowserHttpWebRequest.<>c__DisplayClass5.b__4(Object sendState)
at System.Net.AsyncHelper.<>c__DisplayClass2.b__0(Object sendState)
--- End of inner exception stack trace ---
at System.Net.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.Net.WebClient.GetWebResponse(WebRequest request, IAsyncResult result)
at System.Net.WebClient.OpenReadAsyncCallback(IAsyncResult result)}


L'errore viene scatenato alla chiamata del metodo ExecuteQueryAsync per l'esecuzione della query dall'applicazione client a SharePoint 2010.
Ecco, è bene sapere che questo errore può accadere per due principali motivi:
1- L'indirizzo che avete inserito come parametro del costruttore principale della classe ClientContext non esiste, non funziona o non è raggiungibile tramite browser.
2- Non avete inserito alcun file di policy ("ClientAccessPolicy.xml") per regolamentare le connessioni ai web services di SharePoint dall'esterno, nella directory della vostra web application.

Come è possibile leggere dal punto 2, per consumare un web services (che sia o meno esposto da SharePoint) all'interno di un'applicazione Silverlight, è necessario che il web server che lo ospita abbia un file di policy che regolamenta la possibilità di utilizzo o meno del web service stesso da applicazioni remote. Questo file è il file "ClientAccessPolicy.xml", che e va creato all'interno della root della nostra applicazione web.
Siccome il modello ad oggetti client-side ha, al suo interno, una classe proxy che si occupa di chiamare il servizio "Client.svc" esposto da SharePoint 2010 e leggerne le risposte, anche tutte le applicazioni che ne utilizzano i vari membri dovranno fare i conti con il medesimo modello di policy, in quanto pur scrivendo codice che mantiene il paradigma ad oggetti, alla fine vengono comunque fatte delle chiamate ad servizio web (in questo caso un servizio WCF). Per un introduzione sull'architettura del modello ad oggetti client-side di SharePoint 2010, trovate un articolo su SharePoint Community.
Quindi, in ambiente di sviluppo, potete mettere un file nominato "ClientAccessPolicy.xml" all'interno della root della vostra web application SharePoint. Questo un'esempio classico: 

<?xml version="1.0" encoding="utf-8" ?>   

  <access-policy>  

    <cross-domain-access>  

      <policy>  

        <allow-from http-request-headers="*">  

           <domain uri="*" />   

        </allow-from>  

        <grant-to>  

          <resource path="/" include-subpaths="true" />   

        </grant-to>  

     </policy>  

   </cross-domain-access>  

</access-policy>

Prima di procedere, provate a raggiungere tale file tramite il browser in modo tale da essere sicuri che possa essere letto da tutti, utilizzando questo indirizzo:

http://[servername]/ClientAccessPolicy.xml

E poi fate un bel IISRESET.

Se siete in produzione invece, è meglio seguire le linee guida date da Microsoft per il posizionamento e la stesura del contenuto del file "ClientAccessPolicy.xml".
Trovate invece più informazioni riguardo il modello di sicurezza per l'accesso a risorse esterne tramite applicazioni Silverlight qua: http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx