Security

Where your code goes, what the agent can reach, who at Polaris can see your content and what we haven't done yet.

Polaris runs coding agents on your code. Here’s where your code goes, who can see it, what your agent can reach, and what we haven’t done yet. If anything worries you, email andreas@plrs.sh and the person who built it will answer.

The short version

Each Workspace runs on its own Machine, a separate virtual machine.
Your agent uses the model provider you choose, with your own account. We don’t train models on your code.
Your data is encrypted in transit and at rest, and stored mostly in AWS in Oregon, USA.
We can technically open your content. A rule limits when, not technology. See Who at Polaris can see my code?
We haven’t had an independent audit or penetration test. The gaps we know about are listed below.

Where does my code go?

Polaris itself sends your code to four places:

Your Machine. It clones your repository, and your files, processes and memory live there. Our Machine provider, Sail, runs it and can technically read everything on it.
Your model provider. Your agent sends the files and context it chooses to the provider you connected, using your account.
Our storage in AWS, Oregon. Session transcripts (your prompts, the agent’s replies, command output and diffs), files you upload or share, and temporary copies of a Machine while we move or replace it.
OpenAI, under our account, for Session recaps, dictation and voice. A recap usually includes code. Recaps are on by default; Organization Owners and Admins can turn them off. Our Privacy Policy says what each feature sends and how long OpenAI keeps it.

Your agent can send your code further. Machines have open internet access, so the agent can push to GitHub, call MCP servers and tools you connect, and reach any site. The agent’s own command-line tool may also send usage data to its maker; we don’t turn that off.

Our other providers get account or operational data, not your code. The Subprocessors page says what each one can see.

What can my agent reach?

Your Machine. Each Workspace runs on its own virtual machine. In October 2026 we reviewed our default provider’s isolation ourselves and probed it from inside a Machine. We found no way to reach another Machine or the provider’s metadata service. That review covered Sail only, and it wasn’t independent.
Root. Inside your Machine, the agent has root. Treat the Machine like a laptop you’ve lent to the agent: it can read everything there, including credentials you’ve put on it.
The internet. Outbound traffic isn’t filtered. That’s how agents install packages and call APIs.
Your accounts. The agent can act through the accounts you connect, such as GitHub, while their access is valid.

Prompt injection

Agents read text you didn’t write: issues, web pages, package READMEs, tool output. That text can tell the agent to do something you didn’t ask for, such as sending a file somewhere. We don’t filter Machine traffic, so we can’t stop it once the agent acts.

What helps:

Broker the keys that matter (below).
Limit the Polaris GitHub App to the repositories the agent needs.
Review changes before you merge them.

How are my secrets handled?

Brokered Secrets stay off the Machine.
- The Machine gets a stand-in. When a request leaves the Machine, our broker swaps in the real key.
- Only the broker can decrypt these keys; our main API can’t.
- The broker sees each request as it passes through, and logs which key was used and when, never the request itself.
- If a service echoes your key back in its response, the agent will see it.
Other credentials are on the Machine. Ordinary project Secrets, agent sign-ins and GitHub access are placed on the Machine so your tools work, and the agent can read them there. Broker the keys you care about most.
Stored credentials are sealed.
- Agent sign-ins, API keys and Secrets are sealed with AWS KMS envelope encryption, bound to your Organization.
- Your GitHub sign-in token is encrypted with a separate application key.
- Secret values are write-only: you can replace them but not read them back.
- Config values that aren’t marked secret are stored as plain text.
Masking. Polaris masks Secret values in output, except very short ones (under 8 characters).
GitHub App tokens are short-lived. We create one for each operation, with only the permissions it needs. The token on your Machine can still act on the repositories you’ve connected while it’s valid.

Who at Polaris can see my code?

We can technically open your content (code, transcripts and Machine files) through our production database and our Machine provider. We do it only for the reasons in our Terms: support, keeping Polaris running, security, legal obligations, and improving Polaris unless you’ve asked us not to. Each time, we write down who, when and why. Nothing technical stops us yet; that’s the rule and the record.

Inside your Organization, Owners and Admins can read every Session, including ones that aren’t shared with them. Other members see only Sessions shared with them.

Do you train on my code?

No, and we don’t sell your code or Sessions. Under its API terms, OpenAI doesn’t train on what our features send. Your model provider’s own terms cover what your agent sends it.

Encryption

In transit. Traffic between your browser and Polaris uses TLS 1.2 or newer. Our database connections verify the server’s certificate.
At rest. Our database is encrypted with AWS KMS. File storage is encrypted, and public access to it is blocked.

You sign in with GitHub. Polaris has no passwords of its own.
During the beta, access is by invitation.
Organizations have Owner, Admin and Member roles. You can share a Session with a person or the whole Organization, to watch or to drive.
Previews run on a separate domain (plrs.site). They’re open only to your Organization unless you create a public link. A public link works for anyone who has it until it expires or you revoke it, even if you leave the Organization.
When someone leaves an Organization, their access to its Sessions and private Previews ends within minutes.

How we build and ship

Every change goes through automated tests and an AI code review in a merge queue. There’s no second human reviewer yet.
Urgent fixes can ship first and get the full checks straight after.
Deploys use short-lived credentials (GitHub OIDC), not stored keys.
Production alerts page the founder directly.

No independent audit, SOC 2 or penetration test. Ask us what evidence we can share.
Staff access is limited by a rule and a record, not by technology. Broker keys you wouldn’t want anyone to see.
Agents run as root with open internet access, and only brokered Secrets stay off the Machine. Assume the agent can read anything there, and that anything it reads can steer it.
Account deletion and full data export are by email, not self-serve.
No Organization-wide audit log of what your members do.
No two-factor sign-in of our own. Turn it on for your GitHub account.
Our database runs in one availability zone, with 14 days of backups. An outage means downtime and could lose the last few minutes of changes, so push code to GitHub as you go.
No EU data residency. Our main systems are in the US.

Reporting a vulnerability

Email andreas@plrs.sh. We’ll reply within 3 business days, keep you updated, and credit you if you’d like.

Please:

give us a reasonable chance to fix the issue before you disclose it;
don’t access other customers’ data;
don’t disrupt the service.

If you follow these rules, we won’t take legal action against you for your research.