---
title: Give your eve agent secure access to your private AWS RDS database
description: Connect an eve agent to a private AWS RDS database using Vercel Secure Compute and VPC peering, with a read-only query tool.
url: /kb/guide/give-eve-agent-secure-access-to-aws-rds-database
canonical_url: "https://vercel.com/kb/guide/give-eve-agent-secure-access-to-aws-rds-database"
published: 2026-08-06
last_updated: 2026-08-06
authors: Evan Eissler
related:
  - /docs/eve
  - /docs/connectivity/secure-compute
  - /docs/connectivity/static-ips
install_vercel_plugin: npx plugins add vercel/vercel-plugin
---

You can build an agent on Vercel with eve without managing a server. The agent becomes much more useful when it can read your real data, but that data often lives in a private database in another cloud provider. It is usually blocked from the public internet on purpose.

That means the first blocker is usually security, not code.

Vercel uses this pattern internally with **d0**, an eve agent that acts as a data analyst and scopes every query to the person asking. This guide shows how to build the same pattern for your own agent.

In this guide, you'll learn how to:

- Choose between Secure Compute with VPC peering and Static IPs with an allowlist.
  
- Set up VPC peering between Vercel and AWS.
  
- Write an eve tool that queries your database from a Vercel Function.
  
- Keep database queries out of the Sandbox unless you explicitly open the Sandbox network path.
  

## Two networking options: Secure Compute and Static IPs

There are two separate jobs:

- **Create a private network path** so the agent can reach the database without exposing it to the internet.
  
- **Use a locked-down login** so the agent connects with short-lived, least-privilege credentials instead of a long-lived password.
  

For the private network path, the production approach is **Secure Compute with VPC peering**. This creates a direct private connection between your Vercel project's network and your cloud network. Your database can keep no public address, and the agent can still reach it because traffic stays off the open internet.

If you are just getting started, **Static IPs with an allowlist** are the faster option to set up. Your database still receives traffic over the public internet, but it only accepts traffic from your Vercel project's static IPs. Static IPs assigns addresses from a shared pool, so use this path only when that security model fits your database policy.

| Option                              | Best for                                                                                                     | Availability                               | Setup effort                           |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------ | ------------------------------------------ | -------------------------------------- |
| **Static IPs with an allowlist**    | Getting started quickly, or semi-sensitive projects where public ingress from known Vercel IPs is acceptable | Pro and Enterprise, $100/month per project | Faster                                 |
| **Secure Compute with VPC peering** | Production workloads where the database should stay private and off the public internet                      | Enterprise                                 | More setup, stronger network isolation |

Use Static IPs when speed matters and your database policy allows traffic from Vercel's shared static IP pool. Use Secure Compute when you need a private network path between Vercel and AWS.

The important eve detail is this:

**eve agents run on Vercel Functions. Functions in a Secure Compute project use the private peered path automatically.**

You do not need special networking code in the agent. Attach the project to the network, and database queries from the agent tool route privately.

## The key gotcha: where the query runs

This is the part people often miss.

eve can run code in two places, and each place uses a different network path:

- **An eve tool** runs on a Vercel Function. If the project uses Secure Compute, the tool can reach your private database over VPC peering automatically.
  
- **A bash command in the Sandbox** runs in an isolated microVM with its own network. It does not inherit the Secure Compute peering connection, so it cannot reach your private database by default.
  

The rule:

**Run database queries in an eve tool, not in the Sandbox.**

The tool should fetch the rows, then pass the results back to the model. For a data analyst agent, this is usually all you need.

Only use the Sandbox path if you specifically need model-generated code to connect directly to the database. In that case, you must explicitly open the Sandbox firewall to the database's private IP range.

## Set up VPC peering between Vercel and AWS

This part is one-time setup in the Vercel and AWS dashboards. First create the private network path, then attach your project to it, then open the AWS routes and security rules that let traffic flow. That last step is easy to overlook: a peering connection can show as connected but still fail if the route tables or security groups are missing.

1. **Create the Vercel network.**
   
   Go to Team Settings → Networking → Create Network. Pick the region closest to your database and a CIDR range that does not overlap with your AWS VPC. If the ranges overlap, peering routing breaks.
   
   If you do not see the Create Network button, contact your Vercel account team; self-service network creation is not available to every Enterprise team.
   
   Vercel gives you the values you need for AWS: a VPC ID, an AWS account ID, a peering connection ID, and the region.
   
2. **Create the peering request in AWS.**
   
   The request starts in AWS and is accepted back in Vercel. In the AWS VPC dashboard, create a peering connection and map the Vercel values to the accepter fields:
   
   - **Requester VPC:** your AWS VPC that holds, or can route to, the database.
     
   - **Accepter peering ID:** the Vercel peering connection ID.
     
   - **Accepter account ID:** the Vercel AWS account ID from the dashboard.
     
   - **Accepter region:** the region of your Vercel network.
     
   
   Then return to the Vercel Networking page and click **Accept**.
   
3. **Attach your project to the network.**
   
   Go to Project → Settings → Networking and set the Active Network for each environment that needs database access, such as Production and Preview. This is the step people skip. Creating the network does not attach anything; this is what puts your agent's functions on the private network.
   
4. **Open the AWS side.**
   
   Two settings make traffic actually flow. Add a route from the database's subnets to the Vercel network range over the peering connection. Then update the database's security group to allow its port, such as 5432 for Postgres or 3306 for MySQL, from the Vercel range.
   
5. **Sanity-check the setup.**
   
   Confirm the CIDR ranges do not overlap, the database is reachable at its private host, and your data-access code is on the standard runtime, not Edge. Secure Compute does not cover Edge.
   

Once these are done, a Vercel Function in that project can reach the database at its private address. everything from here is code, and it is just one tool.

## The eve tool

The agent can be as simple as instructions plus one tool.

Create a tool like this:

```tsx
import { defineTool } from 'eve/tools';
import { z } from 'zod';
import { Pool } from 'pg';

// Created once and reused across calls.
// Fluid Compute helps keep it warm.
const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
});

export default defineTool({
  description: 'Run a read-only SQL query against the analytics DB and return rows.',
  inputSchema: z.object({
    sql: z.string().describe('A single read-only SQL SELECT statement.'),
  }),
  async execute({ sql }) {
    const client = await pool.connect();

    try {
      const { rows } = await client.query(sql);
      return {
        rowCount: rows.length,
        rows,
      };
    } finally {
      client.release();
    }
  },
});
```

Set `DATABASE_URL` as an environment variable that points to the database's private host:

```bash
DATABASE_URL=postgres://readonly_user:••••@my-db.internal.abc123.us-east-1.rds.amazonaws.com:5432/analytics?sslmode=require
```

Point `DATABASE_URL` at a read-only role. The tool description alone doesn't enforce anything.

That is all the network code you need. Because the function runs in a Secure Compute project, `pool.connect()` reaches the private database over VPC peering.

## Agent instructions

Point the agent at the tool in `agent/`[`instructions.md`](http://instructions.md):

```markdown
You are a data analyst.

When the user asks about data, call query_db with a single read-only SELECT statement.

Never write or mutate data.

Summarize the rows you get back.
```

That is the core agent: instructions plus one tool.

## What happens at runtime

Here is the request flow:

1. A user asks the agent a question.
   
2. eve starts the turn on a Vercel Function.
   
3. The model calls `query_db` with a read-only SQL query.
   
4. The tool runs on your Secure Compute network.
   
5. The tool opens a connection to the private database over VPC peering.
   
6. Rows come back to the model.
   
7. The model summarizes the result.
   
8. The response streams back to the user.
   

You can inspect the tool call, SQL, and returned rows in the **Agent Runs** dashboard without extra setup.

## Final checklist

- Project is joined to the Secure Compute network for each environment.
  
- AWS routes the database subnets to the Vercel network range over the peering connection.
  
- The database security group allows the Vercel network range on the database port.
  
- The database is reachable at its private host.
  
- The database connection is encrypted in transit (Postgres: `sslmode=require`; MySQL: an `ssl` option in the driver config).
  
- Queries run in an eve tool, not in the Sandbox.
  
- The database role is read-only and least privilege.
  
- Data access code runs on the standard runtime, not Edge. Secure Compute does not cover Edge.
  

## Next steps

- [eve](https://vercel.com/docs/eve): define agents, tools, and sandboxed code, and watch runs in the dashboard.
  
- [Secure Compute](https://vercel.com/docs/connectivity/secure-compute): set up dedicated networks and VPC peering.
  
- [Static IPs](https://vercel.com/docs/connectivity/static-ips): use the quick-start allowlist path.