Security
Trust it because you can check it.
Your crew works on the station you pick, with your keys and in your name. Every job is sealed off, and wiped when it's done.
Your station or ours
You choose where the work happens.
Run your crew on your own station, or let us run one for you on Moondeck Cloud. Here's what that means for your code.
| What | Your own station | Moondeck Cloud |
|---|---|---|
| Where the crew works | Your own machine, or your own AWS account. Moondeck has no access to that account. | A machine we run, made for that one job. |
| Your code | Stays on your station. Moondeck's cloud holds no copy. | Lives on the job's own machine while it runs. |
| Who runs the work | Your station does. Moondeck's cloud coordinates; the work runs on your machine. | We do, on Moondeck's own machines. |
| When the job ends | Its sandbox and its copy of your code are deleted. | The whole machine is wiped. |
Either way, a job only gets the keys it needs, and only while it runs.
Sealed jobs
Every job starts clean.
Every job ends wiped.
A sandbox of its own
Every job gets its own container, its own copy of your code and its own branch. The agents' tools run inside it, not on your station.
Only what you open
The ports you declare for a preview are the only ones that reach you, through Moondeck's preview link. Nothing else is forwarded.
Wiped when it's done
When the job ends, its sandbox and working copy are deleted. On Moondeck Cloud, the whole machine goes with them.
The cloud's own keys, out of reach
Every major cloud hands a machine its credentials at 169.254.169.254. On Moondeck Cloud, nothing inside a job can reach that address. Check it yourself, from inside one.
In your name
Done as you.
Never as a bot.
Every job carries the credentials of the person who started it. The work shows up as theirs, so you always know who did what.
What a job carrieswhen you start it
- Your name
- Commits are written with your own git name and email.
- Your SSH key
- Moondeck makes a key just for you. Only its public half goes to GitHub, and your own ~/.ssh is never touched.
- Your GitHub sign-in
- Pull requests open with your own GitHub sign-in, handed to the job that needs it.
- Your AI accounts
- The crew works with the AI accounts you connected. You pay the provider directly.
Private keys
Your agents use your private keys.
They never see them.
Mark a key as private in your repository and the crew works with a stand-in. The real key is added only on its way to the service it belongs to.
1 · Inside the job
Your agent sees a stand-in
STRIPE_SECRET_KEY = stand-in It uses it like the real thing. It can't read the real one, because it isn't there.
2 · Outside the job
Moondeck swaps it
only for api.stripe.com On its way out, the stand-in is replaced with the real key. Only for the service the key belongs to.
3 · At the service
Stripe gets the real key
the real key The answer comes back with the key scrubbed out, so it can't leak into the job that way either.
- You choose the keys
- Mark a key in your repository's
.env.schemawith the service it's for. Everything else, like a database password, still reaches the job as its real value. - It fails closed
- If anything stops the swap from working safely, the job doesn't get the key at all. Only the owner can let a key's real value through.
- Every swap is logged
- Before a key goes out, the station records the job, the key and the service. Never the value.
- Where it stops
- It works for HTTPS services that take the key in a header, as most APIs do. A key used to sign requests, like AWS's, can't be swapped.
Roles and permissions
Decide who can do what, before anything runs.
Roles set what each person can do, which agents and stations they can use, and how much they can spend. The same rules apply to your agents.
Roles add up
A person can hold several roles and gets everything they grant together. A new role never quietly takes access away.
Caps that hold
Limit jobs at once, starts per day and monthly spend. Your plan is always the ceiling: a role shares out what you bought.
Agents and stations
A role can unlock specific agents and stations. One that no role mentions stays open to everyone.
One rulebook
People and agents share one list of permissions, so tasks.start means the same for both.
New workspaces start with two roles, Workspace Admin and Member. Nothing narrows until you narrow it.
Questions.
Found a vulnerability? Email security@moondeck.io.
Do commits and pull requests show up as a bot?
No. Every job runs with the credentials of the person who started it: your git name and email, an SSH key made just for you, and your own GitHub sign-in. Commits and pull requests are yours, not a bot's.
Can my agents read a key I've marked as private?
No. A key your repository marks as private, with the service it belongs to, reaches the job only as a stand-in. Moondeck swaps in the real key outside the job, on HTTPS requests to that service only, and scrubs it from the answer. The agents can use the key there for as long as the job runs, but never read it. If the swap can't be done safely, the job doesn't get the key at all.
Does Moondeck touch ~/.claude or ~/.ssh?
No. Jobs never mount ~/.claude or ~/.ssh. Moondeck makes a separate SSH key for you instead, and each job's credentials go into its own throwaway sandbox.
If I run my station on my own AWS, do you have access to that account?
No. You own the AWS credentials, and Moondeck has no access to your AWS account. On Moondeck Cloud the question doesn't apply: those machines are ours to run.
Can I limit what a teammate, or an agent, can do?
Yes. Roles decide who can start a job, which agents and stations they can use, and caps on jobs at once, starts per day and monthly spend. A person can hold several roles and gets what they grant together; your plan is always the ceiling. Agents follow the same permission list as people.
Do I need a GPU?
No. Moondeck's agents call hosted models over the network: Claude, Codex, Grok, Cursor and more. There's no local inference.
