Skip to content
Quark

products · foundation

The layer everything stands on.

Foundation is not an add-on: identity, secrets, access, metering, and quotas ship with every deployment — and every product runs on them from the first call.

identity

Orgs, projects, and keys that scope everything.

The tenancy model is simple enough to explain in one breath and strict enough to build a business on.

Organizations sit at the top

Every project belongs to one — the boundary for ownership and membership.

Projects scope the work

API keys, model visibility, and every resource you create live inside a project. Teams get their own lanes; nobody borrows someone else's credentials.

API keys are shown exactly once

At creation, and never again — the console keeps only a display prefix that can never authenticate. Revocation is a click, and it's immediate.

Service accounts for the workloads

Runs and automations get their own identity, so “who did this” always has an answer.

secrets

Written once, shown never.

The credentials that make AI workloads go — model API keys, connection strings, tokens — are exactly the values that end up pasted into tickets and chat threads. Secrets are built to make that impossible.

The value is displayed exactly once

At creation, with a deliberate confirmation — then it's sealed. Not even the console can show it again.

Grants, not grab-bags

Each secret is scoped to the workloads that may receive it. A run gets a secret because it was granted that secret, by name.

Versions, not overwrites

Rotate by adding a new version; consumers follow the secret, not a copy.

An audit trail you can read

Every create, version, grant, revoke, and delivery — for the whole project, in order.

for your security reviewer

Upstream credentials never exist as plaintext in config, environment files, or CI variables — only as sealed values with named grants and a complete audit history.

access

Least privilege, with a veto.

Authorization in Quark is plain enough to review in a meeting.

Roles are named sets of actions

Granted to people and service accounts — the allow side of the story.

Policies are explicit allow and deny rules

A matching deny vetoes everything else, regardless of role grants. When you need to say “never,” the platform means it.

Defaults that make sense

A sensible baseline lets the project breathe; anything sensitive is one explicit grant away from being locked down.

Least privilege by construction

Workloads receive the secrets and permissions they were granted — and nothing else, anywhere on the platform.

underneath

A substrate built to be trusted.

The governance layer stands on a substrate designed to be trusted.

Authenticated transport on every plane

Platform services mutually authenticate over encrypted transport, workloads carry identities of their own, and your console and API clients speak keys and tokens.

Workloads have identities of their own

Platform services verify who's asking, not just which key was presented.

Every request is checked against tenancy

Isolation is enforced on each call, not assumed from network position.

Hardened execution when it counts

For workloads with stricter demands, runs can be hardened or confidential — isolation is a dial, not a fork.

metering

Metering by default.

Usage isn't sampled or estimated; it's emitted by the products as they serve.

By key

Every completion through the gateway is attributed to the API key that made it. Teams, products, and customers get their own keys — and their own answerable column in the ledger.

By product

Gateway calls, sandbox time, index builds, and the rest roll up separately. When spend moves, you'll know which product moved it.

By metric

Requests, tokens, and the platform's own units of work, each tracked in its own right — no blended “units” that explain nothing.

Rolled up, always visible

Spend and usage summaries live on the platform's front page, not buried in an export.

quotas

Quotas that actually enforce.

A budget that only reports is a newsletter. Quotas are enforced where usage lands.

Set a cap per metric, within a rolling window

For a key, a product, or the whole project.

Early warning, in plain sight

Every quota shows its current state — healthy, near the cap, or exceeded — with the headroom rendered as a bar you can read at a glance.

Hard stops at the point of use

When a quota is exhausted, further usage is refused until the window rolls over. Runaway spend is stopped by the platform, not by whoever happens to be awake.

Pair it with gateway limits

Per-key caps on requests and tokens give you a second enforcement point exactly where model spend happens.

for whoever approves the bill

Every team can have its own key and its own quotas — and one team's experiment can never quietly become the company's invoice.

the questions

Built for the questions you'll actually ask.

What did this customer cost us this window?

Usage by key, on one page.

Why did our bill jump?

Usage by product, on the same page.

Are we about to hit the cap?

Quota states with headroom, no export required.

Can we give the intern's script a ceiling?

Yes — a quota is a few fields away.

contact

Talk to us about running Quark.

Tell us about your workloads — we will show you what your own cloud can do.