Deploy the Remote Agentic Gateway (BETA)

Connect AI clients to Apono through a shared HTTPS endpoint

The Remote Agentic Gateway is currently available through a private beta program. Contact your Apono representative for setup information.

The Remote Agentic Gateway connects AI clients to Apono through a shared HTTPS endpoint. It runs centrally as the proxy service of an Apono connector in your environment, so users do not need to install or run the gateway on their local machines. One deployment can serve multiple users and AI clients that can reach the endpoint.

---

How the Remote Agentic Gateway works

1. The AI client connects to the gateway. The client sends MCP requests to https://<HOSTNAME>/mcp.

2. The ingress or load balancer routes the request. It terminates TLS and forwards HTTP traffic to the <CONNECTOR_ID>-proxy service on port 10020.

3. The connector proxy brokers the request through Apono. The applicable agentic access flow governs temporary access, and the MCP’s intent policy governs the tool call. Credentials are not exposed to the AI model.

4. Apono records the activity. The agent and associated user appear in AI Agents, while AI Sessions records access grants, tool calls, and policy decisions.

One gateway deployment can support multiple users and AI clients that can reach the endpoint.

The Remote and Local Agentic Gateways provide the same Apono access controls. Only the deployment model differs. To run the gateway on each user’s machine instead, see Install the Local Agentic Gateway.

---

Prerequisites

Item	Details
Private beta access	Required program participation Your organization is participating in the Remote Agentic Gateway private beta.
Apono account setup completed	Enablement of MCP feature for the Apono account Confirm that an Apono admin has set up Apono Agent Privilege Guard: Enabled MCP features Connected the applicable integration Created an agentic access flow with Restrict to agentic access enabled Enabled the corresponding Apono Managed MCP
Apono connector	Connector deployment requirements Confirm the following: You have access to install or upgrade an Apono connector using Kubernetes and Helm. The Apono connector is version 1.8.4+. The apono-connector Helm chart is version 2.1.4+. For a new connector, obtain the connector ID and token from Apono.
DNS hostname	Hostname for the gateway endpoint, such as apono-agentic-gateway.<your-domain>
TLS certificate	Certificate that matches the hostname and is trusted by the AI client runtime
Ingress or load balancer	Endpoint that terminates HTTPS and forwards HTTP traffic to the connector proxy service on port 10020

Network requirements

Source	Destination	Port	Protocol
AI client runtime	Remote Agentic Gateway HTTPS endpoint	443	HTTPS
Ingress or load balancer	Connector proxy service	10020	HTTP
Connector	Apono API	443	HTTPS
Connector	Integrated target systems	As required	As required

---

Set up the gateway

Enable the connector proxy

Follow the steps:

1. Enable the connector proxy for a new or existing Apono connector.

New connector

A dedicated connector is recommended for the Remote Agentic Gateway. This isolates gateway traffic from other connector workloads and requires no additional sizing beyond the Helm chart defaults.

Create the connector in Apono and obtain its connector ID and token. Then add the following configuration to a new values.yaml file.

apono:
  connectorId: <CONNECTOR_ID>
  token: <APONO_CONNECTOR_TOKEN>

proxyService:
  enabled: true

Existing connector

You can reuse an existing connector when deploying a dedicated connector is not practical. Provide approximately one additional vCPU and 1.5 GB of memory for the agentic workload, then adjust the allocation based on actual usage.

Add the following configuration to the connector’s existing values.yaml file. Do not replace its other settings.

proxyService:
  enabled: true

The gateway connector must run as a single replica. Multiple replicas can route requests from the same session to different connector instances, resulting in unknown session errors.

1. Install the new connector or upgrade the existing connector using your Helm deployment process.

2. Confirm that the ${CONNECTOR_ID}-proxy service appears. The service exposes the gateway internally over HTTP on port 10020. If the service does not appear, confirm that proxyService.enabled is set to true, and then reinstall or upgrade the connector.

kubectl get svc -n ${NAMESPACE} ${CONNECTOR_ID}-proxy

Expose the connector proxy over HTTPS

Expose the ${CONNECTOR_ID}-proxy service through an ingress or load balancer that:

• Accepts HTTPS connections from AI client runtimes

• Uses a certificate that matches the gateway hostname

• Terminates TLS

• Forwards HTTP traffic to ${CONNECTOR_ID}-proxy on port 10020

The following example uses an AWS Application Load Balancer ingress on Amazon EKS.

Follow these steps:

1. Create an ingress.yaml file with the following configuration. Be sure to replace the placeholder values listed below.

This example creates an internal load balancer. Use an internet-facing endpoint only when required by your AI client and network architecture.

The unauthenticated / path can return 401 or 404 when the gateway is healthy. The ALB health check therefore accepts status codes from 200 through 499.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: apono-agentic-gateway
  namespace: <NAMESPACE>
  annotations:
    alb.ingress.kubernetes.io/scheme: internal              # internal LB; use internet-facing only if required
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: <ACM_CERT_ARN>   # cert matching <HOSTNAME>
    alb.ingress.kubernetes.io/backend-protocol: HTTP        # HTTP to the connector (TLS already terminated)
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/healthcheck-port: traffic-port
    alb.ingress.kubernetes.io/healthcheck-path: /
    alb.ingress.kubernetes.io/success-codes: "200-499"      # IMPORTANT: '/' returns 401/404 without auth - that is healthy
    external-dns.alpha.kubernetes.io/hostname: <HOSTNAME>
spec:
  ingressClassName: alb
  rules:
    - host: <HOSTNAME>
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: <CONNECTOR_ID>-proxy
                port:
                  number: 10020

Placeholder	Description
<NAMESPACE>	Namespace where the connector is installed
<CONNECTOR_ID>	ID of the connector running the gateway
<ACM_CERT_ARN>	ARN of the AWS Certificate Manager certificate matching the hostname
<HOSTNAME>	DNS hostname assigned to the gateway

1. Provision the ingress or load balancer using your existing deployment process.

2. Configure DNS and TLS:

   • Point <HOSTNAME> to the load balancer using an A or alias record.

   • If ExternalDNS is not configured, remove the external-dns.alpha.kubernetes.io/hostname annotation and create the record manually after the load balancer is provisioned.

   • Confirm that the certificate matches <HOSTNAME> and is trusted by the AI client runtime.

Register the endpoint in Apono

Follow these steps:

1. On the Connectors tab, in the row of the connector used for the Remote Agentic Gateway, click ︙> Edit. The Edit Connector page opens.

2. Click the Enable Agentic Proxy toggle. The Agentic Proxy Exposed Hostname field appears.

3. Enter the Agentic Proxy Exposed Hostname.

Only enter the hostname, such as apono-agentic-gateway.<your-domain>. Do not include the protocol (https://) or the /mcp path.

1. Click Update Connector. The connector is updated. The Connectors tab opens.

Validate the gateway endpoint

Run the following checks from a machine that can reach the gateway endpoint, which is typically internal.

Follow these steps:

1. Confirm that the ${CONNECTOR_ID}-proxy service exists.

kubectl get svc -n ${NAMESPACE} ${CONNECTOR_ID}-proxy

1. Confirm that the ingress or load balancer is provisioned and routes traffic to ${CONNECTOR_ID}-proxy on port 10020.

kubectl get ingress -n ${NAMESPACE}

1. Confirm that ${HOSTNAME} resolves to the ingress or load balancer.

nslookup ${HOSTNAME}

1. Verify the HTTPS endpoint.

OAuth protected-resource metadata

Request the OAuth protected-resource metadata. A 200 response with a JSON body confirms that DNS, TLS termination, load-balancer routing, the Kubernetes service, and the connector proxy are connected.

curl -sS https://${HOSTNAME}/.well-known/oauth-protected-resource

MCP endpoint

Request the MCP endpoint without credentials. A 401 response confirms that the request reached the gateway and requires authentication.

A timeout, connection refusal, or TLS error indicates a networking or certificate problem.

curl -i https://${HOSTNAME}/mcp

Connect an AI client

Configure a supported AI client to connect to https://<HOSTNAME>/mcp.

Apono will provide client-specific configuration and authentication instructions to Remote Agentic Gateway private-beta participants.

---

Troubleshoot the Remote Agentic Gateway

The ${CONNECTOR_ID}-proxy service does not appear.

Follow these steps:

1. Confirm that proxyService.enabled is set to true in the connector’s values.yaml file.

2. Install the new connector or upgrade the existing connector again.

3. Confirm that the proxy service appears.

kubectl get svc -n ${NAMESPACE} ${CONNECTOR_ID}-proxy

The load balancer marks the target as unhealthy.

Configure the load-balancer health check to:

• Use / as the health-check path.

• Accept status codes from 200-499.

The unauthenticated / path can return 401 or 404 when the gateway is healthy.

The curl request hangs or the connection is refused.

Confirm that the ingress or load balancer:

• Routes traffic to the ${CONNECTOR_ID}-proxy service.

• Forwards traffic to port 10020.

Also confirm that the applicable firewall rules, security groups, routing, and network policies allow the connection.

The curl request returns a TLS error.

Confirm that the TLS certificate:

• Matches <HOSTNAME>.

• Is presented by the ingress or load balancer.

• Is trusted by the AI client runtime.

Agents intermittently receive an unknown session error.

Confirm that the gateway connector runs as a single replica. If the connector is running multiple replicas, scale it back to one.

The gateway is reachable, but all agent actions are denied

Confirm with an Apono admin that the Apono account setup is complete:

• MCP features are enabled.

• The applicable integration is connected.

• An agentic access flow exists with Restrict to agentic access enabled.

• The corresponding Apono Managed MCP is enabled.