Security notes

1. Credentials are shown once
2. Where to keep them
3. Rotate them
4. Never share them
5. In CI
6. What we can and cannot see
7. If a credential is exposed

Credentials are shown once

• The proxy password is generated when your service is set up and shown once. We keep only a hash of it.
• The WireGuard private key is generated for you and shown once, inside your configuration. We keep only the public key, so a configuration we no longer have cannot be shown again.
• Copy them straight into your secret manager. If you lose them, nothing can recover them. Ask us to rotate, and you get new ones.

Where to keep them

• In a secret manager or in your CI system's secrets. GitHub: repository or environment secrets, with required reviewers on the environment when a job is sensitive.
• Not in a repository, an image, a container layer, a shared shell profile, a wiki page, a chat message or a ticket.
• On disk only in files that only their user can read (chmod 600).
• Not on a command line, where every user on the machine can see them in the process list. Read them from the environment or from standard input. See the curl example.
• Not in logs. Do not run set -x or curl -v where the log is shared. A proxy URL with a password in it is a credential.

Rotate them

Rotating replaces a credential with a new one. The old one stops working when the change is applied, so update your secrets right after you receive the new ones.

• When: when someone who knew a credential leaves, when you suspect exposure, when you lose it, and on a schedule you can keep, so that rotation is routine.
• How: email support@penduses.com with your workspace name and which credential: the proxy login, or the WireGuard key, and on Pro which of the two addresses. Or use your dashboard once it is live.
• What changes: a new proxy password (the username can stay) or a new WireGuard key pair, shown once. The addresses and the allowlist stay as they are.
• Pro: each address has its own credentials. Rotating one does not touch the other, and you can do them one after the other without an outage.

Never share them

• A credential lets whoever holds it send traffic from your address. What leaves your address is attributed to your account, and you are responsible for it under the acceptable use policy.
• Give each person and each system its own access to the secret store, not a copy of the secret.
• We will never ask you for your proxy password or your private key. Anyone who does is not us.
• When you ask for support, send the safe details listed in Troubleshooting, not the credentials.
• Reselling or passing on proxy access to others is not allowed.

In CI

• Store the credentials as secrets. GitHub masks a registered secret in logs, but masking only matches the exact text: an encoded, split or transformed copy is not masked. The GitHub Action registers every form it builds.
• Workflows from forks do not receive secrets, and you should keep it so. Do not use pull_request_target, or another trigger that runs code from a fork with your secrets: that code could use your dedicated address.
• Give the job the least it needs: permissions: contents: read, and an environment with required reviewers for the jobs that reach production destinations.
• Pin third-party actions, including ours, to a full commit SHA in production.
• Set the proxy only on the steps that need the dedicated address.

What we can and cannot see

• Content. We do not decrypt or inspect your traffic. HTTPS and database TLS stay encrypted between your client and the destination.
• Metadata. We keep connection metadata for 30 days: time, destination, port and bytes. We use it to run the service, to apply limits and to handle abuse reports. See the privacy draft.
• The proxy connection is TLS. The proxy port speaks TLS 1.2 or newer and your client checks the node's certificate against its host name, so the proxy login and the host names you ask for are not readable on the way. The traffic inside an HTTPS or TLS connection stays encrypted end to end. We run the proxy behind a TLS terminator on the node and the plain proxy listens on the node's loopback only: there is no clear-text proxy port on the Internet, and no SOCKS5 port, because SOCKS5 sends the password in clear text. A client that does not verify the certificate gives that protection up, so keep verification on. WireGuard encrypts the whole path to our egress node if you prefer a tunnel.
• Attribution. Your address is dedicated to your account. That is what lets a destination allowlist it, and it means traffic from it is tied to you. This service does not hide who you are.

If a credential is exposed

1. Stop using it. Remove it from the place where it leaked (a repository, a log, a chat) and delete or redact what you can.
2. Ask us to rotate it now. Email support@penduses.com with "credential exposure suspected", your workspace name, which address and the time window in UTC. Do not send the credential.
3. Update your secrets with the new credential as soon as you receive it.
4. Look at the other side. Check the destination's logs for connections from your address you do not recognise, and tell us what you find.

To report abuse from one of our addresses, see Report abuse. The pilot is best effort with no SLA.