Markbase
Security

Security by architecture, not just policy.

Markbase is a hosted Markdown document store reached over MCP. Workspaces are isolated, every write produces a new version, parallel agents can't clobber each other, and the OAuth flow for MCP clients is hardened the way the spec describes — not the way it's usually implemented.

Request access

Architecture

Isolation, versioning, and idempotent writes

The most differentiating part of Markbase's security model isn't a policy — it's the shape of the system. Workspaces are isolated at the storage layer; writes produce new versions instead of replacing bytes; and the contract for agents writing the same file is an ETag, not a hope.

Workspace isolation

Every read, write, list, and search is scoped to a single workspace owned by a single organization. Object-storage keys, search-index shards, and database rows are all partitioned by workspace ID; tokens carry only the org and scopes you approved.

Versioned by default

Documents live in S3 with bucket versioning enabled. Every successful write produces a new version — nothing is destructively overwritten. Accidental deletes and bad agent writes can be recovered from prior versions.

Conflict-free concurrent writes

Every read returns an ETag; every write asserts the ETag it expects. If two agents race, the loser gets a clean etag_mismatch back and reconciles. There's no silent clobber, no last-write-wins surprise.

Per-folder governance

_markbase.md files inside a workspace declare conventions for that subtree (purpose, frontmatter contract, append-only norms). The conventions travel with the data and are read by every agent before it acts — no CLAUDE.md to replicate into every harness.

Hardened OAuth 2.1 for MCP

MCP clients connect through our native OAuth 2.1 Authorization Server: PKCE S256 mandatory, exact redirect-URI matching, single-use authorization codes (10-minute TTL, hashed at rest), RS256 access tokens (1 hour) with rotating keys, and opaque refresh tokens hashed at rest with rotation on every use. Reuse of a rotated token revokes the whole chain.

You own the trust list

The dashboard's Connections page lists every MCP client authorized against your workspaces, the scopes granted, and last-seen timestamps. Revoking a client invalidates its refresh token immediately; previously-issued access tokens expire on their one-hour clock.

Infrastructure

Where things run

  • Application hosting: Hetzner Online GmbH (Germany). API, OAuth Authorization Server, Postgres database, and search index run on a managed Kubernetes cluster in Hetzner data centers.
  • Object storage: Amazon Web Services S3 (us-east-1), with bucket versioning enabled and server-side encryption (SSE-S3) at rest.
  • DNS, CDN, marketing site & dashboard SPA: Amazon Web Services (Route 53, Amplify, CloudFront), serving from the United States and AWS's global edge.
  • Encryption in transit: TLS 1.2 or higher on all external connections.
  • Encryption at rest: Postgres, search index, S3, and backups are encrypted at rest. OAuth signing keys are stored as managed secrets, not in source.
  • Network isolation: Production workloads are segmented inside the Kubernetes cluster with network policies; ingress is gated at the load balancer with TLS termination by cert-manager.
  • Patch management: Regular updates to operating systems, the runtime image, and application dependencies. Production images are built fresh on every release.

Access Control

Authentication & MCP authorization

Your sign-in

  • Sign-in with Google. We do not store passwords.
  • Server-side sessions for the dashboard; session cookies are HttpOnly and Secure .
  • Organization membership controls which workspaces you can access.

Agent / MCP client authorization

  • OAuth 2.1 with mandatory PKCE (S256), exact redirect-URI matching, and Resource Indicators (RFC 8707) so tokens are audience-bound to the MCP endpoint.
  • Dynamic Client Registration (RFC 7591) is rate-limited per-IP; registration tokens gate later management operations (RFC 7592).
  • Authorization codes are single-use, hashed at rest, and expire after 10 minutes.
  • Access tokens are RS256-signed with rotating keys and expire after 1 hour. Refresh tokens are opaque, hashed at rest, rotated on every use, and expire after 30 days.
  • Stolen-token detection: reuse of a rotated refresh token revokes the entire rotation chain.
  • The consent screen is rendered server-side off the SPA origin, with CSRF protection and clickjacking headers (frame-ancestors 'none' ).

Our systems

  • Multi-factor authentication required for all administrative access to production.
  • Unique accounts for all personnel — no shared credentials.
  • Principle of least privilege across all internal systems.

Data Handling

What we store, and for how long

  • Minimal collection. We collect only what's needed to operate the Service — account info, the documents you submit, OAuth client metadata, and operational logs.
  • Soft-delete with scheduled purge. Deleted documents move to a per-workspace trash where they can be restored. A daily CronJob permanently purges items remaining in trash.
  • Search index scoped per workspace. The full-text index is partitioned per workspace and per organization. There is no cross-tenant search path.
  • No training on your Content. We do not use the contents of your documents to train machine learning models. Aggregated, de-identified usage data may be used to improve the Service.
  • Account deletion. On account closure we cascade deletion across the database, search index, and object storage in accordance with our retention policy.

Detailed retention windows for account data, OAuth tokens, billing records, and server logs are in the Privacy Policy .

Compliance

Legal & regulatory

Markbase is operated by AltaCoda LLC, a Delaware limited liability company. We comply with applicable data protection laws including GDPR and CCPA/CPRA.

  • GDPR. We act as a data processor when handling personal data on your behalf. Our DPA includes Standard Contractual Clauses (Module 2) for EEA, UK, and Swiss data transfers. Sub-processor list published at markbase.cloud/subprocessors .
  • CCPA/CPRA. We do not sell or share personal information. Our DPA includes CCPA service-provider certification.
Document Link
Terms of Service markbase.cloud/terms
Privacy Policy markbase.cloud/privacy
Data Processing Addendum markbase.cloud/dpa
Subprocessors markbase.cloud/subprocessors

Incident Response

When things go wrong

  • Documented incident response procedures for identifying, containing, and remediating security incidents.
  • Personal Data Breach notification within 72 hours, as required by GDPR and committed in our DPA.
  • Bucket versioning on object storage means accidental or unauthorized writes can be rolled back to a prior version during recovery.
  • Post-incident review and remediation for all security events.

Vendor Management

Sub-processor oversight

  • Due diligence conducted on all sub-processors before engagement, evaluating their security practices and data protection controls.
  • Contractual data protection obligations imposed on every sub-processor.
  • 30-day advance notice of sub-processor changes, with objection rights for customers.
  • Full sub-processor list published at markbase.cloud/subprocessors .

Responsible Disclosure

Found a vulnerability?

We're grateful to security researchers who help keep Markbase safe. If you've found a vulnerability, please reach out privately before public disclosure.

  • We acknowledge reports within 2 business days.
  • We work to understand and validate the reported issue and will keep you updated.
  • We will not take legal action against researchers acting in good faith.
  • We ask for reasonable time to remediate before public disclosure.
security@altacoda.io

Transparency

What we don't do

  • We don't use the contents of your documents to train machine learning models.
  • We don't sell or share your personal information.
  • We don't read your workspaces outside of normal Service operation.
  • We don't mix data across organizations or workspaces.
  • We don't destructively overwrite a write (versioning catches it).
  • We don't store full payment card numbers.