01 / Trust and security

Where we actually stand, and where we are going.

Ember is early. We are not claiming a mature enterprise control framework, and this page is written so you can tell the difference between what is true now and what is intended.

For diligence forms or procurement questions, talk to us and we will answer at this level of directness.

todayintended

02 / Posture

Kept in separate columns on purpose.

What we can say today, next to what we are working toward.

Area

Today

Working toward

Access scope
Today
Integration access is scoped to what a feature needs. We are not claiming an audited access model.
Working toward
Per-integration scopes with revocation, and an access record customers can read.
Customer data
Today
We keep what the product needs and drop what it does not. Retention is not yet fixed in writing.
Working toward
Published retention that matches what we actually run, not an aspiration.
Tenant separation
Today
We are not describing a tenancy design yet, because it is still in motion. Saying more would be guessing.
Working toward
A documented separation model, written up once it is what we ship.
Explainability
Today
Every assessment carries the evidence and provenance behind it. That is a product commitment, not a security control.
Working toward
Evidence trails a reviewer can export, replay and challenge.
Formal assurance
Today
No certification. We will not claim one we cannot stand behind.
Working toward
Outside review and compliance work when the product is ready to carry it.

If something you need is only in the right-hand column, say so. We would rather lose a deal on timing than win one on a claim we cannot support.

03 / Principles

Intentions, not a finished control list.

Four commitments that shape how the product gets built.

01
Least privilege, and keep the boundaries visible
Grant integrations and features only the access they need, and keep admin and integration boundaries legible as Ember changes. A boundary nobody can see is not a boundary.
access
02
Treat sensitive context as earned
Keep what the product needs, drop what it does not, and do not assume access to something just because an integration technically exposes it.
data
03
Separation customers can reason about
Over time, predictable separation between customer environments, so a team can answer where their data sits and what crosses a line without asking us.
tenancy
04
Auditability, because the product is a claim-making system
Ember produces assessments about production systems. If a team cannot follow one back to its evidence, it should not act on it, and neither should we.
trust

04 / Notes

Written to be quoted back at us.

The detail, in plain terms.

Data and retention

Customer data is something we carry through the life of the product: what arrives from integrations, what we derive from it, and how long it still makes sense to keep. Retention and the exact shape of subsystems will change as we ship more. When we write it down for customers, it will match what we actually run.

Integrations and credentials

Integrations should use scoped credentials wherever the platform allows it, and we want to avoid broad access when a narrower scope does the job. That applies both to Ember talking to third-party tools and to how we separate paths internally as the team grows.

Separation between customers

Stronger separation between tenants is how we expect the platform to mature. We are not spelling out a tenancy design here because it is still in motion. Architecture and trust notes will describe what we ship, not what we hoped for early on.

Logging and operational visibility

Logging and traceability matter both for running the service well and for helping customers see what happened during an incident. We plan to deepen operational visibility as Ember scales, as part of running something real rather than as a tagline.

How this page will change

Security gets deeper as the product does: clearer internal habits, better documentation for buyers, and formal assurance work when the time is right. We will not chase certificates we cannot stand behind, and we will not quietly move a line from the right column to the left one.

05 / Thinking

An assessment you cannot inspect is a risk, not a feature.

All writing

06 / Diligence

Security questions, integration scope, or a form to fill in?

Send it over. We will answer what is true now and what is queued for soon, and we will tell you plainly which is which.

Talk to us

Vulnerability reports are welcome. Our disclosure contact is published at /.well-known/security.txt.