Your AI agent needs to answer one question: “Can we ship 12 units by Friday?” The agent runs in your cloud. The inventory system runs inside your customer’s network. The customer won’t open an inbound firewall port.
You get it working at the first site. Then a second customer signs, and their security team asks which agent needs access, which system it can reach, and how they can revoke that access. They want answers for their environment, and your engineering team is back in the deployment meeting.
I asked people on Reddit how they handle this. Two suggestions stood out: use an outbound tunnel where appropriate, and give the agent a narrowly defined operation such as looking up an item’s stock. Those ideas address different parts of the same deployment. The useful question is how to put them together in a way you can repeat.
To connect a cloud AI agent to a private system, run a small service inside the customer’s network that can reach the system and initiate an outbound connection. Authorize the specific agent that needs to use it, and limit what the service will do on that agent’s behalf. Repeat the setup with separate identities and permissions for each customer.
What does an outbound tunnel actually solve?
An outbound tunnel lets software inside a private network initiate a connection from the inside. That can give an approved remote client a route to a service without opening an inbound firewall port at the customer site. The customer still needs to allow the required outbound traffic. Cloudflare Tunnel is one example of this pattern. Cloudflare Tunnel documentation
When evaluating a tunnel or any other private connection, ask three separate questions. Where can traffic go? Which agent can send it? What can that agent do when the request arrives? Your tunnel provider may offer access controls, and the application still needs to enforce permissions for the operations it exposes.
How can a cloud agent check inventory without broad database access?
Put a small connector inside the customer’s environment and give it one job: look up stock for a specified item. The cloud agent sends the item ID. The connector checks the request, queries the private system using scoped credentials, and returns the permitted result. The application can expose a named operation like check_stock(item_id) while keeping raw SQL access inside the customer’s environment.
Then test who can use that connection. The ordering agent should reach the inventory connector. An unrelated agent in the same cloud should be denied. The first customer’s agent should also be denied when it tries to reach the second customer’s connector. Tying the connection policy to authenticated identities gives teams a way to make those distinctions.
What should you repeat for the second customer?
Repeat the deployment steps and tests, and give each customer its own identities and access policies. Before calling the first pilot done, write down how to do these four things:
- Install the connector. Document where it runs and what outbound connectivity it requires.
- Approve one connection. Specify which agent can reach the connector and which operation the connector exposes.
- Prove the boundaries. Test an approved lookup, a denied request from an unrelated agent, and a denied connection across customers.
- Revoke access. Remove the agent’s permission and verify the result with another connection attempt.
Run the same checklist at a second site. Track the engineering work and the security review separately. If the installation takes an afternoon but access approval takes several rounds of review, you’ve learned where to focus before the next rollout.
Where does Cynapsa fit?
Cynapsa is an identity-based network for AI agents. In this setup, it governs which authenticated agent can connect to which peer across cloud and private environments. The application on the customer’s side still decides whether it will perform the inventory lookup and what it returns. That lets you use the same connection pattern across deployments while defining each customer’s permissions separately.
Frequently asked questions
Can a cloud AI agent query an on-premises database without opening an inbound port?
Yes, when the customer permits a supported outbound connection. A connector inside the customer’s network can query the database locally and return the result. The database can keep its existing private endpoint.
Is an outbound tunnel enough for an enterprise AI deployment?
A tunnel may be enough for reachability. Check how your setup authenticates each agent, scopes access to the right customer and service, and revokes permissions. Also check how the receiving application limits the actions it will perform.
Does MCP provide private network access?
MCP defines how an AI application discovers and invokes tools, among other capabilities. To call a remote MCP server, the client still needs a working transport path to it and any authorization the server requires.
Can sensitive data stay on-premises?
The connector can run the operation locally and return a limited result. For example, it could return whether an item is in stock while keeping supplier records inside the private environment. Review the fields in the request and response, plus what the application writes to logs, to see what data actually leaves.
How do you stop one customer’s agent from reaching another customer’s tools?
Give each deployment separate identities and explicit connection rules. Test the boundary directly by trying to connect Customer A’s agent to Customer B’s connector. Verify that the attempt is denied even if both agents run in the same cloud.
What’s a good first use case to test?
Choose one read-only workflow with a real dependency on a private system, such as looking up inventory. It gives engineering and security a concrete request to review and a simple test to repeat at the next customer site.
If you’re building an agent that needs to reach a customer’s private systems, explore how Cynapsa handles agent connectivity.