Data Access The Agent requires access to your data, otherwise it can't do its job. You should allow specific permissions to the data that you want the Agent to work with and deny access to anything you don't want the Agent to be able to access. It is good practice to only allow access to resources that you want access to and broadly deny access to everything else. You also have full control over detail about the data the Agent accesses through the web portal, please refer to Data Sharing Principles for a summary of object, column, and row level filtering.
Installing the Agent on a well-secured computer within your internal network is a simple solution and for most small organisations, will be preferable.
Simply put — if you have internet-facing computers holding data to be shared then install your Agent within your network.
The Agent service account acts as a User on the network - with access to database objects or folder locations where data needs to be read from or written to.
The same locations could also be accessed by Users on your network who need to prepare and maintain data that is being shared.
It is important that Users are aware that any object that is used for data sharing can be visible by another Organisation if the datastore has been shared.
One common approach to installing the Agent within enterprise networks is to install it on a computer within a DMZ.
A DMZ is a 'no-mans-land' sandbox network between the internet and your company's core internal networks. This is seen as a 'safe' place to install the Agent because it is specifically blocked from the internal network. However, the Agent needs access to resources on the internal network. Often there is no domain trust between the internal and DMZ networks, further complicating things. If you must use this approach, you will need to do one of the following to make it work:
An account can have multiple Agents installed as required.
Once you have a planned implementation, take a look at the checklist on the page Agent System Requirements
