proofboundJoin the waitlist

In development. Early access starts with GitHub Actions.

Known outbound IPs for workloads you can name.

Proofbound is an identity-aware outbound gateway. Your CI jobs and services reach IP-allowlisted APIs, databases, and SFTP servers through a predictable set of egress IPs, authenticated by workload identity, constrained by destination policy, and recorded per connection.

One email when early access opens. No newsletter.

Allowed by policyRefused at the gatewayIllustrative example

The allowlist knows an address. It doesn't know a workload.

Partner APIs, financial services, databases, and SFTP servers commonly accept connections only from known public IPs. That model predates ephemeral runners and shared egress, and it shows.

CI runners move

GitHub-hosted Actions runners draw from large, changing IP ranges. You can't hand a partner a list that stays true.

NAT hides the caller

Kubernetes workloads often share a NAT gateway. Every pod looks the same from the outside, whichever one opened the socket.

Workarounds pile up

Self-managed static-IP runners, shared proxy passwords, one-off firewall rules, a bastion someone set up in 2021.

An IP is not an identity

A connection from an approved address doesn't tell you which workload initiated it, or whether it should have.

Identity in, known IP out.

Proofbound sits on the outbound path as a forwarding proxy. It decides whether a connection may leave, and from where. Not what's inside it.

  1. 1

    The workload presents its identity

    A GitHub Actions job requests its OIDC token; a Kubernetes pod uses its service-account token. Proofbound exchanges it for a short-lived credential, so there's no long-lived proxy password in your secrets.

  2. 2

    The gateway checks policy

    The requested host and port are checked against destination policies. If no rule allows this workload to reach this destination, the connection is refused.

  3. 3

    The connection leaves from a known IP

    Permitted connections are forwarded from a stable egress address, the one your partner already allowlisted. TLS and SSH stay end-to-end between your workload and the partner.

  4. 4

    Metadata is recorded

    Workload, destination, decision, timing, and byte counts are logged per connection. Application payloads are never decrypted or stored.

.github/workflows/settlements.ymlIllustrative, API not final
permissions:
  id-token: write   # lets the job request a GitHub OIDC token
  contents: read

jobs:
  sync:
    runs-on: ubuntu-latest
    steps:
      - uses: proofbound/connect@v0
        with:
          gateway: acme

      # outbound traffic now leaves via 203.0.113.24
      - run: ./scripts/pull-settlements.sh
policies/ci-to-partner-bank.yamlIllustrative
default: deny

allow:
  - from: github:acme/payments-sync@refs/heads/main
    to:   api.partner-bank.example:443

  - from: k8s:prod/settlement-worker
    to:   sftp.clearing.example:22

Four building blocks, nothing more.

Known outbound IPs

Give partners a small, predictable set of public addresses to allowlist instead of a cloud provider's published ranges.

203.0.113.24, 203.0.113.25

Workload identity

Connections authenticate with short-lived credentials derived from GitHub Actions OIDC or Kubernetes workload identity, not shared proxy passwords.

github:acme/payments-sync@refs/heads/main

Destination policies

Declare which workloads may reach which hosts and ports. Everything else is denied, rather than handing CI unrestricted internet egress.

allow api.partner-bank.example:443

Connection visibility

See which workload connected where, when, and whether it was permitted. Metadata only, with no application payload inspection.

14:02:11Z allow 1.2 MB

Every connection has a name attached.

When a partner asks who called their API at 14:02, the answer is a repository and branch, or a namespace and service account. Not “something behind the NAT.”

Connections in the last 10 minutesSample data
  • github:acme/payments-sync@mainallow

    api.partner-bank.example:443

    14:02:11Zvia 203.0.113.241.2 MB

  • k8s:prod/settlement-workerallow

    sftp.clearing.example:22

    14:02:14Zvia 203.0.113.2438.4 MB

  • github:acme/web@pull/812deny

    api.partner-bank.example:443

    14:05:40Z

  • k8s:staging/report-gendeny

    db.vendor.example:5432

    14:06:02Z

  • github:acme/payments-sync@mainallow

    api.partner-bank.example:443

    14:09:27Zvia 203.0.113.25840 KB

Recorded: workload identity, destination host and port, decision, egress IP, timestamps, byte counts.

Never recorded: request bodies, headers, file contents, or anything inside the TLS or SSH session.

Starting where it hurts most: CI.

First in early access

GitHub Actions to IP-allowlisted APIs

Keep using GitHub-hosted runners. Jobs that need to reach an allowlisted service route through Proofbound; everything else is unchanged.

  • No self-hosted runner fleet just to own a static IP.
  • No proxy password stored as a repository secret.
  • Scoped by repository, branch, and environment using claims in the OIDC token.
  • Pull requests from forks are refused unless a policy says otherwise.

Kubernetes to partner APIs

Predictable egress for selected workloads, with policies per namespace and service account instead of per cluster NAT.

Applications to SFTP partners

Controlled outbound SSH and SFTP for file exchange, with the session forwarded end-to-end and the connection logged.

Banking and payment partners

Partner allowlists plus audit questions: which system connected, under which policy, and when. A more demanding case we're designing toward.

Deliberately narrow.

Infrastructure is easier to trust when it's clear about what it doesn't do.

Proofbound is

  • An outbound proxy and gateway with workload authentication
  • A stable set of egress IPs your partners allowlist
  • Default-deny destination policies by host and port
  • A record of connection metadata

Proofbound is not

  • A VPN or a mesh between your networks
  • A replacement for your partner's firewall: they still allowlist the IPs
  • A TLS-intercepting proxy: HTTPS and SSH are never decrypted
  • A general-purpose zero-trust platform

Managed, or in your own cloud.

Both are part of the product direction. Neither is generally available yet; the managed option comes first.

Proofbound Cloud

Building now

Managed outbound infrastructure. We run the gateway and provide dedicated egress IPs for your organization to hand to partners.

  • Dedicated egress IPs
  • Managed gateway and policy engine
  • First target for early access

Proofbound Private

Planned

Run the gateway in your own cloud account, behind your own NAT gateways and static IPs, with the same identity and policy model.

  • Your network, your IPs
  • The gateway runs inside your environment
  • For stricter residency or audit needs

Questions engineers ask first.

Can I use Proofbound today?
Not yet. Proofbound is in development. Join the waitlist and we'll contact you when early access opens, starting with GitHub Actions on Proofbound Cloud.
Does my partner still need to allowlist anything?
Yes. Your partner allowlists Proofbound's egress IPs for your organization (or your own IPs with Proofbound Private). Proofbound doesn't bypass or replace their firewall.
Do you decrypt HTTPS or SSH traffic?
No. The gateway forwards connections and records metadata about them. TLS and SSH sessions stay end-to-end between your workload and the destination.
How is this different from a static-IP NAT gateway?
A NAT gateway gives you a stable address, but every workload behind it looks identical and nothing restricts where they go. Proofbound adds workload authentication, per-destination policy, and a per-connection record on top of the stable address.
Which identity sources will be supported?
GitHub Actions OIDC first, then Kubernetes workload identity (projected service-account tokens). Credentials are short-lived and exchanged at connection time, with no long-lived proxy passwords.
What protocols?
TCP connections to specific hosts and ports. HTTPS APIs, databases, and SSH/SFTP are the initial focus. Policies match on destination host and port, for example api.partner-bank.example:443.

We're building Proofbound now.

If you're wrangling allowlists for CI or Kubernetes today, we'd like to hear how, and give you early access when it's ready. Tell us what you'd connect first and we'll prioritize accordingly.