Agent Server [1/3]: Where Enterprise AI Agents Live, Work, and Scale

‍

TL;DR: Enterprise data agents need to run somewhere secure, and for most organizations, that means inside their own environment, not a vendor's cloud. Genesis deploys its agent server as a Docker container that runs inside your data platform (Snowflake, Databricks), your cloud setup (AWS, Azure), or even on-premise Kubernetes clusters. Access control works the same way it does for people: each agent gets its own account, permissions, and monitoring.

Where does it run? Where is it deployed? In the world of software, people used to deploy software through floppy disks and CD-ROMs. The vendor had no way to see what you were doing with it because everything ran on your own machine. The world of software as a service obviously changed that quite a bit, because now the software is running somewhere else, in a place that the vendor has to secure and that you as a user have to become comfortable with.

Agents Replacing SaaS Applications

Agents are starting to reduce the need for certain classes of SaaS applications. That's one of the potential benefits and cost savings agents might allow: the ability to slow the growth rate of SaaS spending, because those agents can do things internally that organizations used to depend on SaaS vendors to do. So that means those agents have to run somewhere.

The Genesis Approach: Running Agents Inside the Customer Environment

There are various places an agent could run. It could run back at a SaaS vendor. There are companies that run whole turnkey SaaS systems for agents that handle marketing, legal, and other functions. At Genesis, though, we focus on data agents, things that work with data. Data is obviously one of the key assets of any organization. And in our experience, our customers want those data agents, and the servers for those agents, to run inside the customer's own environment, ideally on the same platform where the data itself lives. It makes it a lot easier to secure and to understand why it's secure, versus having agents running somewhere else that have to reach into your corporate data.

For a closer look at how to evaluate where your agent server should specifically live within your environment, see Agent Server [2/3]: Where Should Your Agent Server Run?

Deployment Options for the Genesis Agent Server

Assuming a customer wants to deploy a data agent inside their environment, not outside (which is how all of our Genesis customers do it), there are a few options. Our agent server is a Docker container, which means it can run anywhere the customer is comfortable running Docker containers. Most large enterprises are already running plenty of containers for various things, so the concept is generally familiar.

Deploying Inside Your Data Platform

The biggest and most useful places to run agent servers are inside your data platform itself. Snowflake makes this especially easy through Snowpark Container Services. Genesis has a Snowflake native application that comes with a set of Snowpark containers, which is essentially the Genesis agent server running inside those containers. Snowflake itself has written about how this integration works and why it matters for enterprise teams — you can read their perspective on the Snowflake blog. So if you're a Snowflake customer, running it inside your Snowflake account is a straightforward path, and it gives you a strong security posture because you inherit everything you already trust Snowflake for. Databricks has similar capabilities for running containers inside its platform.

If you're curious how Genesis integrates natively with Snowflake as a foundation for data work, Launching the Genesis App through the Snowflake Marketplace walks through that setup.

Deploying on AWS or Azure

Most of our customers are either AWS or Azure shops. On the AWS side, people are generally comfortable running applications and containers via EC2 or ECS, and we provide Terraform deployment scripts that make it easy to set up our server in those environments. On the Azure side, customers can run our system in Azure containers or Azure VMs, and we have Terraform scripts for that setup as well.

On-Premise and Kubernetes Deployment

The other option is to run it somewhere else entirely. If an organization has a Kubernetes cluster, the agent server can run there too. Some hedge funds run on-premises Kubernetes clusters and want everything inside their own building, and that works fine. Because our software ships as a container, it can run in any of these environments. All of them, from a security and access control perspective, are generally seen as better than running an agent in a third-party vendor's cloud, where you have to rely entirely on their security protocols.

Why Deployment Location Matters for Data Agents

This matters even more for data agents specifically, because ideally you're giving them broad access to your organization's data sets, both structured and unstructured. Broader access than you would normally give to a typical SaaS platform. SaaS platforms generally work with data they help create. Salesforce, for example, is largely working with data that lives inside Salesforce. Agents are different. Data agents are accessing data that's already resident in your enterprise, potentially large amounts of it across many systems. That's why running agent platforms inside an already-trusted, secured, and monitored enterprise environment is generally the right approach.

For more on how this plays out in data engineering workflows specifically, see How Genesis Automates Data Pipeline Development in Hours.

Access Control for Data Agents

When thinking about how to secure data agents, there are two things to consider. One is the access that the agents themselves have to enterprise systems and underlying data sets. The other is what users can do with those agents. For a full technical breakdown of how Genesis handles architecture and security, the Genesis Data Agents Architecture & Security FAQ is a good reference.

Treating Agents Like People

The approach we find most useful is to treat data agents as you would a person, and to give each agent access rights accordingly. In your Snowflake, Databricks, JIRA, GitHub, Google Drive, or SharePoint environment, you'd set up an account for each agent, either as a person or as a service account, depending on how your organization is classifying non-human users. You give them an access key or account, then in the Genesis system you assign that access to the relevant agent. From there, the agent can use that access to query Snowflake or Databricks, run Python on Snowpark, interact with GitHub or JIRA, and so on. And you can monitor that agent's activity the same way you'd monitor a human's.

The broader thinking around how to manage agents as members of a team is worth reading about in 20 Years at Goldman Taught Me How to Manage People. Turns Out, Managing AI Agents Isn't That Different.

Setting Appropriate Access Levels

In terms of what kind and level of access to give a data agent, the right frame is generally: what would you give a new employee? That usually comes with limits. You wouldn't hand full administrative access to an entire system to someone on day one, and the same applies to agents. Think about read access to certain data sets, write access to specific schemas or play spaces, and work from there. The agent server manages all of this, securely holding the roles, rights, and keys that each agent will use. Genesis's origins in the Snowflake ecosystem — covered in depth on the Snowflake Builders Blog — inform a lot of how this permissioning model was designed from the ground up.

For a more detailed look at how access control, role-based permissions, and caller limits work in practice, the third post in this series goes deeper: Agent Server [3/3]: Agent Access Control Explained: RBAC, Caller Limits, and Safer A2A.

Frequently Asked Questions

Why run the agent server inside our own environment instead of a vendor's cloud? When a data agent has broad access to your organization's data, you want full visibility into what it's doing and full control over who can reach it. Running the agent server inside your own environment, whether on Snowflake, AWS, Azure, or on-premise, means you're applying security and monitoring you already trust rather than depending entirely on a third party's protocols.

What does it mean that the Genesis agent server is a Docker container? It means it's portable. Docker is a standard packaging format for software, so the Genesis agent server can run anywhere your organization is already comfortable running containers, including Snowflake, Databricks, EC2, ECS, Azure, or a Kubernetes cluster. Most large enterprises already have this infrastructure in place.

How do we control what a data agent can access? Each agent is set up with its own account or service account in the relevant systems (Snowflake, GitHub, JIRA, etc.), with permissions scoped to what that agent actually needs. The Genesis agent server manages those credentials securely. You can also monitor agent activity the same way you'd monitor a human employee's access.

Can Genesis agents run on-premises? Yes. If your organization runs an on-premises Kubernetes cluster, the Genesis agent server can run there. Some financial services firms, including certain hedge funds, prefer keeping everything inside their own infrastructure, and the container-based deployment supports that.