Skip to content
Ashlar Labs

A working document

Security.

The whole product is a question about what crosses the boundary between two organizations. This page is the answer in detail.

§ 01 The trust model

The trust model

Ashlar Labs hosts a shared investigation workspace where a software vendor and one of its technical customers work as peers on the same problem. Each side controls what crosses the boundary into the shared space. The workspace itself is exposed as MCP tools, so each side plugs in its own AI instead of routing model traffic through ours. We are responsible for the integrity and isolation of the workspace. Each side remains responsible for what they choose to put into it.

§ 02 Data regions

Where data lives

A workspace has three regions. Two of them are private. The third is shared.

  • Vendor-private. Internal context the vendor brings in: stack traces from prior incidents, internal hypotheses, references to other customers. The customer side cannot read this.
  • Customer-private. Internal context the customer brings in: their architecture notes, credentials reachable from their cluster, comments from their own engineers. The vendor side cannot read this.
  • Shared. Everything both sides have agreed should be in the joint investigation. This is what the workspace is for.

Content does not migrate between regions on its own. Promotion is always explicit and recorded.

§ 03 Scope & sensitivity

Scope and sensitivity are orthogonal

Every node in the workspace carries two independent labels: where it can be read, and how carefully it should be treated.

Scope answers who can see this. Private means just the author. Org means just the author's organization. Global means both sides.

Sensitivity answers how cautiously the content should be handled. Normal, confidential, or secret.

The two are independent on purpose. A vendor engineer can mark internal architecture notes as Org-scope and secret-sensitivity, work on them privately, and later promote them to Global with the sensitivity label preserved. The handling rules travel with the content.

§ 04 Promotion flow

Crossing the boundary

Anything moving from Private or Org scope to Global goes through a promotion step. Promotion is bilateral by design.

  1. The author marks the node for promotion.
  2. Server-side DLP runs against the candidate content. Rules cover common patterns (API keys, tokens, internal hostnames, employee identifiers) along with per-tenant patterns each side configures for themselves. Anything flagged is held. The author either redacts and resubmits, or overrides with a reason recorded.
  3. The counterparty side acknowledges. Without acknowledgment, the content stays on the originating side. There is no quiet propagation.
  4. The promotion event, its DLP result, and both acknowledgments land in the audit log.

§ 05 Audit log

The audit log

Every state-changing event in a workspace is recorded. The log is append-only and hash-chained, so a retroactive edit would break the chain and be visible to both sides on the next verification.

What gets recorded:

  • Workspace membership changes
  • Node creation, edit, and deletion, with diffs that respect redactions
  • Scope and sensitivity transitions
  • Promotion events, DLP findings, and bilateral acknowledgments
  • MCP tool invocations: which client, which tools, which arguments
  • Exports of the log itself

Either side can export their share of the log at any time, signed and verifiable.

The audit log is not a compliance feature. It is how the system stays honest in a relationship that has historically been one-sided.

§ 06 Bring your own AI

Bring your own AI

The workspace exposes itself as a set of MCP tools. You drive it from Claude Code, Claude Desktop, or any MCP client you trust, using your own model provider and your own API keys. We are not in the model loop.

What this means in practice:

  • Your model conversations do not transit our infrastructure.
  • We never see your model provider's API key.
  • We do not store your prompts. We store the tool calls your client makes against the workspace, because that is what the workspace is.
  • If your security policy forbids a particular model provider, you change the policy on your side. We do not need to be in the loop.

A traditional support tool with a bundled AI sits between you and your model provider. Ashlar Labs sits to the side: a shared workspace your AI can reach, not a path your AI traffic flows through.

§ 07 Identity & access

Identity and access

Workspace membership is the unit of access. Adding or removing a participant is bilateral: the originating side proposes, the counterparty side confirms. Participation changes are recorded in the audit log on both sides.

Authentication is via SSO with your existing identity provider. Workspace and tenant isolation is enforced at the data layer. No shared identifier crosses tenants.

§ 08 Infrastructure

Infrastructure

Production runs on managed cloud infrastructure. TLS protects all client-to-server and server-to-server traffic. Encryption at rest is provided by the underlying platform. Per-tenant secrets are stored in a managed secrets service and rotated on a defined schedule.

Specific providers, regions, and subprocessor details will appear in the Data Processing Addendum we publish before accepting any production data. Design partners who need that document earlier can ask, and we will share what we have.

§ 09 Disclosure

Vulnerability disclosure

Found something? Email security@ashlarlabs.ai. We will acknowledge within two business days, share a triage assessment within five, and credit you in the advisory unless you prefer not to be named.

We do not have a paid bug bounty yet. We do have a strong preference for working with the people who tell us about problems.

§ 10 Compliance posture

Where we are on compliance

Pre-launch. The honest answer is that we are building the controls first and pursuing the certificates next. SOC 2 Type I is on the roadmap. We will commit to a date when the audit begins. GDPR posture is being designed in from the start because the product is built on bilateral data exchange. A subprocessor list and DPA will be published with the production launch.

If your procurement process needs a specific document and the date matters, write to us and we will tell you exactly where we are.

If you read this far

Security on this product is not a feature added on top. It is the question the whole product is built to answer. If you are evaluating us and want to dig into any of this in detail, write to will@ashlarlabs.ai. We would rather have the hard conversation early.

Last updated: 2026-05-24