Security and tenancy

This page describes the boundary that is enforced today, not an aspiration. If you are evaluating PlatformSmith, this is the page to read closely, and the places where the model is coarser than you might assume are called out rather than glossed.

The outer boundary: your organization

An organization is a hard boundary. No request, no query and no agent can reach data belonging to another organization. Every object in the system — workspace, project, environment, runtime, session, secret, artifact — belongs to exactly one organization and is filtered by it on every read and every write. This is the boundary the whole architecture is built around.

Inside your organization: roles at two scopes

Permissions are granted by assigning a role to a person at a scope. There are exactly two scopes:

• Organization scope — the role applies everywhere in the organization.
• Workspace scope — the role applies inside one workspace and nowhere else.

The five roles

Role	Scope	What it can do
owner	organization	Everything, everywhere in the organization. Protected: the last owner cannot be removed.
admin	organization	The same as owner today.
member	organization	Read across the organization; create workspaces; full control of their own personal integrations. Cannot launch runtimes, edit projects, or change settings.
workspace-admin	one workspace	Full control of that workspace and everything in it, including its members and its tokens. Cannot manage organization-level users, integrations or roles.
workspace-editor	one workspace	Work inside the workspace: create and manage projects, runtimes, sessions and playbook runs; create and edit (but not delete) agent definitions and playbooks. Read-only on the workspace itself, its environments and its secrets; no member or token management.

Two details in that table are easy to miss and matter in practice:

• A plain member cannot launch anything. Read across the organization and create a workspace, yes; spawn a runtime, no. If a teammate can see everything and start nothing, they are a member and need a workspace role.
• workspace-editor is read-only on environments and secrets. They can use what is there — launch into an environment, run an agent whose definition references a secret — but they cannot create, change or delete either. Environments and secrets are administrative surfaces on purpose.

What is not a separate permission boundary

Roles are granted per workspace, never per project or per environment

There is no project-scoped or environment-scoped role. Everyone with a role in a workspace has that role over every project and every environment in it.

So if you need person A to reach project X but not project Y, the answer today is two workspaces, not two projects in one workspace. Projects and environments are governed by permissions; they are not independently grantable.

Plan your workspace layout around who should see what. That is the axis the model actually enforces.

What runs where, and what can see what

• Your containers run on your infrastructure. PlatformSmith schedules them; a controller you installed starts them. The controller connects outbound — you never open an inbound port, and PlatformSmith never dials into your network.
• Model credentials are yours. The coding agent runs on your Anthropic or OpenAI account. Prompts and code go from your container to your model provider under your own credential.
• Secrets are encrypted at rest and never returned in plaintext by any API surface, including the MCP control plane. They are injected into containers whose agent definition references them — see What the platform can and cannot see.
• A coding agent has your container's access. It can run commands and reach the network your container can reach. Scope that with the environment you launch into.

Accounts and sign-in

• Sign-in methods available on a deployment are set by whoever operates it: password, Google, GitHub, or a combination. Signup can be disabled entirely, making the deployment invite-only.
• Linking a Google or GitHub identity is authenticated-only by design: you sign in first, then link. There is no path where arriving from an identity provider silently attaches to an existing account — that would let anyone who can prove an email address take over an account with it.
• Personal access tokens act as you, with your permissions. Treat one as a password. → API and automation

Reporting something

If you find a security issue, please report it privately rather than opening a public issue — see Support.