Security and access, layer by layer.

In short

Your organisation's boundary

Everything you keep belongs to one organisation, and only that organisation's active members can open it. Access rules in the database keep each organisation's data apart, and the app checks them again. The Trust Centre explains how that is tested.

• One person, several organisations. Someone can belong to more than one organisation, with a different role in each. Whatever they open is judged by the organisation it belongs to, never by their place in another.
• Only your own people. Access can be given only to the organisation's own members and teams. Anyone else joins by invitation first.
• Owners and admins of the organisation have full access to everything in it, and only they open its settings.

Roles and places

Access follows the shape of your work. An organisation holds workspaces, a workspace holds projects, and a project holds its folders, documents, whiteboards, plans, work items and database. Access given to a place reaches everything inside it, unless something inside has access of its own.

Teams give a group of people access in one step, and are on the Pro and Enterprise plans. Inviting people and changing roles are in People and teams.

How access is decided

Each time someone opens or changes something, Stable Baseline asks the same questions, whether the request comes from the app, an AI tool, the API or an agent:

1. 1

   Are you an active member of its organisation?

   If not, the answer is no. A deactivated member has no access at all.
2. 2

   Are you an admin?

   An owner or admin of the organisation has full access to everything in it. An admin of a workspace has full access to what that workspace holds, apart from databases, which have their own sharing.
3. 3

   Which grant is nearest?

   Stable Baseline looks at the item, then its folders, its project and its workspace, and the first place with a grant for you or one of your teams decides. A grant of your own there decides; otherwise your teams' grants do, and a team's No access keeps you out. With no grant at all, your workspace role decides.
4. 4

   What does the grid say for this kind of item?

   A grant on a project can allow or deny Read, Write and Delete for each kind of item in it.
5. 5

   Is someone acting for you?

   An agent, Orbit or an AI tool gets only what both you and it may do.

The grid

When you share a project, the Share dialog's Override access grid sets Read, Write and Delete for its improvements, documents, plans, whiteboards and databases. A workspace's grant has the grid's Databases row. Each cell is Inherit, which follows the level, Allow or Deny.

• Allow turns that permission on, even beyond the level the grant gives.
• Deny turns it off for that grant only. When another of the person's grants allows it, such as one given to their team, the most generous wins.
• Admins: organisation owners and admins are never held by a Deny, and neither are a workspace's admins in its documents, whiteboards, plans and improvements.
• A grant on something nearer, a folder or a document, decides there instead.

Who can own work

A task or an improvement can be owned only by an active member of the organisation who can open it, or by one of the organisation's own teams. The owner pickers offer only those people, and a change that names anyone else is refused, with the reason in plain words.

When access ends

Access ends when someone is deactivated or removed, when a grant is taken away or lowered, or when an item moves somewhere they cannot open. Each takes effect straight away, and within seconds for someone in a live editing room:

• The app applies the change to their next request, in every session they have open.
• Live editing. Everyone in a document or board being edited together is checked again every few seconds. Someone whose access was lowered is made read only, and someone who lost it is dropped.
• Keys and connected apps of a deactivated or removed member stop working. When a grant is lowered, what their keys and connected apps may do is lowered with it.
• Agents and duties never act past what the person they work for may do now. A duty pauses if its owner can no longer act, until someone chooses another owner. A shared agent whose owner is deactivated or removed passes to the organisation and keeps working; one that was never shared waits for an admin to adopt it.
• Approvals can be decided only by someone who can still read what the job read.
• Removing someone also takes away their grants, their database access and their roles on agents, and deletes their AI chats in the organisation, so nothing comes back if they are invited again. Deactivating keeps everything, ready for when you reactivate them.
• Invitations. An invitation's link is sent only to the person invited, and a cancelled invitation stays cancelled. Accepting one never changes the role of someone already in the organisation, and never switches a deactivated member back on. An invitation never makes anyone an owner.

Documents

• Documents follow their project's access, and the Documents row of the project's grid. A folder, or a single document, can also be shared with chosen people and teams.
• A copied link opens only for people who already have access.
• Search shows a document only to people who may read it, its author included, and a mention tells someone only if they may read the document.
• Moving or deleting a folder needs that right for everything inside it. Moved items take on the access of their new place, and access given to them by hand is removed.
• Every version records who saved it, and what an agent or an AI tool changes is recorded under its name. See Version history.

Plans and the work register

• Plans, tasks and improvements follow their project's access, and the Plans and Improvements rows of the project's grid.
• A task or an improvement can be owned only by someone who can open it (see who can own work), and an assignment notice names a task only to someone who may read it.
• In a plan's or an item's activity, every entry names who made it. Only comments can be changed or deleted, by their author or by an admin of the project, workspace or organisation, and an edit to someone else's comment is recorded.
• Looking a record up by its short id, such as TAS-12, finds it only in projects you may open.

Whiteboards and decks

• Whiteboards follow their project's access, and the Whiteboards row of the project's grid. A board being edited together is checked again within seconds, as documents are.
• A deck belongs to its board: only people who may open the board see its decks.
• Decks run sealed off. A deck plays in a frame of its own, apart from your session, so it cannot read your sign-in or anything else in the app. It loads fonts and pictures only from Stable Baseline's own hosts, what it holds is cleaned before it is shown or exported, and its links open in a new tab, and only to secure addresses.
• Meeting Scribe draws on a board: see Meeting Scribe.

Databases

Databases have access of their own, apart from documents. Organisation owners and admins can always open and manage every database.

• Whole project or Chosen people. A database shared with the whole project, or the whole workspace, opens for the people there, at their access to databases: a grant's Databases row in the grid can set Read, Write and Delete, and at Inherit they follow the person's level. A database shared with Chosen people opens only for the people and teams it lists: the place's access neither opens it nor keeps anyone out of it.
• Levels. No access, Can view, Can edit or Can manage, for each person or team. A grant on the database, or on one of its tables, decides what that person can do there: hide a table from someone, or make it view only for them.
• Rows. A table rule decides who sees which rows: Open, Edit your own, See your own, or Private rows. One row can be shared more narrowly still, with Only some people.
• Hidden stays hidden. A row hidden from you is never shown, counted or added into a total. A value you may not see shows as Restricted, blurred, with the tooltip “You don't have access to the underlying data.” The value itself is never sent to you.
• Worked out for you. A lookup or a rollup over linked rows counts only the linked rows you may see. A figure that draws on another table's totals is hidden from you if any of the rows behind it are.
• Links. A link to a row you may not see shows nothing of that row.

More on sharing a database, its levels and its rules: Databases.

Forms

A form is its own permission. Whoever it lets in can answer, whether or not they can open the table, and answering shows them nothing else of it: no other rows, and no count. Only people who manage a table can open its form to people outside the organisation. See who can answer.

Dashboards and downloads

Every number on a dashboard is worked out for the person looking at it, from the rows they may see, and a visual on a table they cannot open shows nothing. A dashboard's link gives nobody any rights. Downloads of a dashboard, a view or a table are made the same way, for the person who asks.

Records: who did what

• Document versions say who saved each one.
• Activity on plans, tasks and improvements lists every change and comment, each under the name of who made it.
• Row history and audit keep every change to a database row, with who made it and when: for 7 days on Free, 30 days on Plus and Pro, and 60 days on Enterprise. Owners and admins can keep it for less, or turn it off.
• An agent's activity lists every run, how it started and what it did, and a run can be undone.
• Each connection to an outside app shows what it did.
• The organisation's activity logEnterprise lists what happened across the organisation, from document edits to member changes and security events, and marks what an agent or an AI tool did.
• Your Security Log, in your account settings, lists your own sign-ins and security changes for 90 days.

How long each record is kept is in the Trust Centre.

Agents and duties

• It works for the person who asked. A job someone starts runs within both the agent's access and that person's own, checked at every step. Sharing an agent never lets anyone have it do what they could not do themselves.
• Every change is on the record under the agent's name, together with the person it worked for.
• Some tools are never an agent's: billing, members, teams, permissions, settings and other agents.

Duties

• A duty's runs work for its owner, within the agent's access and the owner's own. A duty hears about a document, a board, a row or a meeting only when its owner may read it.
• If its owner can no longer act, a duty pauses and says so, until someone chooses another owner.
• Changing a duty someone else owns needs the access the duty uses, unless you are an owner or admin of the organisation.
• Outside Stable Baseline, a duty does only what its setting allows: Drafts only, Ask before each send or Send on its own, and deleting always asks. Only owners and admins can let a duty send mail on its own, and its replies go only to the email domains they allow.
• A duty may do at most two of three things: read things from outside, reach private information, and act outside on its own.

Approvals

• An approval goes only to the people it is for: the person who asked for the job, or a duty's owner and the backups chosen on the duty.
• To decide, a reviewer must be able to read what the job read. Anyone else on the list sees “You can't review this because you don't have access to the underlying data.” and cannot decide.
• If nobody on the list can decide, the request waits with the owner, who is told how to put it right.
• Adding a backup checks first that they have the access the agent uses. The bell and the emails about an approval reach only its reviewers, and each decision is checked again at the moment it is made.

Connectors

• An owner or admin connects a mailbox for the organisation. A personal connection is used only for work its owner starts, or duties they own. Each connection can read only, draft, or send, and the organisation's rules can only make it stricter.
• A connection's sign-in is kept encrypted and is never shown to anyone, admins included. A sign-in completes only for the person who started it.
• Each connection keeps a record of what it did.
• Disconnecting stops agents using it at once and removes its sign-in: Stable Baseline asks the provider to end it, and deletes the sign-in it kept. A personal connection of someone who leaves the organisation is disconnected too.
• The mail agents work with, and how long it is kept, is in the Privacy Policy.

AI apps over MCP

• You choose what it may do. Signing in from an AI tool opens a consent screen: the organisation, the places it may reach, and Read, Write and Delete for each kind of content. An API key offers the same choices.
• Databases start unticked. A new key or sign-in reaches no database until you tick it, and you can hold it to chosen databases, and to chosen tables in them.
• Write without Delete deletes nothing. It can add and change, never remove.
• Never more than you. A key or a sign-in only narrows what its person may do, and when your access changes, so does its.
• Organisation tasks are off until an owner or admin turns them on: members, teams, permissions, billing and settings.
• Your sign-in first. Making a key, or approving an AI tool's sign-in, needs your own sign-in to be complete, second factor included.
• Revoke at any time. Every key and signed-in tool is listed in your settings, every call is recorded against it, and revoking one stops it at once.

Each choice in detail: Permissions.

Orbit

Orbit has exactly your access: it reads and changes only what you can open yourself, whatever you ask it to look at. It checks with you before it changes things, as your organisation allows, and always asks before deleting something for good, sending anything outside Stable Baseline, or spending money or a larger amount of credits at once. See how Orbit checks with you.

Meeting Scribe

Meeting Scribe says what it is. It joins the call as a bot, never as a person, by default under your organisation's name with Scribe, and posts a note in the meeting chat saying what it does and that the host can remove it. It transcribes only, and stores no recording.

Starting it needs edit access to the board. What it shows the meeting, as its camera or a screen share, is only the part of the board it draws, and that stops when the meeting ends, when the output is switched off, or when the person who started it can no longer open the board.

The platform

Where your data lives

• Your content is stored in Australia, in Sydney, and encrypted where it is stored. Every connection is encrypted in transit, with TLS 1.3, and sign-in tokens, keys and other secrets are stored encrypted.
• Diagrams are drawn in the Oceania or Asia-Pacific region by Cloudflare: rendered in memory, nothing stored, zero data retention.
• Pictures you make or change with AI are processed outside Australia.
• Your content is never used to train AI models.

Where everything is processed, and how AI uses your content, is in the Trust Centre. Every supplier, what it does and where, is on the subprocessor list.

Signing in

• Signing in with an email and password, or an email link, needs a code from an authenticator app as well.
• With Google, Google confirms who you are, and an account that has an authenticator still asks for its code. With single sign-on, your identity provider confirms it.
• You are told by email when Google is linked to your account.
• Single sign-on, on the Pro and Enterprise plans, connects your identity provider. Once you enforce it, members on your verified domains sign in only through it, and owners keep a way back in.

Sessions and your Security Log

In your account's security settings, Active Sessions lists the browsers and devices signed in as you. End one, or choose Sign Out All Other Sessions: your keys and connected apps keep working, and you revoke those separately. The Security Log lists your sign-ins and security changes for 90 days.