Products and engineering · Noida · established 2026

We build software our customers can run without us.

Frontier Labs builds and sells its own products. The first is Pramaan ID: one Rust binary, zero inbound firewall rules, zero components hosted by us — an identity provider and Zero-Trust control plane that runs inside the customer's own network. Access tokens are bound to a key the device cannot export (DPoP, RFC 9449), so a copied token is inert in anyone else's hands. We take client engineering and platform work on the same terms: the source, the infrastructure definitions and the credentials stay with the client. There are no case studies yet — the mechanism below is what there is to judge.

Watch a token get refused How we take on client work

Three lines of work, one team

Frontier Labs

The deployment, in numbers we can be held to

  • 1

    Rust binary to run

    OIDC provider, device registry, policy engine and connector control plane in one process.

  • 0

    Inbound ports opened

    Connectors dial out to the control plane. Publishing an internal service is a policy change, not a firewall change.

  • 0

    Components hosted by us

    Self-hosted only. No managed tenant, no hosted trial, and no operational access to a running installation.

  • RFC9449

    DPoP, implemented

    Tokens are bound to a key the device generates and never exports, so a copied token is inert elsewhere.

Every figure here is a property of the software rather than a claim about our business. Each one is checkable by running the binary; none of them is a customer count, and none of them is a timing that would change on your hardware.

Demonstration

You cannot check a claim. You can check a mechanism.

Everything above this line is an assertion, and assertions are what every vendor page is made of. What follows is the mechanism itself: what Pramaan ID does to a stolen token, and what our own mail client is held to. Both are drawn here in HTML, CSS and SVG rather than photographed, so they stay legible at 320 pixels, weigh nothing, and can be read by a screen reader — and so that nothing on this page can be mistaken for a screenshot of something that does not exist.

Pramaan ID · beat 4 of the twelve-minute demo

One token. Two machines. One of them is refused.

An access token is a bearer token: whoever holds it, holds the session. The industry answer is a shorter lifetime, which narrows the replay window without closing it. Pramaan ID issues the token against a public key the device generated and cannot export, and records that key's RFC 7638 thumbprint inside the token as cnf.jkt. The exchange below is the one the demo walks through on stage.

A token bound to the key of the device it was issued toOn the left, a laptop holding a private key that cannot be exported, chained to a token that carries that key\u2019s thumbprint. On the right, the same token offered to a second laptop holding a different key: the path is barred before it arrives.
  1. 01 The private key never leaves The device generates a P-256 key pair with extractable set to false. There is no API that returns the private half — the browser refuses in its own words. On a phone this is the secure element; the property is identical.
  2. 02 The token names the key Only the public half is enrolled. The issued token carries cnf.jkt, the thumbprint of that key, so the token says which key is allowed to use it rather than trusting whoever presents it.
  3. 03 Every request carries a fresh proof A short JWT signed by the private key, bound to the method, the URI and a one-time identifier. Capture one off the wire and reuse it and the second use is refused — it buys an attacker a request they already watched succeed.
  4. 04 The refusal needs no revocation The broker takes the thumbprint of whoever signed the request and compares it with the one inside the token. On a second machine they do not match, so the token is inert — while remaining perfectly valid, unexpired and unrevoked for the device that holds the key.

The enrolled laptop

device A

  1. Request from the device the token was issued to

    GET /userinfo
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9.eyJzdWIi…
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwiandr…

    200The proof is signed by the key whose thumbprint the token carries.

Any other machine

device B · same token

  1. Attempt 1 — the same token, presented as an ordinary bearer token

    GET /userinfo
Authorization: Bearer eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9.eyJzdWIi…

    401No proof at all. This is the attack every bearer-token system loses to.

  2. Attempt 2 — the same token, with a real DPoP proof from this machine

    GET /userinfo
Authorization: DPoP eyJhbGciOiJFUzI1NiIsInR5cCI6ImF0K2p3dCJ9.eyJzdWIi…
DPoP: eyJ0eXAiOiJkcG9wK2p3dCIsImFsZyI6IkVTMjU2Iiwiandr…

    401This proof is valid and correctly signed. It is signed by the wrong key, and cnf.jkt does not match.

And stillBack on the enrolled laptop, the same token still answers 200. It was never revoked and it has not expired. It simply does not work anywhere else.

Frontier Mail · what we hold our own software to

We run our own mail on the same terms we sell.

Every page a Frontier Labs mailbox user sees — sign-in, the mailbox, the composer, the admin console — is our code, served from our own infrastructure. It is the standard we ask clients to judge us by, so the figures beside it are the ones we actually measure on every deploy, not a target we are working towards.

100/100

browser tests passing

Driven in a real headless Chromium, not against curl. Every bug this client has shipped — CORS, Trusted Types, history — was invisible at the protocol level.

127.0KB

critical path

Everything fetched before the first message is on screen, fonts included. Measured on every run, not budgeted for.

10,000

messages, no pagination stall

The list is virtualised, so a mailbox that size scrolls without the main thread blocking on it.

0

components we ask you to trust us with

The same rule as Pramaan ID. If you run it, you run all of it.

Three people read this page. They are not asking the same question.

If you own security

“What happens when a token is stolen?”

It stops working. Not sooner — elsewhere. Binding is DPoP, RFC 9449, and the demo above is the test you should make any vendor sit through: copy a live token into a second browser and watch what the product does.

If you own the platform

“What am I actually running?”

One Rust binary, inside your perimeter, under your DNS, with signing keys generated on your side. No agent fleet to hold at matching versions, and no inbound firewall rule — connectors dial out.

If you sign the contract

“What happens when you leave?”

Nothing stops. The engagement is written to end: infrastructure in code in your repository, credentials rotated out, our access revoked in a way you can verify yourself. There is no retainer to sign and no hosted component to keep paying for.

Not a screenshotEverything in this section is drawn with HTML, CSS and SVG — there is not one screenshot on this page. These are illustrations of how the software behaves, built from the same request flow the demo runs live. They are not captures of a running system, and we would rather say so than have you find out.

Products

Our own products, installed on your side of the firewall.

Products are one of the three things we do, and the one where we choose the defaults, the threat model and the release schedule ourselves. One product is shipped; the rest of this section is what it does, how it is deployed, and where it stops.

Shipped — an identity provider and Zero-Trust control plane in a single Rust binary.

Pramaan ID

प्रमाण — pramāṇa, Sanskrit: proof, or the means by which a claim is established as true. That is the job an identity provider does, once per request.

An access token is a bearer token: whoever holds it, holds the session. The usual answer is a shorter lifetime, which narrows the replay window without closing it, and short enough to matter is usually short enough to break ordinary use. Pramaan ID binds the token to a private key held on the device it was issued to, so a copied token is inert in anyone else's hands. The same binary is the OIDC provider, the device registry, the policy decision point and the control plane for outbound-only connectors that reach private applications without an inbound port.

How a device-bound request is checked
  1. 1EnrolThe device generates a key pair and keeps the private key. Only the public key leaves it.
  2. 2AuthenticateThe person signs in. The token is issued against that public key, not to the bearer.
  3. 3ProveEach request carries a short JWT signed by the private key, bound to the method, the URI and a one-time id.
  4. 4DecideThe policy engine evaluates person and device, then allows the connector to reach the private application.

A token copied from a log, a proxy or a browser profile fails at step 3 — the key never left the device it was issued to. DPoP · RFC 9449

  • Device-bound tokens (DPoP, RFC 9449)

    A token is issued against a public key the client generates and holds. Every request then carries a short proof JWT signed by the matching private key and bound to the HTTP method, the URI and a one-time identifier the server can reject on replay. A token lifted from a log, a proxy or a browser profile is inert without that key, and the key is not in the token.

  • Outbound-only connectors

    The connector runs beside the private application and dials out to the control plane; nothing new listens on a public interface and no inbound rule is added at the edge. Publishing an internal service becomes a policy change rather than a firewall change, and the application keeps no public DNS record of its own.

  • People and devices are both principals

    Enrolment records the device against a key it generates and does not export, so a session is a pair: this person, on this device. Policy is evaluated against both, which is what lets access be granted to an engineer on an enrolled laptop and refused to the same engineer — same password, same second factor — on an unknown one.

  • One binary, inside your perimeter

    The OIDC and OAuth endpoints, the device registry, the policy engine and the connector control plane are one Rust process, so there is no agent fleet or sidecar to hold at matching versions. It runs on your hardware, under your DNS, with signing keys generated on your side — we have no operational access to a running installation.

BoundaryPramaan ID is self-hosted only. There is no managed tenant and no hosted trial, and none is planned. If you need identity to be somebody else's service, we are not the vendor for it.

What comes after Pramaan

More products are in progress. We are not going to name them, sketch the category or collect addresses for a waiting list: an announced roadmap is not a product, and the announcement is the easiest part of it. Engineering and platform work funds the product line, so the next one ships when it is installable and documented rather than when a page needs filling. It will be published here in the same shape as this one — what it does, what it refuses to do, and how to run it yourself.

Engineering practice

We take on one or two builds at a time, and they run on the people who build our own product.

Frontier Labs was registered in Noida in 2026, so there are no case studies on this page and nothing dressed up to look like one. What exists is a shipped product — Pramaan ID, a self-hosted identity provider that runs as a single Rust binary — and a delivery model we are willing to set out in full before anything is signed. Client engineering runs on the same people and the same terms.

The people who scope it write it

There is no second team behind the first. Whoever sits in the technical call is whoever opens the pull requests, and there is no account manager in between to relay decisions. That is also why the number is one or two rather than ten: it is the honest limit at our size, and we say so when the next slot is not free.

Your repository, your infrastructure

Commits land in your remote from the first week, not in ours. CI runs on your runners, secrets stay in your vault, logs and metrics go to your account, and infrastructure is described in code — Terraform, or whatever you already run — rather than clicked into a console. Nothing is handed over as an archive at the end, because nothing was withheld along the way.

Estimates carry their assumptions

We quote a range and write down what the range assumes: expected data volumes, the authentication model, which third-party APIs sit on the critical path, who controls DNS and the certificate chain. When an assumption breaks, the estimate is revised in writing with the reason attached. A fixed price agreed before the schema exists is priced for our risk, not yours.

Where we are deep, and what we decline

Rust, TypeScript, Postgres and Linux, with identity and access as the layer we know best. Pramaan ID is the public evidence of that, and its architecture is set out further down this page, so you can judge the work rather than the claim. We do not claim the same depth in mobile, data science or embedded work, and we will point you elsewhere instead of learning on your budget. We also decline seat-filling engagements where the architecture is decided in a room we are not in.

How Pramaan ID is built

Platform and infrastructure

Everything between
a merge and a customer.

Accounts, networks, pipelines, secrets, and the signals you get when something is wrong. Engineering decides what the software does; this work decides what happens to it after merge, and who can reach it. It is scoped work inside your cloud accounts and your repositories, and every change arrives as a pull request your team reviews and can decline.

Environments rebuilt from a repository

Terraform or OpenTofu, remote state with locking, environments composed from the same modules with separate state per environment, and nothing created by hand in a console. Where infrastructure already exists we begin with an import phase, bringing live resources under state before changing any of them. That phase is slow on a large estate, so it is scoped and priced as its own piece of work rather than absorbed into the rest.

Credentials that expire

Static cloud keys in CI replaced with OIDC federation to a role only a named workflow can assume. Human access through short-lived sessions rather than standing SSH keys. Secrets in one store with an audit trail, and a break-glass path that is documented, tested, and deliberately noisy when it is used.

The path from merge to production

One build artefact promoted across environments instead of rebuilt at each stage. Schema migrations separated from the deploy that depends on them, so either can go out or be reversed on its own. Rollback rehearsed as a scheduled exercise, not attempted for the first time during an incident.

Instrumentation before dashboards

OpenTelemetry traces across service boundaries, structured logs carrying the same request id end to end, and alerts written against user-visible symptoms rather than CPU graphs. Expect the first pass to delete more alerts than it adds. A pager that fires on things nobody acts on teaches people to ignore it.

BoundaryWe are not a managed-services vendor. There is no retainer to sign and no on-call rota to buy: the engagement is written to end, with your team operating what we leave behind. Runbooks, diagrams, and the reasoning behind each decision live in your repository, not ours.

Method

Same four steps for a client's system and for our own products.

Nothing in this list is exotic. The order is the part we hold to: constraints before architecture, a deployable path before the first feature, a rehearsed handover before the work is called finished. Each step exists to make the next one cheaper. It is the order we used to build Pramaan ID, and the order we would follow on your payments service or on a Terraform estate that none of us wrote.

  1. 01

    Constraints before architecture

    Before any design, we write down what must be true: where data may sit, which identity provider or ledger you cannot replace, what has to keep working through a network partition, what your own team will maintain after we leave. For Pramaan ID the binding constraint was that nothing inside the customer's perimeter may accept an inbound connection; outbound-only connectors and a single binary follow from that, not from taste. If the constraints cannot be written on one page, we say so before quoting, not after.

  2. 02

    A deployable path before the first feature

    The first thing we put into your environment is the thinnest slice that genuinely runs there: build, deploy, roll back, logs, metrics, one real request served through the whole path. It usually looks like nothing was built. It settles certificate renewal, secrets handling, egress rules and who may authorise a production change while each of those still costs a day, rather than when a release is already waiting on them.

  3. 03

    The engineer you meet is the engineer who commits

    There is no bench behind us. The engineer in the technical call is the one whose name is on the commits, and we do not substitute quietly. Work lands as small changes in a repository you own, with the decision notes in the tree beside the code, so a wrong direction shows up in a diff on a Tuesday instead of at a milestone review. On a system we did not write, the first commits are tests that pin existing behaviour before anything is changed.

  4. 04

    Handover is rehearsed, not documented

    The engagement ends with someone on your side running the full deploy and a restore from backup, on your infrastructure, while we watch and stay quiet. Infrastructure is in code, credentials held only by us are rotated out, the dependency and licence list is handed over, and our access is revoked in a way you can verify yourself. The runbook covers the two or three things that will actually page someone, not every screen.

BoundaryWe are not the cheapest firm in Sector 2, we will not fix a price on a scope that is still being discovered, and we do not put engineers on a project whom you have not met. If you need thirty people by next quarter, this is the wrong firm to ring.

On the record

Frontier Labs Private Limited, and what it is not yet.

Incorporated in 2026 and registered at A 67, Sector 2, Noida, Uttar Pradesh 201301, GSTIN 09AAHCF1478M1Z3. There are no case studies on this site because there are none yet. What there is instead is architecture: the request flow, the deployment topology, the RFCs we implement and the things Pramaan ID deliberately will not do. All of it can be checked without speaking to us.

Established 2026

That is recent enough to matter and we are not going to write around it. There is no client list to show, so the thing to judge is the work: read the token flow, run the binary on your own hardware, and form a view of the engineering from that.

One team, three lines of work

Our own products, client engineering and platform work are done by the same people. Pramaan ID is the first product we have shipped; others are in progress and we will not name or describe them until they exist in a form you can install.

No bench, no account layer

The people you meet on a call are the people who write the code, and there is no handover to a delivery team once the estimate is signed. If we cannot staff a piece of work ourselves, we will say so rather than subcontract it quietly.

What we do not do

Pramaan ID is self-hosted only: there is no managed tenancy to sign up for, and running it for you is not on offer. We do not take staff-augmentation contracts billed by the seat, and we are not competing on rate. If price is the deciding variable, someone else will win it.

Registered and invoiced in India

A private limited company under the Companies Act, GST-registered, invoicing in INR. Contracts, IP assignment and MSAs are signed by the entity rather than by an individual.

Entity
Frontier Labs Private Limited
GSTIN
09AAHCF1478M1Z3
Registered office
A 67, Sector 2
Noida, Uttar Pradesh 201301
India
Incorporated
2026

Contact

What to send, and what comes back.

For Pramaan ID, the useful first message is your current identity provider, roughly how many internal applications you want behind a connector, and the constraint forcing the change — an audit finding, a customer security review, a VPN you would rather stop maintaining. Ask for the DPoP request flow, the deployment topology or the system requirements and that is what comes back. Evaluation runs on your own hardware, and a call is more useful after you have had the binary running than before.

For engineering or platform work, send the system as it stands: what runs where, what breaks, what you have already tried and the date that is actually driving this. We will tell you in that first exchange whether it is work we should be doing at all.

contact@frontier-labs.in Read the Pramaan ID architecture

Replies come from whoever would do the work; there is no sales desk in between and nothing on this site is behind a form. We work to IST (UTC+05:30), which overlaps the European working day; anything further west is arranged case by case.