Self-hosted · client pilots

Access infrastructure. Not the whole network.

GDSGate gives employees, contractors and workloads controlled access to specific resources — SSH hosts, databases, Kubernetes, internal web apps, MCP and model services — without exposing protected networks to inbound connections.

OIDC identity · Cedar policy · short-lived access · tamper-evident audit
access.gdsgate
$ gdsgate login
identity  alex@example.com
groups   platform, oncall

$ gdsgate ssh prod-api-03
ALLOW  resource=SshHost::prod-api-03
ttl      5m  ·  session audited

$ gdsgate db proxy prod-orders
DENY   policy: prod-db requires approval
SSHPostgreSQLMySQLKubernetesInternal WebMCPModel servicesRaw TCP
WHY GDSGATE

Administrative access usually becomes network access.

VPNs and ad-hoc tunnels solve reachability. They do not automatically answer who may reach which resource, for how long, under which policy, and with what audit evidence.

01

Too much reachability

A contractor needs one database or service, but receives a route into a broader network segment.

02

Long-lived credentials

Static SSH keys, database passwords and shared service credentials are hard to scope, rotate and attribute.

03

Fragmented controls

SSH, databases, Kubernetes, web tools and AI services often end up with separate access rules and audit trails.

HOW IT WORKS

A resource gateway in front of protected systems.

The protected side dials out. Users request a named resource. Policy is evaluated before the session, and selected protocols can be authorized again inside the session.

01

Identity

User signs in through the configured OIDC provider. Workloads can use their own short-lived identity.

02

Policy

Authority evaluates the actor, action, resource and context using Cedar policy.

03

Short-lived access

On allow, GDSGate issues a short-lived access artifact scoped to the requested path.

04

Outbound Connector

Connector maintains an outbound tunnel and reaches the backend from inside the protected zone.

User / workloadssh · psql · kubectl · browser
OIDC + request
Proxyclient-facing data path
outbound reverse tunnel
Connectorprotected side · outbound
Agent hostlong-lived agents under their own identities · endpoints published in the catalog
Authorityidentity · Cedar policy · PKI · audit
Protected resourcesSSH · DB · Kubernetes · Web · MCP · model · TCP
GDSGate controls traffic that goes through the gateway. Other routes or credentials that allow direct access to the host must be restricted separately.
USE CASES

Built for distributed infrastructure and privileged access.

Branches & production sites

Central IT accesses servers, databases and internal tools across offices, warehouses and production sites without opening inbound access to each site.

Contractors & vendors

Give a service engineer access to exactly the required resource, optionally with JIT approval and a short lifetime instead of a broad VPN account.

Platform & DevOps teams

Use native ssh, psql, kubectl and TCP tooling while central policy decides which environments and resources each identity can reach.

CI, services & AI agents

Services, CI and automation receive their own short-lived identity and are evaluated against the same access policy as users. AI agents run inside a constrained sandbox and receive only the resources and actions explicitly delegated to them. Agents that run continuously live on a separate agent host under an identity of their own.

AI AGENTS

Agents run in a sandbox.

An AI agent can act on a user’s behalf without inheriting the user’s full authority. The sandbox exposes only the resources and actions explicitly delegated to the agent. Delegation can be revoked at any time.

UserDelegates a specific task to the agent.
→
Agent sandbox
AI agent

Operates with delegated authority already narrowed by access policy.

allowed resourcesallowed actionsno full user authority
→
Allowed server
Allowed DB or API
Other infrastructure
The same model is useful beyond AI: automation and other delegates can receive a bounded subset of authority without exposing the user’s complete access.

Agent host

A dedicated agent host runs long-lived agents. It starts programs an operator declares centrally. Such an agent has an identity, rights and an audit trail of its own; it is not an extension of an employee’s access.

OperatorDeclares the agent, its rights and its endpoints.
UserThe resident client keeps a local address for every catalog resource — the agent’s endpoints among them.
→
Agent host
Long-lived agent

Runs continuously under an identity of its own. Holds no credentials.

host isolationaccess renewalown groups
Published endpoints
consoleweb pagemodel APIMCP tools
→
Allowed server
Allowed model or database
Other infrastructure
The agent reaches resources through the gateway: every call is checked against policy and lands in the audit under the agent’s own name. A user connects to an endpoint the same way as to any other catalog resource.
01

An identity of its own

An operator declares the agent centrally. It gets its own principal and groups, and the audit names the agent, not the person who started it.

02

Host isolation

Each agent runs in an isolated environment with filesystem, namespace, system-call and resource limits. The strict profile is the default.

03

No credentials to hold

The agent stores no credentials. It sees only local addresses for the resources it may use, and every request is decided at the gateway.

04

Automatic access renewal

While the agent runs, the host renews its access. When access expires, the agent is frozen or stopped.

An agent’s endpoints — a console, a web page, a model API, MCP tools or a TCP stream — are published in the catalog as ordinary resources. A web page can receive a signed statement of the visitor: the call then goes through only if both the agent and the visitor are allowed, and the audit names the visitor.
WHERE IT IS USED

Internal assistant

The assistant runs continuously and answers on an internal web page. It reaches the model through the gateway, and the page can receive a signed statement of the visitor: the call goes through only if both the assistant and the employee are allowed.

Data assistant

The agent gets narrow access to one database or cluster: it answers questions and prepares extracts without administrator rights. Writes can be denied by policy.

Operations bot

The bot runs next to the infrastructure, reads state and performs a limited set of actions in Kubernetes. Policy separates reading from changing.

Site automation

An agent runs inside a branch or a plant and reaches local systems from within. No inbound ports are needed: the agent host dials out itself.

SECURITY MODEL

Central policy without turning the gateway into a flat network tunnel.

GDSGate separates identity, authorization and network reachability. The Connector never needs an inbound listener in the protected zone, and the Authority owns trust, policy and audit decisions.

OIDC + Cedar

OIDC establishes identity; Cedar evaluates access against users, groups, resource attributes and request context.

Short-lived credentials

Allowed requests receive short-lived certificates or session credentials instead of relying on a permanent shared secret.

Fine-grained authorization

Kubernetes requests, MCP tool calls, model calls, restricted database statements and web routes can be authorized inside a session.

JIT access

Policies can require one or more approvals before temporary access becomes available.

Audit & session control

Authorization and session events are hash-chained; operators can inspect and terminate live sessions.

Self-hosted

Deploy the control plane and Connectors in your own infrastructure. Production deployments can use separate roles and PostgreSQL state.

Docs →
VPN VS RESOURCE ACCESS

Use a VPN when you need a network. Use GDSGate when you need a governed resource path.

Typical VPN access
GDSGate access
Reachability
Network / subnet
Named catalog resource
Protected-site ingress
Usually required somewhere in the path
Connector dials out
Authorization unit
Often network membership
Identity + action + resource + context
Credentials
Frequently long-lived or backend-specific
Short-lived gateway access
Audit
Connection-oriented, varies by backend
Central authorization + session evidence
Native tools
Yes
Yes — ssh, psql, kubectl, TCP clients
PRICING

Predictable annual pricing. No fee per server or Connector.

Protected resources and Connectors are not billed separately. Plans scale primarily with the number of people who receive access through GDSGate.

Team

$4,500/ year
Up to 10 users
Up to 500 protected resources
Small infrastructure teams

Business+

$11,500/ year
Up to 50 users
Up to 5,000 protected resources
Larger IT / operations teams

Enterprise

$19,000/ year
Up to 100 users
Up to 10,000 protected resources
Enterprise deployments

Custom

Custom quote
More than 100 users
Protected resources — by agreement
Discuss terms →
Self-serve technical evaluation — 30 days, free.
Assisted PoC — a paid engagement; the fee is credited toward the license.
Deployment after the pilot — a separate service.
Advanced support: custom quote.
BUILT BY GDS

Systems engineering behind the product.

GDS has been building production software since 2012. More than 30 projects are running in production across custom software, industrial systems, AI and infrastructure engineering.

About GDS ↗
CLIENT PILOTS

Start with one real access path.

Pick a concrete scenario — a contractor to one database, central IT to a branch server, or a DevOps team to a Kubernetes cluster. We can scope a pilot around that path and validate both allowed and denied access.

Tell us what you need to reach and from where. We reply on the same business day with a scoped pilot plan.

Or email us directly at hello@gds.dev.