Point an agent at data that has to stay inside the company

This category shows up whenever the request is “let an agent query our own database or internal API” - a shipment tracker, a customer-support backend, an internal metrics store. The server itself holds no data; it's a narrow, purpose-built proxy in front of something that already exists, usually restricted to reads. That narrowness is deliberate: a connector with three specific tools (shipments_for_route, delay_reason, eta, say) is far easier to reason about and secure than one generic run_query tool that happens to accept SQL.

This is also the category where foro's security model does the most work, because the thing being exposed usually can't tolerate a mistake. Whatever credential the server needs to reach the internal system - a database replica's connection string, an internal API token - lives as an encrypted secret, injected into the container at start and never written to disk anywhere in the clear.

The deployed server also sits on its own Docker network, created for that project alone, invisible to every other team's deployed server on the same box and unable to reach foro's own internal services. That isolation is worth reading precisely, because it's easy to assume more than it says. It separates tenants from each other and from the platform; it doesn't restrict which upstream hosts the tools may call. Ordinary outbound HTTPS works the way it would from any container. What gets blocked is another project, the platform internals, and the usual abuse routes such as mail relay on port 25.

Then there's who's allowed to ask it questions. Every deployed server can run on a single shared token, which is fine for a connector one or two people use. For a team, OAuth 2.1 is the better fit and comes as a per-project setting: people sign in with the identity provider the company already runs - Azure Entra ID, brokered straight through - instead of a shared secret sitting in a channel somewhere. Each person's token is scoped to that one project specifically, so a leaked token from this server is worthless against any other project the company has deployed. For teams with EU data-residency requirements, where the platform runs - a fully European cloud with no non-EU parent company - is usually the detail that gets asked about first.

For something handling live customer data, testing a new tool doesn't mean guessing at what it returns - running it through the Playground passes the result through the same PII scrubber that guards the dashboard's own chat, so a raw shipment record with a customer's name or address doesn't end up pasted into a conversation by accident while someone's debugging. And every call is counted: the Tools tab shows how many times delay_reason ran this week, its error rate, and its latency - the kind of detail a security review asks for anyway, already sitting there rather than needing to be built.

• Fits cleanly when access can stay read-only and every caller can be scoped to the same project-level permissions.
• Doesn't fit yet if different outside customers need to hit the same server with different, customer-specific permissions - that's a different hosting shape (one server, many tenants) than the one-container-per-project model foro runs today.