Trust

Security at Proxy

Proxy reads your codebase and sits in your meetings. That is a lot of trust, so here is exactly how it works — what we ask for, what we keep, and what we can and cannot do.

Last updated October 20, 2026

The short version

  • Least-privilege access. Scoped to the repos and channels you pick, revocable in one click.
  • Every token is held by Nango, never by us. Your work's sandbox gets only short-lived, scoped credentials from Nango; our own infrastructure keys never enter a sandbox.
  • Proxy sends only through one outbound path, which redacts, budgets and records every message, and an action that changes something outside the conversation — a pull request, an issue — waits for the yes of the person it acts for.
  • We don't train on your data. Proxy does not train any model on your code, meetings or messages, and our model providers are not permitted to under the terms we use them on.
  • Every company is isolated — separate storage, separate compute, enforced by the database itself.
  • We keep as little as possible, and delete everything on request.

What we ask for — and what we deliberately don't

GitHub. A GitHub App (not a personal token), installed on your org and scoped to the repositories you select. It requests thirteen permissions and no others: repository contents, pull requests, issues and Checks, which it writes; and read-only repository metadata, Actions, commit statuses, repository secrets, repository variables, organization members, and the security alerts GitHub raises (Dependabot vulnerability alerts, code scanning and secret scanning alerts), so Proxy can follow up on them. The read-only app is the same list with contents and Checks as read.

It does not request organization administration, environments, or workflow definitions. Proxy cannot alter your org settings, and it cannot change your CI: a change that touches a workflow file reaches a person as a patch to apply themselves.

It does ask for read access to repository secrets, and we would rather be exact about what that can and cannot do. GitHub never returns a secret's value to any app, ours included — the permission returns names and metadata only, so Proxy can see that a secret called STRIPE_KEY exists and never what it holds. Repository variables are the different case, and we say so plainly: GitHub treats those as ordinary configuration rather than secrets, and their values are readable. We ask for both so Proxy can tell you that a build failed for want of a value, and which one.

Slack. Proxy reads messages and the files shared in the channels and direct messages it has been added to, lists channels, looks people up — including their email, so it can reach the right person — and asks to search public channels, which Slack permits only once an app is listed on its Marketplace. It posts, reacts, uploads files, and answers in the side panel. It reads the reactions on its own messages, so a thumbs-up or thumbs-down on a reply counts as feedback on it. It asks for no admin scope and it cannot read a private channel it is not in. When an admin starts Proxy, it joins the public channels an admin chooses, once; it never adds itself to a channel after that, and someone in a private channel adds it there.

One drift we would rather state than have you find. The installed Slack app still carries chat:write.public, a scope that lets it post in a public channel it was not added to. Our app definition in source no longer asks for it, and removing it from the installed app is outstanding. Until that is done, "only where it was invited" is true of what Proxy reads, not of where it can post.

Only where it has been added. Proxy reads only the channels it has been added to. It does not read a person's own private channels or direct messages, and nobody is asked to connect their own account.

Google. Sign-in, and read-only calendar events: which meetings exist, who is in them, and their links. Read-only on your directory too — people, and the groups they are in, so Proxy knows who is who and who is an admin, and your Workspace's list of domains, so every domain of one company resolves to that one company — and the admin audit feed, which is how we are told when a group's membership changes. No mail, no files, no write access anywhere.

Any grant can be revoked by an admin at any time, and access stops immediately.

Where your code runs, and the credential boundary

Work happens in an isolated sandbox created for that meeting or that piece of work and destroyed when it is done. The work's credentials reach the sandbox; our infrastructure's credentials never do. A sandbox gets only short-lived credentials, minted by Nango for that company and scoped to what the work needs, and model and voice services reach it through our own forwarder or a short-lived token — never our keys.

Anything Proxy says or does outside the sandbox goes through one outbound path on our servers: it sends as Proxy (never as you), redacts credentials, holds each person to a daily budget of unprompted messages, and records every send. Pull requests and issues are opened only after the yes of the person they are for, and Proxy pushes only to its own proxy/ branches — it never merges.

Isolation between customers

Every record carries its company's identity, and the database enforces that boundary itself with row-level security — so even a bug in application code cannot return another company's row. Compute is per-meeting and never shared. Storage is separated per company.

We test this continuously, including under concurrency: a recent verification ran a hundred companies signing up simultaneously and confirmed complete isolation.

Where your access tokens live: Nango

Every token you give Proxy is held by Nango, a dedicated credential store, and not by us. That is your company's GitHub installation, your Slack install, Linear, each person's own connection to those tools and to Zoom, and any test keys you add. Nango encrypts what it holds with AES-256-GCM, is SOC 2 Type II, and comes with its own data-processing agreement. It is named as a sub-processor in ours.

No access token is ever in our database, our logs or our error reports, and nobody at Proxy reads one. When work needs a token, Nango is asked for a fresh one for that company and that person, and refresh tokens never leave it. Our own keys to Nango are split by job, so the part of the product that opens a connection cannot read tokens.

Google is the one exception, and it is the safer one: our access to your calendars and directory is signed for by Google's own IAM, so no key for it exists anywhere.

Encryption and secrets

  • In transit: TLS everywhere.
  • At rest: managed encryption for all storage, plus a second layer — per-company credentials are individually encrypted with AES-256-GCM.
  • Secrets live in a managed secret store, never in source control, never in logs.

AI, and what happens to your data

Proxy runs on Anthropic's Claude models, and uses Google's Gemini models for live conversation in meetings, research and images. We don't train on your data: neither Proxy nor these providers train a model on your code or conversations, under the commercial terms we use them on. What a provider may keep for a limited time for abuse prevention is governed by those terms, which we will share on request.

Proxy is built to be grounded: it cites the real file and line behind an answer, or it says it does not know. Meeting content is treated as untrusted input — instructions embedded in a transcript or a document cannot make Proxy act on them.

What we retain, and deletion

We keep what the product needs and little else: your notes and work product, the code understanding Proxy builds, and operational logs. Meeting audio is consumed live and not retained by us, and Recall, which carries it, is set to keep nothing.

A meeting's transcript, notes, action items and published artifacts are deleted for real once the meeting is older than your company's retention period — 30 days unless you set it between 7 and 90 — by a job that runs every night. Records of usage and an audit trail of who did what (never what was said) stay.

Deletion works. On request we purge your company's data — records, stored artifacts, and credentials — and revoke every token. You can also disconnect any integration yourself at any time.

Sub-processors

We use a small set of vendors, each for one job: Google Cloud (hosting, databases and storage, United States), Anthropic (the Claude models) and Google (Gemini: live conversation in meetings, research, images and a backup voice), Nango (the credential store — see below), E2B (isolated sandboxes), and for meetings Recall (joining and carrying audio, set to keep nothing), AssemblyAI through Recall (transcription) and Cartesia (Proxy's spoken voice). Also: Browser Use (browsers Proxy opens for a task), Exa (web search and reading public pages), Resend (email), Stripe (payments) and Sentry (error monitoring). A current list with details is available on request and is named in our DPA.

Where we are honest about our stage

Proxy is an early-stage company and we would rather tell you exactly where we stand than imply more.

  • We are not SOC 2 certified yet. The controls described here are real and in place; the formal audit is not something we have completed.
  • We have not commissioned a third-party penetration test yet. We run automated security scanning on our code, dependencies, and cloud configuration.
  • Meeting features are rolling out; where a capability above applies to a feature you have not been given yet, it applies from the moment you are.

If your security review needs something specific — a DPA, a completed questionnaire, or a conversation with an engineer — just ask. We will answer directly.

Reporting a vulnerability

Email security@useproxy.co. We will acknowledge quickly, keep you updated, and we will not take legal action against good-faith research.

Related: Privacy Policy · Terms of Service