# Prerequisites > The access and environment requirements to verify before using Tetrate Agent Router, covering what developers and administrators each need from day one. Before starting with Tetrate Agent Router, verify that you have the following access and environment requirements in place. This page covers what each role needs (developers and administrators) to use Agent Router successfully from day one. ## Management Plane and Data Plane The very first prerequisite for installing, configuring or using a self-hosted data plane, is a provisioned Management Plane. Both the provisioning and operational management is done by Tetrate, making the management plane a hosted components. At the moment, it is not possible to fully self-host Agent Router Enterprise, only the data plane. ![management-vs-data-plane](/img/screenshots/about/architecture/TARE_arch.png) For more information on hosting options and the underlying architecture, consult [Planes and core components](/product-architecture/planes-and-components/). ## Account access Tetrate Agent Router serves different web applications, each serving a distinct role. Depending on your function, you may need access to one or both. | Requirement | Details | | --- | --- | | **User account** | An email/password or SSO credential provided by your administrator. For Proof-of-Concept (PoC) environments, Tetrate provisions accounts with appropriate roles. | | **Console URL** | The developer-facing application for API keys, model routing, and usage monitoring (e.g., `https://router.tare-pn-12345678.tetrate.ai/`) | | **Admin Dashboard URL** | The operator-facing application for managing models, providers, and users (e.g., `https://dashboard.tare-pn-12345678.tetrate.ai/`) | Your administrator will provide URLs and initial credentials during onboarding. If your organization uses SSO, you will authenticate through your corporate identity provider; no separate password is required. Agent Router access is role-based: each user is granted access only to the applications appropriate to their function. ## Browser requirements Tetrate Agent Router is fully browser-based; no desktop software installation is required. Both applications support the following browsers: - Google Chrome 90+ - Mozilla Firefox 90+ - Microsoft Edge 90+ - Safari 15+ JavaScript must be enabled. A screen resolution of 1280×720 or higher is recommended for the best experience, particularly when viewing usage dashboards and request log details. ## For developers (Console users) Developers use the Console to create API keys, browse the model catalog, configure routing policies, and monitor usage. In addition to account access, you will need: | Requirement | Purpose | | --- | --- | | **API key** | Generated in the Console under **API Keys**. Authenticates all AI requests sent through the gateway and determines which routing policies apply. | | **Proxy endpoint URL** | The address your application sends requests to instead of calling AI providers directly. The gateway handles routing, fallback, guardrail enforcement, and provider translation transparently. Shown on your Dashboard (e.g., `https://my-first-proxy.acme.com`). | | **SDK or HTTP client** | Any OpenAI-compatible client library or HTTP tool. No gateway-specific SDK is required. | ### Supported SDKs and tools Tetrate Agent Router is compatible with any tool or library that speaks the OpenAI API format. To connect, replace the provider's base URL with your proxy endpoint URL and use your Console API key. No other changes are required. | Category | Examples | | --- | --- | | **Python libraries** | `openai`, `langchain`, `crewai`, `pydantic-ai`, `llama-index` | | **TypeScript/JavaScript** | `openai` SDK, Vercel AI SDK | | **Code assistants** | Cline, Aider, Continue, Roo Code, Goose | | **Chat interfaces** | Open WebUI | | **MCP clients** | Claude Code, Cursor, VS Code | For step-by-step setup instructions for each tool, see [Integrations](/agent-router-service/guides/integrate-the-gateway-with-an-app/). ## For administrators (Admin Dashboard users) Administrators use the Admin Dashboard to manage model availability, configure AI provider credentials, control user access, and maintain Agent Router audit trail. You need: | Requirement | Purpose | | --- | --- | | **Admin role** | Assigned by a Agent Router administrator. Grants access to the Admin Dashboard and all operator-level controls. | | **Provider credentials** | API keys for each AI provider you plan to configure (e.g., OpenAI, Anthropic, Azure OpenAI, Google Vertex AI). These are stored securely by Agent Router and are never exposed to Console users. | | **SSO metadata** | OIDC discovery URL, issuer, client ID, and client secret from your corporate identity provider. Agent Router supports OIDC only. | In PoC environments, provider credentials and initial Agent Router configuration are preconfigured by Tetrate. Administrators can review and modify these settings from first sign-in. ## Network requirements Where network firewalls, security groups, or outbound proxies are in use, the connections listed below must be permitted. ### Endpoints, direction, and ports Direction is stated from the customer's perspective: **Out** is traffic that leaves the customer domain, **In** is traffic that enters it. All ports are TCP, and every Tetrate-hosted endpoint is HTTPS on port 443. Tetrate-hosted endpoints follow the pattern `..tetrate.ai`, where `` is the identifier issued during onboarding (for example `tare-pn-12345678`). Which connections apply depends on the deployment model, and the difference is larger than it first appears. In a Self-Hosted Data Plane deployment the gateway runs in a customer-managed cluster, which is what makes the cluster-side rows and the single inbound path necessary. In an [Enterprise Fully Managed](/agent-router-enterprise/fully-managed/) deployment Tetrate runs both planes and nothing is installed in the customer environment, so every required connection is outbound from a browser or an application and no inbound rule exists at all. Both tables are given below; see [Deployment models](/product-architecture/deployment-models/) for the wider comparison. #### Self-Hosted Data Plane This is the model described by this section: Tetrate hosts the management plane, and the Controller and the gateway run in a customer-managed Kubernetes cluster. | Endpoint | Direction | Port | Opened by | Purpose | | --- | --- | --- | --- | --- | | `https://router..tetrate.ai` | Out | 443 | Developer browsers | Console access: API keys, model catalog, usage monitoring | | `https://dashboard..tetrate.ai` | Out | 443 | Administrator browsers | Admin Dashboard access: models, providers, users, settings | | `https://auth..tetrate.ai` | Out | 443 | All browsers, at sign-in | Authentication, including the OIDC callback used by SSO | | `https://api..tetrate.ai` | Out | 443 | Controller, from inside the cluster | Configuration polling and data plane health reports (`/v1/dataplane-status`) | | `https://registry.tetrate.ai` | Out | 443 | Cluster nodes and the install host | Container images and the Helm chart. Install and upgrade only, and avoidable by mirroring to a private registry | | `https://tare.tetrate.ai` | Out | 443 | Operator workstation | `tare` CLI download. Once per workstation, not needed by the cluster | | AI provider APIs, such as `https://api.openai.com` and `https://api.anthropic.com` | Out | 443 | Gateway | Model requests to each configured provider. Not required where every provider is self-hosted or reached over private connectivity | | Remote MCP servers referenced by MCP profiles | Out | 443 | Gateway | MCP tool calls to servers hosted outside the cluster | | External observability backend, such as `https://otlp.nr-data.net` or `https://trace.agent.datadoghq.com` | Out | 4317 (OTLP gRPC) or 443 | In-cluster OpenTelemetry collector | Telemetry export. Not required where the observability stack runs inside the customer environment | | `https://acme-v02.api.letsencrypt.org` | Out | 443 | cert-manager | Certificate issuance for the gateway hostname. Only where Let's Encrypt is used rather than an internal certificate authority | | Gateway endpoint on a customer-owned hostname, such as `https://ai-gateway.acme.com` | In | 443 | Client applications, agents, and coding assistants | AI request routing. This ingress is created and controlled by the customer and can be internal-only. It terminates on the in-cluster `egress` service on port `10080` | | Corporate OIDC identity provider: discovery, authorization, and token endpoints | In | 443 | Tetrate-hosted authentication service | Validation of the discovery document and exchange of the authorization code. Applies only where the identity provider is self-hosted and not otherwise reachable from outside the customer domain. No rule is needed for a SaaS identity provider such as Entra ID, Okta, or Google | | Let's Encrypt HTTP-01 challenge validation | In | 80 | Let's Encrypt validators | Certificate issuance only. Avoidable with the DNS-01 solver or a certificate supplied from an internal public key infrastructure | | Tetrate management plane into the cluster | None | None | Nothing | No connection is ever initiated from Tetrate into the customer environment, so no inbound rule is required on Tetrate's behalf | Only two of these entries are unavoidable: the outbound connection from the Controller to `api..tetrate.ai`, and the inbound path from client applications to the gateway, which the customer defines. Every other row is either conditional on a feature being used or removable, as described in the sections that follow. #### Enterprise Fully Managed, for comparison Nothing is installed in the customer environment, so there is no cluster, no ingress to create, and no cluster-side egress. The gateway is Tetrate-hosted and is called outbound like any other SaaS API. | Endpoint | Direction | Port | Opened by | Purpose | | --- | --- | --- | --- | --- | | `https://router..tetrate.ai` | Out | 443 | Developer browsers | Console access: API keys, Base URL, request logs, usage | | `https://dashboard..tetrate.ai` | Out | 443 | Administrator browsers | Admin Dashboard access: models, providers, users, settings | | `https://auth..tetrate.ai` | Out | 443 | All browsers, at sign-in | Authentication, including the OIDC callback used by SSO | | `https://proxy..tetrate.ai/v1` | Out | 443 | Applications, agents, and coding assistants | AI request routing. This is the Base URL shown in the Console, and it is the row that reverses direction in a Self-Hosted Data Plane deployment, where the same function is served by a customer-owned hostname | | Corporate OIDC identity provider: discovery, authorization, and token endpoints | In | 443 | Tetrate-hosted authentication service | As in the self-hosted case, and required only where the identity provider is self-hosted and not otherwise reachable from outside the customer domain | Three consequences of the model are worth noting before a firewall change request is raised: - Nothing that appears in the self-hosted table as cluster-side traffic applies. `registry.tetrate.ai` and `tare.tetrate.ai` are not contacted, no certificate is issued for a customer hostname, and no inbound rule is opened for the gateway. - Connections to AI providers and to remote MCP servers originate from Tetrate's environment rather than the customer's. Where a provider account restricts access by source address, the allowlist must therefore cover Tetrate's egress and not the customer's. - Telemetry export to a customer-hosted observability backend is the one case that reverses direction, since the exporter would run on Tetrate's side. Confirm the arrangement with Tetrate before assuming a self-hosted collector can be used. The remainder of this page describes the self-hosted case. ### Data plane connections In a [Self-Hosted Data Plane](/agent-router-enterprise/self-hosted-data-plane/) deployment the data plane (the Controller and the Agent Router gateway) runs in a customer-managed Kubernetes cluster, and Tetrate hosts the management plane. The connections the cluster needs are listed below, stated relative to the customer environment. | Direction | Connection | Port | Required | | --- | --- | --- | --- | | Outbound | Controller to the management plane, for configuration polling | 443 | Yes. This is the only connection the data plane needs in steady state. | | Outbound | Gateway to AI provider endpoints | 443 | Yes, unless every configured provider is self-hosted or reached over private connectivity. | | Outbound | Cluster to `registry.tetrate.ai`, for container images and the Helm chart | 443 | At install and upgrade only. Avoidable by mirroring the images and chart into a private registry. | | Inbound | Client applications to the gateway | 443 | Yes, but this ingress is created and controlled by the customer, and it can be internal-only. | | Inbound | Tetrate or the public internet into the cluster | None | No. Nothing outside the environment opens a connection into the data plane. | Mirroring images and the chart to a private registry is covered under [Data plane installation](/agent-router-enterprise/self-hosted-data-plane/data-plane-installation/); keeping provider traffic off the public internet is covered under [Private provider connectivity](/product-architecture/network-and-security/#private-provider-connectivity). ### Outbound-only applies to every self-hosted deployment The outbound-only design is a property of the architecture, not a separate deployment mode. [Network and Security](/product-architecture/network-and-security/) discusses it under the heading **Intranet deployment**, which describes the most restrictive network posture rather than a distinct product configuration: the whole page applies to Self-Hosted Data Plane deployments. A standard self-hosted install therefore has the same property as the intranet case. The management plane never opens a connection into the customer environment, and no inbound firewall rules are needed on Tetrate's behalf. What an intranet posture adds is a choice the customer makes about the gateway's own ingress. Where every application calling the gateway is itself internal, the gateway can be exposed on an internal address only and no public ingress is needed at all. ### Summary for a security review The points a security team most often asks about, collected for a review or a firewall change request: - The management plane never initiates a connection into the customer environment. There is no exposed listener for Tetrate to call and no inbound firewall rule to open. - Configuration reaches the data plane over a single outbound HTTPS connection on port 443, opened from inside the cluster by the Controller and used to poll for updates. - Prompts and responses travel only through the data plane in the customer's environment. The outbound configuration connection carries configuration, not request content. What request detail is sent to the management plane is itself configurable; see [Control what request data leaves the cluster](/agent-router-enterprise/guides/operate-and-govern/cost-and-quota-management/configuring-request-logs/). - Traffic to AI providers can be held on private connectivity (Azure Private Link, AWS PrivateLink, GCP Private Service Connect) so it never crosses the public internet, and a fallback chain built only from private endpoints cannot route to a public provider. - Gateway ingress is the customer's own. It can be restricted to internal networks, and mutual TLS can be required of callers. - Registry access is needed only at install and upgrade, and can be removed entirely by mirroring images and the Helm chart into a private registry. Full detail on each control, written for a reader without a networking background, is in [Network and Security](/product-architecture/network-and-security/). For topology, see [Deployment models](/product-architecture/deployment-models/) and [Architecture Overview](/product-architecture/architecture-overview/). ### The Data plane URL field The onboarding wizard's **Data plane URL** field is described in the interface as the URL the management plane uses to reach the AI Gateway. That label is misleading and has caused the field to be read as an inbound connection requirement. It is not one. The value is the customer-facing gateway URL, the address that **client applications** call. The management plane stores it against the workspace and pushes it into the data plane's own configuration, so that the Console can show developers the endpoint to use and the gateway knows the address it serves. Nothing in the management plane dials it. Three consequences follow, all useful to know before onboarding starts: - The URL does not need to be reachable from the management plane or from the internet. It needs to be reachable by whatever calls the gateway, so an internal-only hostname is correct when every caller is internal. - The URL does not need to resolve at install time. It is recorded as configuration, and DNS can be wired afterwards. - The field is optional. It can be left empty during onboarding and registered later under **System → Settings → Data planes**, or passed to `tare install --serve-url`. See [Management plane onboarding](/agent-router-enterprise/self-hosted-data-plane/onboarding/) for the field in context, and [Manage multiple gateways on a data plane](/agent-router-enterprise/guides/operate-and-govern/project-and-data-plane-management/manage-gateways-on-a-data-plane/) for why a data plane can own more than one such URL. ## Kubernetes requirements Self-hosted data plane installs require a Kubernetes cluster running **Kubernetes 1.32 or later**. ## Which version to install The registry publishes a long list of versions carrying pre-release identifiers such as `alpha` and `rc`, which makes the choice look more consequential than it is. Which version applies depends on the install path. **With `tare install`, no version is chosen.** The CLI carries an embedded Helm chart and deploys that, so the data plane version follows the version of the `tare` binary in use. Installing a current CLI is the whole of the decision, and `tare --version` reports what is installed. The `--chart-version` flag exists only for overriding the embedded chart with a remote or OCI one through `--chart-path`, which is not the usual path. **With a direct Helm install**, a version is required, because the chart is pulled from the registry as an OCI artifact: ```bash CHART_VERSION="0.1.0-alpha.1+17f076b" ``` Unless Tetrate has pinned a version for the deployment, use the most recently published chart version. The pre-release identifiers currently in use reflect a pre-1.0 release train that is moving to a plain SemVer scheme; they are not a reason to prefer an older tag, and there is no separate stable channel to select from. Where a version is being chosen for a production install, confirm the intended one with Tetrate rather than inferring it from the tag list. Two constraints on the version string itself cause most install failures: - The value must be a full SemVer version. A bare commit SHA is rejected before Helm contacts the registry. - Build metadata is joined with `+`, as in `0.1.0-alpha.1+17f076b`. The registry stores the same tag internally with `_`, but Helm's `--version` requires the `+` form. A release-build version such as `v0.1.0-beta.3` is also accepted. Record the version that was installed, since upgrades and support conversations both depend on knowing it. The mechanics of both paths, including mirroring the chart to a private registry, are in [Data plane installation](/agent-router-enterprise/self-hosted-data-plane/data-plane-installation/) and the [`tare install` reference](/reference/tare-cli/install/). ## SSO requirements Single sign-on (SSO) lets users access the Console and Admin Dashboard through your corporate identity provider. Any OIDC-compliant identity provider is supported. Before configuring SSO, collect the following details: - Issuer (Identity Provider URL) - Client ID - Client Secret - Discovery URL (optional) **When SSO is required depends on your deployment path.** Open your path from the Get started sidebar, or see Deployment models if you are unsure which applies. - **Agent Router Service:** SSO is handled by Tetrate; no customer SSO setup. - **Enterprise Fully Managed:** Configure SSO during onboarding (wizard Step 2) or confirm it is already set up in a PoC environment. - **Enterprise Self-Hosted Data Plane:** Gather SSO details early. SSO can be configured after the data plane and gateway are running, provided it is done before opening the Console to developers. In Tetrate-provisioned PoC environments, SSO may already be configured; confirm with your administrator before starting the onboarding wizard. Mapping IdP roles to Agent Router roles is optional and can be done after the data plane is running. ## Evaluation checkpoint Use this checklist to confirm your environment is ready before proceeding to the quickstarts: - [ ] you have completed Management plane onboarding (triggered when first opening the Admin Dashboard) - [ ] You can access the Console URL and sign in successfully - [ ] You can access the Admin Dashboard URL (if applicable to your role) - [ ] Your browser meets the minimum version requirements - [ ] For self-hosted data plane installs: your cluster meets the [Kubernetes version requirement](#kubernetes-requirements) - [ ] For self-hosted data plane installs: outbound HTTPS on port 443 from the cluster to the management plane is permitted, and any security review has the [connection summary](#summary-for-a-security-review) - [ ] For self-hosted data plane installs: the [version to install](#which-version-to-install) is known, whether that is a `tare` CLI version or an explicit chart version - [ ] You have an API key (or can create one in the Console) - [ ] You know your proxy endpoint URL Where to go next Management plane onboarding Continue self-hosted setup: sign in to the Admin Dashboard and complete organization details, providers, and models. Self-Hosted Data Plane See the full install sequence from management plane onboarding through developer handoff.