Docs / Operate

Security and access

This page covers who can do what in a workspace, what an agent can reach, and how Dawnrose keeps workspaces apart.

Workspace roles

Invite people on the People page: enter an email, pick a role and click Invite. People who already have an account are added at once; others get an email with an invite link, and the link is also copied for you to send yourself. Pending invites are listed with the members until they are accepted; revoke one with the × next to it. Change a role with the menu next to each member.

Only owners can make someone an owner or change an owner’s role. A workspace always keeps at least one owner.

An invite is accepted automatically only when the person signs in with an identity provider that verified the email address. People who sign up with an email and password use the invite link.

Inviting someone to one project

To share a single project, open its Settings → Members, enter an email under Invite member, pick Can edit or Can view and click Invite. Someone outside the workspace joins it as a guest and sees only that project. A workspace member you invite keeps their workspace role, and the project permission can raise it for that project, never lower it. Click Copy invite link to send the link yourself. Removing a guest from their last project removes them from the workspace too.

Agents can’t invite people or change anyone’s access. Members, roles and project access are managed only in the dashboard, signed in. An agent can see who is in a workspace with list_members.

Restricted projects

By default everyone in the workspace can open every project. In a project’s Settings → Members, turn on Limit to project members to limit it to workspace admins and owners, plus the people listed as project members. For those people, the project permission replaces their workspace role in that project.

Tokens

• Agent tokens come from the Connect agent page and are limited to one workspace. Everything done with them is marked as AI.
• API tokens come from Account → Tokens, for the CLI, CI and scripts. They act as you, across your workspaces. Used over MCP, they are still treated as an agent.

A token can do what its owner’s role allows, never more. An agent token cannot create tokens, and a token limited to a workspace can only create tokens for that workspace. Passwords can be changed only from a signed-in browser session, not with a token. Dawnrose stores tokens only as hashes, so they are shown once when created. Revoke tokens on the Connect agent page or under Account → Tokens; see Revoke a token.

Sealed secrets

Seal variables that hold secrets. A sealed value is given to the service at runtime but cannot be read back by anyone: not in the dashboard, the API, the CLI or by agents, and not through the resolved value of another variable that references it. Sealed variables are not copied into new environments or pull request environments. See Sealed variables.

Confirmations for destructive actions

MCP tools that delete or overwrite data take a confirm argument that must be true: delete_project, delete_environment, delete_service, remove_deployment, remove_domain, disable_tcp_proxy, remove_volume, restore_backup and delete_backup. The server refuses these calls without it. Every tool also carries read-only or destructive annotations, so clients that ask before risky calls can do so. Dawnrose’s instructions to the agent say to use destructive tools only when you asked for them.

When a service is deleted, on its own or with its environment or project, its backups are kept for 7 days. In that time the workspace owner can restore one into a new service of the same kind.

In the dashboard, deleting a service, an environment, a project or a volume, and restoring a backup, ask you to type the name (for a volume, its mount path) to confirm. In the CLI, dawn rollback, dawn down, dawn env delete and dawn domain remove ask for confirmation, or need --yes when not run in a terminal.

How workloads are isolated

• Sandboxed replicas. Service replicas and pre-deploy commands run under gVisor (runsc), a user-space kernel between the app and the server; the deploy log says “Sandboxed with gVisor”. All containers run with no-new-privileges, capabilities dropped, and limits on CPU, memory and processes (512, 2,048 or 4,096 per replica, depending on the plan).
• Separate networks. Each environment has its own private network. Containers cannot reach the cloud provider’s metadata service or the servers’ private network.
• Separate builds. Builds run on dedicated build servers that host no tenants and hold no TLS keys. A paying workspace’s builds run on a server only it ever uses, deleted after about 30 idle minutes. Trials share a separate pool that never holds a paying workspace’s build. Because that server is the workspace’s own, a build can take a little longer to start while one is prepared. Each workspace builds in its own rootless builder with its own cache, which is removed when the last build ends. Base images in FROM and COPY --from come from registries, never from other workspaces’ images on the server. A Dockerfile path must stay inside the source, and repositories must be remote, not paths on the server.
• Images. A failed image pull falls back to the server’s cached copy only for public catalog images or images your workspace already ran there.
• Firewall. Containers can’t reach other tenants’ published ports, private networks or port 25, and of the host only its DNS and public edge ports. Each container is limited to 25 MB/s out, 100 new TCP connections a second and 200 new UDP flows a second. Trial networks get 5 MB/s and 20 new TCP connections a second.
• Ports scanners go for. Trial apps can’t connect out to SSH, RDP or SMB ports (22, 23, 135, 139, 445, 3389 and 5900). On paid plans those ports take 2 new connections a second per container.
• Dawnrose itself. An app can’t reach the Dawnrose API or dashboard from inside its container. Call them from outside, or use a deploy hook from CI.
• Memory. What a replica may use is reserved on its server in full, so the kernel never has to pick a neighbour’s database to kill.

What this doesn’t cover

• Builds run outside gVisor, which makes them the weakest layer on the platform. Trials share a build pool with each other, so a kernel exploit from a trial’s build step could reach other trials’ builds on that server, until it’s replaced within 24 hours. It doesn’t reach paying workspaces’ builds, running apps or TLS keys.
• Disk throughput has no per-workspace limit, so a noisy neighbour can slow others on the same server.
• gVisor doesn’t claim to stop hardware side channels between workspaces on one server.
• Limits at the edge don’t help against a volumetric DDoS attack that fills the network link.
• Edge servers hold TLS private keys, and the master encryption key is on the control server rather than in a key management service.

Encryption and data

• Variables, integration tokens, notification channel settings and certificate keys are encrypted at rest with AES-256-GCM.
• Backups are encrypted with a key derived for your workspace, so another workspace’s key cannot decrypt them. See Backups.
• A custom domain routes traffic only after its TXT ownership record checks out, so nobody else can attach a domain you point at Dawnrose.
• Notification webhooks cannot target private or loopback addresses, and they can be signed with a secret.
• The dashboard’s live event stream only carries events from projects you can access, with credentials removed.

Activity log

Every change records who made it: a person, an agent (with the agent’s name, marked as AI) or Dawnrose itself, for example for automatic domains and first-run setup. Read it on the project’s Activity page, under Workspace activity, or with the agent’s get_activity tool. See Activity log.

Reporting a security problem

Write to support@dawnrose.ai. The same address is in /.well-known/security.txt. Please include:

• What you found, and where: a page, an API endpoint, an MCP tool or a CLI command.
• The steps to see it, with the requests or code you used.
• What someone could do with it.

We’ll reply as soon as we can.

If you’re looking for problems, please:

• Test only against accounts, workspaces and services you own.
• Don’t access, change or delete other people’s data. If you reach some by accident, stop and tell us.
• Don’t run denial-of-service tests or send spam.
• Give us a reasonable time to fix the problem before you publish it.