Too much reachability
A contractor needs one database or service, but receives a route into a broader network segment.
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.
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.
A contractor needs one database or service, but receives a route into a broader network segment.
Static SSH keys, database passwords and shared service credentials are hard to scope, rotate and attribute.
SSH, databases, Kubernetes, web tools and AI services often end up with separate access rules and audit trails.
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.
User signs in through the configured OIDC provider. Workloads can use their own short-lived identity.
Authority evaluates the actor, action, resource and context using Cedar policy.
On allow, GDSGate issues a short-lived access artifact scoped to the requested path.
Connector maintains an outbound tunnel and reaches the backend from inside the protected zone.
Central IT accesses servers, databases and internal tools across offices, warehouses and production sites without opening inbound access to each site.
Give a service engineer access to exactly the required resource, optionally with JIT approval and a short lifetime instead of a broad VPN account.
Use native ssh, psql, kubectl and TCP tooling while central policy decides which environments and resources each identity can reach.
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.
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.
Operates with delegated authority already narrowed by access policy.
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.
Runs continuously under an identity of its own. Holds no credentials.
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.
Each agent runs in an isolated environment with filesystem, namespace, system-call and resource limits. The strict profile is the default.
The agent stores no credentials. It sees only local addresses for the resources it may use, and every request is decided at the gateway.
While the agent runs, the host renews its access. When access expires, the agent is frozen or stopped.
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.
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.
The bot runs next to the infrastructure, reads state and performs a limited set of actions in Kubernetes. Policy separates reading from changing.
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.
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 establishes identity; Cedar evaluates access against users, groups, resource attributes and request context.
Allowed requests receive short-lived certificates or session credentials instead of relying on a permanent shared secret.
Kubernetes requests, MCP tool calls, model calls, restricted database statements and web routes can be authorized inside a session.
Policies can require one or more approvals before temporary access becomes available.
Authorization and session events are hash-chained; operators can inspect and terminate live sessions.
Deploy the control plane and Connectors in your own infrastructure. Production deployments can use separate roles and PostgreSQL state.
Protected resources and Connectors are not billed separately. Plans scale primarily with the number of people who receive access through GDSGate.
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.
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.