How Gravity controls who can read, change and publish your docs

Gravity holds documentation that customers, partners and coding agents act on. That makes three questions matter more than any feature: who can sign in, who can change what readers see, and whether you can show, later, exactly what was published and who approved it.

This brief answers them as the platform works today. Where something is not available yet, it says so. The ledger below is the short version; each line links to the chapter that explains it.

Members sign in through your identity provider over SAML or OIDC, so joining, leaving and multi-factor rules stay where you already manage them. Single sign-on can be required for your email domain, which removes the password path for your own people entirely.

People who sign in with a password, such as contractors on another domain, can protect it with an authenticator app and one-time backup codes. Passwords and codes are never written to logs.

Automatic provisioning through SCIM is not available yet. Today an admin invites each member and gives them a role, and removing a member ends their access to the organization.

There are four roles: Owner, Admin, Editor and Viewer. They are fixed, which keeps a review short: the matrix below is every permission each one holds. Custom roles are not available.

What shapes access is where a role is granted. A role can be given for the whole organization, or for one site, space or collection. For any page, the grant closest to it applies, whether it is higher or lower than the organization role. Owners and admins keep their role everywhere.

Readers are a separate question from members. Each space decides which audiences may read it: everyone, signed-in readers, developers, or audiences you define and fill by email. A single block can be limited to an audience, so one page can carry a partner-only paragraph without a second copy of the page.

Editing in Gravity is fast and collaborative, and none of it is visible to readers. A change reaches readers only through a change request: required reviewers compare it with the live page, approval rules decide who must sign off, and only someone whose role includes publishing can publish it.

Each publish creates a new numbered version. The version stores a hash of its content, the hash of the version before it, who published it and when, signed by Gravity’s server. Changing an old version later, even directly in the database, breaks the chain from that point on, and verification says where.

Alongside the versions, the audit log records every request made to the platform, by people, tokens and agents alike: who made it, the action, the resource, whether it succeeded or was refused, when, how long it took, and from which address and client. Refusals are recorded too, which is often what an investigation needs.

Gravity writes documentation from your code without taking the code. The CLI runs inside your CI, where the repository already is, and sends Gravity the docs it writes, each block pointing to the file, lines and commit it came from. Your repository is not cloned to our servers.

Passes that write prose send requests through Gravity’s AI gateway, and those requests can contain code snippets. The gateway passes them to the model provider and keeps neither the request nor the reply, only a record of who, when, which model and how many tokens.

Coding agents and assistants reach your docs over MCP. Access is granted the way you would grant it to an app: a person approves the connection on a consent screen, every time, and the agent then acts with that person’s permissions and no more.

The person can disconnect it at any time. Revocation is checked on every call, so the next request is refused, not the next day’s. Each call, each approval and each revocation is in the audit log.

Your data is backed up every night, and each backup is kept for 35 days. Recent changes can also be recovered to a point in time, which covers mistakes noticed the same day. Connections to Gravity and from Gravity to AI providers are encrypted.

Licences change over a contract’s life, so they are designed never to strand anything. If a licensed feature lapses, what it holds stays readable, and revoking access or removing items keeps working. You are never left with data you cannot reach or a credential you cannot turn off.

Our SOC 2 audit is in progress, and we will not describe Gravity as certified until it is. During your review we share our current security posture and the audit timeline, a data processing agreement and the subprocessor list.

The answers below are written for questionnaires. Search them, copy one, or copy them all. If yours asks something they do not cover, send it to us.