Security, as it is built.
This page lists the protections Baselumen runs today, in plain terms. It claims no certification, because Baselumen holds none, and it ends with what is not done yet.
Sign-in and sessions. One account for the suite.
Accounts are handled by Clerk, the sign-in service the whole Stacklumen suite shares. You sign in on stacklumen.com, and that one sign-in covers Baselumen too.
-
Every app screen is gated
Signed out, a page under the app sends you to sign in, and a background request gets a refusal rather than a page. Each API route checks the session itself as well.
-
Sessions from the suite only
In production, a session token is accepted only when it was issued for one of the suite's own sites. If the sign-in service's key is missing, the app fails rather than running without sign-in.
-
One reading of every address
Every gate compares the decoded path. An address that cannot be decoded cleanly, such as one encoded twice or carrying an encoded slash, is refused outright.
-
Cross-site forms refused
A form post, upload or plain-text request that changes something and comes from another site's page is refused before it reaches the route.
-
The MCP endpoint checks origin
A browser page on another site cannot call the MCP endpoint: a request carrying a foreign origin is refused.
-
Sign-in returns home
After sign-in, you are only sent back to an address on the suite's own sites.
Tokens with a scope. Shown once.
Agents that cannot sign in, and the baselumen CLI, use a workspace token. A token starts
with bl_ and carries 160 random bits.
- Shown once: the token is shown when it is made and never again. Baselumen keeps a SHA-256 hash of it and its last four characters, so a stored token cannot be read back
- Owner only: only the workspace owner can make, list or revoke tokens
- Expiry and reach: a token lasts 30 days, 90 days, a year, or until revoked. It reaches the whole workspace or one client
- Checked every time: on every request the token is refused if it was revoked or has expired, if the person who made it is no longer the owner, or if the workspace is not active. A revoked token stops working on its next request
New token
7 scopes. Only the tools they allow.
A token can be limited to some scopes. The MCP tool list it sees holds only the tools those scopes allow. A token with no scopes chosen has full access, including tools added later.
- components:read
- Search the catalog, fetch source (recorded as copies), and read your custom components, site pins and designs
- components:write
- Create, edit and fork custom components, pin components to a Terminal site, and create, edit and push designs
- clients:read
- Read the client list
- deploy:write
- Deployments — reserved, no write tools exist yet
- dns:write
- DNS — reserved, no write tools exist yet
- account:read
- Read your profile, settings, the workspace and its members
- account:write
- Update your profile, settings and the workspace details
Agents sign in, too. You choose Allow.
An agent that supports it connects to the MCP endpoint by signing in with your Stacklumen account and asking
you to allow it. Clerk is the authorization server, and Baselumen publishes where to find it at
/.well-known/oauth-protected-resource.
-
Owners connect
Only a workspace owner can connect an agent. The owner role, an active workspace and the account's standing are checked again each time the agent's sign-in is verified.
-
Baselumen's scopes only
An agent's sign-in carries only Baselumen's own scopes. One that carries none of them is refused. The two reserved scopes are never granted this way.
-
Revocation is quick
A verified sign-in is remembered for 15 seconds at most, so a revoked one stops working within that time. Owners can disconnect an agent at any time.
One workspace cannot see another. The server decides.
Every read and write goes through Baselumen's server, which decides what the signed-in person may reach before it touches the database. Your browser holds no key that can read workspace data.
- Workspaces
- A workspace named in a request is used only if you are a member of it. Anything written is written to that workspace.
- Clients
- A client is looked up to the workspace that owns it, and you are checked against that workspace. A member limited to some clients reaches only those.
- Guests
- Someone invited by a client sees only that client's shared work and is sent away from the agency's screens. See guests on the agencies page.
- The database
- Row security stays on, so the public key the browser carries reads nothing. The key that can read data is kept on the server.
- Staff access
- Stacklumen staff can open a workspace they are not a member of only by giving a reason, which is logged, and for at most 8 hours. The workspace shows a Staff tag while they are in it.
Rate limits. Counted in one step.
Requests are counted in the database in one step, so two requests at once cannot both slip under a limit, and refused attempts count too. A refusal says when to try again.
- MCP endpoint
- 60 requests a minute from one address, checked before sign-in, and 120 a minute for a workspace, shared by all of its tokens
- Copying a component
- 60 a minute from one address; 10 in 10 seconds and 120 in 5 minutes for one person
- Component Studio, Generate
- 3 a minute and 30 an hour for one person
- URL tools and audits
- 30 a minute from one address; 6 in 10 seconds and 40 in 5 minutes for one person
- Design pushes to Terminal
- 10 a minute for a workspace, and 30 asset uploads a minute
- Contact form
- 5 an hour from one address
Fetching the URLs you give the tools. Nothing private on the way.
The audits read pages you name, so they are kept from reaching anything private on the way. Tests in the code hold each of these rules.
-
Public addresses only
Only http and https. Private, loopback and link-local addresses are refused, the cloud metadata address among them, and so are names such as localhost or anything ending in .local or .internal.
-
Every disguise decoded
Addresses written as a single number, in hex, or wrapped inside IPv6 are decoded before they are checked.
-
Names resolved first
A name is looked up before the request, and refused if any address it gives is internal. A name that does not resolve is refused.
-
Redirects checked hop by hop
Redirects are followed by hand, at most five, and every hop is checked again.
-
Webhooks are signed
Webhooks a workspace sets up are signed with HMAC-SHA256 and a timestamp, sent over https only, and the connection is held to the address that was checked.
-
Files handed out, not shown
Client files are refused if they are programs or scripts, and every file is given out as a download from a short-lived link. Uploads are capped at 100 MB, 50 MB from a guest.
Headers on every response. Set by the app.
The app sets these on every response it serves.
- Framing
- Pages can be framed only by the same site:
frame-ancestors 'self'andX-Frame-Options: SAMEORIGIN. The one exception is the component preview, which stacklumen.com may frame, and which runs sandboxed with no access to the site it sits on. - Content policy
- A Content Security Policy that blocks plugins (
object-src 'none'), pins the base address (base-uri 'self') and upgrades insecure requests. - Transport
Strict-Transport-Securityfor two years, including subdomains.- Browser features
- Camera, microphone, location, payment and USB are switched off by
Permissions-Policy. Content types are not sniffed, and referrers are cut to the origin when leaving the site.
Secrets stay on the server. The build checks itself.
-
The build checks itself
After every build, the output is searched for the value of every secret the build can see. If one is found, the build fails, and the report names the variable and the file, never the value.
-
Read when needed
Private settings are read on the server when a request needs them, never compiled into the code. A test fails if code reads them the other way.
-
Credentials encrypted
Credentials a workspace stores are encrypted with AES-256-GCM. Baselumen stores no AI provider keys: your agent runs on your own plan.
Request logs strip tokens, bearer values, secret-named fields and email addresses before anything is written.
Your data. Yours to keep.
- Ownership
- You own everything you put into the products. Stacklumen claims no ownership of it and does not use it to train anything.
- Export and deletion
- To export, correct or delete your personal data, or to delete your account, write to support@stacklumen.com from the address you sign in with. Accounts are deleted by Stacklumen staff on request.
- Workspaces
- An owner deletes a workspace on stacklumen.com. It is switched off for 14 days, when the owner can still restore it, and then removed.
- Who processes it
- The services that store and process data for the products are listed on the sub-processors page. How data is used is in the privacy policy.
Reporting a vulnerability. And what is not done yet.
Write to support@stacklumen.com with what you found and how to reproduce it. People who report responsibly are thanked. The acceptable use policy says the same.
Not done yet
- Certifications
- Baselumen holds no security or compliance certification.
- A security address
- There is no separate security inbox or security.txt yet. Reports go to support.
- Self-serve export
- There is no button to download your data yet. Exports are done on request.
A question this page does not answer?
Write to support@stacklumen.com and ask it.