Agent Server [2/3]: Where Should Your Agent Server Run?

‍

TL;DR: Genesis deploys its agent server as a Docker container inside the customer's own environment. Supported targets include Snowflake via Snowpark Container Services, Databricks, AWS, Azure, and on-premises Kubernetes. Each agent gets its own scoped account and monitored access, treated the same way you'd treat a new employee.

Where does it run? Where is it deployed? In the world of software, people used to deploy software through floppy disks and CD-ROMs. That felt very secure because the software was running on your computer, and the vendor had no way to access it or see what you were doing with it. SaaS changed that considerably. Now the software runs somewhere else, in a place the vendor has to secure and that you, as a customer, have to become comfortable with.

Agents Replacing SaaS Applications

Agents are starting to replace certain classes of SaaS applications. One of the potential cost savings is the ability to slow SaaS spend because agents can handle things internally that companies used to depend on outside vendors to do. That means agents have to run somewhere. For background on what an agent server actually is, see Agent Server [1/3]: Where Enterprise AI Agents Live, Work, and Scale.

The Genesis Approach: Running Agents Inside Your Environment

There are various places an agent server could run. It could live at a SaaS vendor; there are companies that run turnkey systems for agents handling marketing or legal work. At Genesis, we build data agents: software that works with data, which is one of the most important assets any organization holds. In our experience, customers want those agents running inside their own environment, ideally on the same platform where the data already lives. It is much easier to secure, and much easier to explain why it is secure, compared to agents running somewhere else and reaching back into your corporate data.

Deployment Options

Assuming a customer wants to deploy a data agent inside their environment, which is how all Genesis customers do it, there are a few places to run it. The Genesis agent server ships as a Docker container, so it runs anywhere customers are already comfortable running containers. Most large enterprises run lots of containers for lots of things and are generally comfortable with that model.

‍

Running Inside Your Data Platform

The most useful place to run the agent server is directly inside your data platform. Genesis has a Snowflake native application built on Snowpark Container Services, which runs the Genesis agent server inside those containers. Running it inside your Snowflake account is a straightforward path, and you inherit the security posture you already trust Snowflake for. Databricks has similar capabilities for running containers inside the platform.

AWS, Azure, and On-Premises

Most customers run AWS or Azure. Genesis provides Terraform deployment scripts for both: EC2 or ECS on AWS, container instances or VMs on Azure. For customers who need everything inside their own building (some hedge funds still run on-premises Kubernetes clusters and want data that never leaves their walls) that works too. Once the server is running, see Connecting Data Sources in Genesis for next steps.

All of these deployment options share a common advantage from a security and access control perspective: they are all better than running an agent in a third-party cloud where you have to worry about someone else's security protocols.

Why This Matters for Data Agents Specifically

For a data agent, you ideally give it broad access to your organization's data, both structured and unstructured, much broader than you would give a typical SaaS platform. SaaS platforms generally create data inside themselves. Salesforce is a good example: most of the data in Salesforce was generated inside Salesforce. Data agents are different. They are accessing data that is already resident inside your enterprise, potentially across a large range of systems and data sets. Running them inside an environment that is already trusted, secured, and monitored by your organization is the right approach. For more on managing data operations once agents are deployed, see Data Operations AI Agents.

Access Control: Treating Agents Like People

When securing data agents, there are two things to think about: the access agents have to your systems and data, and the access users have to the agents themselves.

The most practical approach is to treat each agent like a person. Set up an account in each system the agent needs, Snowflake, Databricks, GitHub, JIRA, either as a named user or as a service account, depending on how your organization classifies non-human users. Assign those credentials in the Genesis agent server. From there, the agent can query Snowflake, run jobs on Databricks, interact with GitHub, and so on. And you can monitor its activity through the same audit logs you already use for human users.

In terms of access level, start the same way you would with a new employee: scoped permissions, not administrative access. Read access to relevant data sets, write access to designated schemas, specific tool integrations as needed. The Genesis agent server manages all of those rights, roles, and keys securely. For a deeper look at how this works, see Agent Server [3/3]: Agent Access Control Explained: RBAC, Caller Limits, and Safer A2A. If you are thinking about how managing agents compares to managing people on a team, this post is worth a read.

Frequently Asked Questions

Why run the agent server inside our environment? Data agents need broad access to your data. Running them on infrastructure you already own and monitor is the simplest way to keep that access secure. Genesis cannot see your data or agent activity.

What platforms are supported? Snowflake, Databricks, AWS, Azure, and on-premises Kubernetes. All deployments use Docker containers.

How much access should we give an agent? Start narrow: read access to relevant data sets, write access to designated schemas, specific tool integrations only. Expand as needed, the same way you would with any new team member.

How do we track what agents are doing? Agents get their own accounts in each connected system, so their activity shows up in your existing audit logs and monitoring tools.