Seven things that are true before you connect anything.
Each of these is a property of how the system is built rather than a promise about how we behave. The detail underneath every one of them is further down the page.
- Workspaces are isolated
- Every read, write, list and search is scoped to one workspace owned by one organization. Storage keys, search shards and database rows are partitioned by workspace; a token carries only the organization and scopes you approved.
- You approve every agent, and you can revoke it
- No agent reaches your content until you authorize it. The dashboard lists every connection, what it was granted and when it was last seen, and revoking one takes effect immediately.
- Every change has history
- Writes produce a new version rather than replacing bytes. You can read what a document said before, compare two versions, and put an earlier one back.
- Conflicting writes stop before work is lost
- When two agents reach for the same document, the second one is told it moved and reconciles. There is no last-write-wins, and no silent clobber to discover later.
- Deleted work is recoverable
- Deleting moves a document to a per-workspace trash where a person can restore it. Only after its retention window does a scheduled job purge it for good.
- Your content is not used to train models
- We do not train machine learning models on the contents of your documents. Aggregated, de-identified usage data may be used to improve the service.
- There are deployment options past the shared service
- Where the answer to "where does this data live" has to be something specific, Markbase can run inside your own environment or as a single-tenant deployment in your cloud account.
The detail
How it's actually built.
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 and dashboard: 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, object storage 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 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.
Sign-in and agent access
Your sign-in
- Sign in with Google or GitHub. We do not store passwords.
- Server-side sessions for the dashboard; session cookies are HttpOnly and Secure.
- Organization membership controls which workspaces you can reach.
How an agent is authorized
- OAuth 2.1 with mandatory PKCE (S256), exact redirect-URI matching, and Resource Indicators (RFC 8707) so tokens are audience-bound to the 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 dashboard origin, with CSRF protection and clickjacking headers.
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.
What we store, and for how long
- Minimal collection. We collect only what's needed to operate the service — account information, the documents you submit, agent connection metadata, and operational logs.
- Soft delete, then scheduled purge. Deleted documents move to a per-workspace trash where they can be restored. A daily job permanently purges what remains past its retention window.
- Search 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.
Retention windows for account data, tokens, billing records and server logs are in the Privacy Policy.
Legal and 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 transfers.
- CCPA/CPRA. We do not sell or share personal information. Our DPA includes CCPA service-provider certification.
When things go wrong
- Documented incident response procedures for identifying, containing and remediating security incidents.
- Personal Data Breach notification without undue delay and no later than 48 hours, as committed in our DPA.
- Object-storage versioning means an accidental or unauthorized write can be rolled back during recovery.
- Post-incident review and remediation for all security events.
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.
- The full sub-processor list is published at markbase.cloud/subprocessors.
Found a vulnerability?
We’re grateful to security researchers who help keep Markbase safe. If you’ve found something, please reach out privately before public disclosure.
- We acknowledge reports within 2 business days.
- We work to understand and validate the reported issue, and 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.
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.
Deployment
Somewhere specific, if that’s what your review requires.
Past the shared service there are two options, and the difference is who operates it: Markbase deployed inside your own environment, or a single-tenant deployment in your cloud account that we run for you. Both are scoped and quoted.
See the deployment options