Skip to content

Connections#

An agent with no access to your systems is a chatbot. Connections are how an agent reaches Kubernetes, AWS, your APIs, and your internal tools without ever holding the credentials that make it possible.

Everything on this page shares one property: the agent asks, the platform decides, the platform injects the secret, and the call is recorded.

Four mechanisms#

  • Kubernetes

    Register clusters and let agents run kubectl against them, including clusters behind a firewall via a reverse tunnel.

  • AWS

    Assume-role access to an account. The agent signs with a fake key; the platform re-signs with real STS credentials.

  • MCP connectors

    Register upstream MCP servers. Their tools are re-exposed under policy, tool by tool.

  • HTTP APIs

    Turn an OpenAPI document into governed tools, or allow a domain outright through the egress proxy.

Underneath all four is the same policy-controlled proxy: every outbound connection from a sandbox terminates there and is matched against the effective policy before anything leaves.

The pattern#

graph LR
    agent[Agent] -->|placeholder| proxy[Egress proxy]
    proxy -->|policy check| policy[(Effective policy)]
    proxy -->|real secret| upstream[Upstream system]
    proxy --> audit[(Audit trail)]
  1. The agent makes an ordinary request with a placeholder credential, or none at all.
  2. The proxy matches the destination — domain, HTTP method, URL path — against the effective policy.
  3. Allowed requests get the real credential substituted at the boundary.
  4. The upstream sees a normal, authenticated request.
  5. The event is written to the audit trail, allowed or denied.

The agent never learns the secret, and there is no code path where it could.

Where each lives#

Resource Scope Created with
Cluster Project nexusctl cluster create
AWS connection Project nexusctl aws-connection create
Connector (MCP or HTTP) Project nexusctl connector create
Credential Project nexusctl credential create
Domain rules Policy nexusctl policy create

Connections belong to a project. An agent in one project cannot see another project's clusters, accounts, or connectors — that is what makes a project the blast radius.

Registering a connection makes it available. A policy still has to grant it before any agent can use it.

What agents get in the shell sandbox#

The platform's shell sandbox ships with aws, kubectl, gh, and webfetch already wired to the project's connections. An agent runs kubectl get pods with no kubeconfig and aws s3 ls with no access key — the credentials are attached on the way out.

Every registered connector also appears as a CLI inside the sandbox, so an agent can discover what it has rather than being told. See Agent tools.

  • Credentials — storing secrets and defining how they are injected
  • Models — the one connection agents always need
  • Policies — granting what a connection makes possible
  • Audit trail — what was reached, by whom

Connecting a system that is not on this page — a database, a queue, an internal service with an unusual auth scheme — is normal. Talk to us.