One of the major changes of thinking that is required for web developers is understanding that in AIR they are developing desktop applications not web applications. Desktop applications have special permissions such as file system interaction that web applications do not have. For this reason, special care must be taken to ensure that your AIR applications are not compromised by outside sources as well as ensuring that your AIR application is from the publisher that it is supposed to be from. Hence you'll find certificates and security sandboxes inside of AIR.
Note: For more information on security in AIR, see Lucas Adamski's article Introducing the Adobe AIR security model.
Because of the risk desktop applications can pose to a user's computer, there needed to be some method of verifying the identity of the publisher for an AIR application. Just as with some other desktop application platforms, Adobe AIR requires that you have a certificate for your application. This does not mean however that you must have a commercial certificate. Adobe actually allows developers to use self-signed certificates as well. In Dreamweaver you can create a certificate for your applications by selecting the Set button next to the Digital Signature field on the AIR Application and Installation window. An additional window will come up, and you will need to select the Create button. The next window will allow you to fill in information about you and your organization (see Figure 4). Once this is complete, Dreamweaver will inform you if your certificate has been created correctly.
Note: For more information on the rationale behind signing applications see the section Why sign an application in Todd Prekaski's article Digitally signing Adobe AIR applications.

Figure 4. The certificate creation window in Dreamweaver CS3
Now you can set the digital signature from the AIR Application Settings window. You need to be sure and remember the password that you used when your certificate was created, because this password will have to be entered each time that you create your .air file.
Commercially signed certificates confirm your identity to the end user of the application. This is important enough that it even changes the installation screen when the user is installing a self-signed versus a commercially signed AIR application. Figures 5 and 6 illustrate this difference.

Figure 5. The installation window for a self-signed certificate application

Figure 6. The installation window for a commercially signed certificate application
Commercially signed certificates are available from several companies such as Thawte. Unlike the process for creating a self-signed certificate, the commercial certificate issuer handles the process you must go through to get your certificate.
A sandbox gives a page or asset in your application a specific group of permissions. The root HTML file that is referenced in your application descriptor file will automatically reside in the application sandbox. The root file of your application will reside in the application sandbox.
The application sandbox gives the widest range of
capabilities. There is really only one limitation for content in the
application sandbox: the use of the eval method is greatly
restricted. The eval method can still evaluate literals, but function calls
cannot be passed through JSON. Since this is a desktop application and not a
web application, the core AIR API calls need to be protected. What if the remote
server was compromised and send the following JSON statement?
{ air.NativeApplication.nativeApplication.exit() }
This would cause your application to exit without warning.
Many JavaScript developers do not write this into their code, but many
JavaScript frameworks implement this functionality. In these cases, the
developer can use the remote sandbox and use the parentSandboxBridge and childSandboxBridge to communicate between the two different sandboxes.
This functionality for working between different sandboxes can be confusing, so there is a template from Adobe for working with these types of applications. This template can be found in the exercise files for this article. This template is a great place to start integrating your existing web application with AIR.
Sandboxing in AIR is a complex topic. For many applications this basic method of application / non-application sandboxing will suffice, but when data is loaded dynamically from multiple sources, a more thorough understanding of the security model inside of AIR will be required. You'll find an entire chapter in Developing AIR Applications with HTML and Ajax dedicated to the security model. Lucas Adamski's also recently wrote an article in which he introduces the AIR security model and the rationale behind it.