Deploy the Secure Agent

Learning Objectives

After completing this unit, you’ll be able to:

• Explain what the Secure Agent is and how it bridges local networks and cloud services.
  
• Describe the outbound secure communication protocols used between the Secure Agent and IDMC.
  
• Distinguish between Secure Agents, Secure Agent Groups, and Hosted Agents.
  
• Configure and monitor a Secure Agent in the Administrator service.
  

The Connection Problem

Many organizations store data on premises, behind corporate firewalls that cloud services can’t reach directly. For example, Cassie, a developer at AW Computing, faces this exact challenge: her SQL Server database lives inside the company’s private network, but IDMC is in the cloud. How does IDMC reach data that’s behind a corporate firewall?

The answer is the Secure Agent.

Learn About the Secure Agent

The Secure Agent is a lightweight software component that you install on a machine within your local network. After installation, it runs as a background service and acts as the bridge between IDMC and any data sources that aren’t directly accessible from the cloud. Think of the Secure Agent as a trusted messenger.

• IDMC sends execution instructions down to the agent. For example: “Read from this SQL Server table, enrich the records, and write to Salesforce.”
  
• The agent executes those instructions locally, handling the data extraction, processing, and loading.
  
• The processed data moves directly through the agent to the target system.
  

How the Secure Agent Communicates

The Secure Agent communicates with IDMC using outbound HTTPS connections, the same protocol used for secure web browsing. This is important for two reasons.

• There are no inbound firewall rules required. Because the agent initiates the connection outward to IDMC (not the other way around), most corporate firewalls allow it without special configuration.
  
• The communication is encrypted in transit. All communication between the Secure Agent and IDMC is encrypted using Transport Layer Security (TLS), protecting data as it moves between your environment and the cloud.
  

This outbound-only architecture means Cassie installs the agent on a server inside AW Computing’s network without asking the IT security team to open risky inbound firewall ports.

Installing and Registering the Secure Agent

Setting up the Secure Agent involves three straightforward steps.

1. Download the Installer.
   

• Navigate to Administrator | Runtime Environments in IDMC. Select Download Secure Agent, select your operating system (Windows or Linux), and copy the generated Install Token.
  

2. Run the Setup.
   

• Execute the installer on a dedicated host machine inside your local network. Ensure the host machine has outbound internet access on port 443.
  

3. Register the Agent.
   

• Launch the registration utility on the host machine, enter your IDMC username, and paste the Install Token.
  
• Once registered, Cassie opens Administrator | Runtime Environments in IDMC and sees her new agent listed with an Active status. She is now ready to create database connections using her agent.
  

Agent Groups and Runtime Environments

In IDMC, one or more Secure Agents can be grouped together into a Secure Agent Group, also called a Runtime Environment. Groups provide redundancy—if one agent is unavailable, another in the group picks up the workload.

When Cassie creates a connection to her SQL Server, she selects her Secure Agent Group as the runtime environment. IDMC uses this setting to determine which agent handles data movement for that connection.

Here are some details about the different runtime environments.

Cassie sets up her single agent for now. If the group needs more capacity, she can add more agents for high availability. She notes that you cannot mix different operating systems (for example, a Windows Secure Agent and a Linux Secure Agent) in the same Secure Agent Group.

When to Use a Hosted Agent

Not every IDMC environment needs a Secure Agent. IDMC also offers a Hosted Agent—a managed runtime that lives entirely in the cloud.

A Hosted Agent is appropriate when:

• All your data sources and targets are cloud-accessible (for example, Salesforce, AWS S3, or a cloud database with a public endpoint).
  
• You want to avoid installing and maintaining software on a local machine.
  
• You’re prototyping or building in a sandbox environment.
  

A Secure Agent is required when:

• Your data lives behind a corporate firewall or on-premises network.
  
• Your organization’s security policy prohibits cloud services from initiating connections inward.
  
• You need low-latency access to a database on the same local network as the agent.
  

AW Computing’s SQL Server lives inside a private network, so Cassie needs the Secure Agent. If her team later migrates that database to a cloud provider with a public endpoint, she can switch to a Hosted Agent and retire the local installation.

Monitoring Agent Health

Once the Secure Agent is running, Cassie keeps an eye on it from the Administrator service. The Runtime Environments page shows:

• Agent Name: The registered name of the agent
  
• Status: Active (green) or Inactive (red)
  
• Last Heartbeat: The last time the agent checked in with IDMC
  
• Version: The installed agent version
  

IDMC agents send a heartbeat to the platform every few minutes. If an agent goes inactive, because the host machine was restarted or lost network access, IDMC flags it and any tasks scheduled to use that agent will not run.

Cassie sets a calendar reminder to check agent status every Monday morning. She also plans to add a second agent to the group later in the year for redundancy. If one goes down, the other keeps pipelines running.

Wrap It Up

With the Secure Agent installed and registered, Cassie’s IDMC environment is connected to AW Computing’s private SQL Server, no IT firewall exceptions required. The manual CSV imports that slowed AW Computing’s team are ready to be replaced with automated pipelines.

Now that you understand how the Secure Agent bridges on-premises and cloud systems, you’re ready to build those pipelines. Check out Cloud Data Integration Mapping Fundamentals to see how it’s done!