Zekt authorizes through GitHub. Your enterprise authorizes through Microsoft Entra ID. Zekt Gate is the piece that lets the second one speak to the first — without either side giving up the identity model it already relies on.
The short version
One paragraph, then the detail
Your developer portal signs a developer in with their corporate account and calls Zekt on their behalf. Zekt, however, expects a GitHub identity, because that is what its automation path has always used. Zekt Gate sits at that seam: it accepts the Entra token your portal already holds, proves the token is genuine, works out which Zekt customer the token belongs to, and hands Zekt a request it can trust. Your developers never need a GitHub identity to make that call, and Zekt never has to stop being GitHub-native.
Where the problem starts
Nothing is broken, and it still does not work
The gap is not a missing API. Zekt already has APIs. The gap is that nothing at the edge can say who is calling in terms your enterprise recognises.
The automation path works
A developer pushes code, a GitHub Actions workflow runs, and zekt-action calls Zekt. The GitHub identity establishes who the caller is, and Zekt authorizes on that basis. This path is not the problem and does not change.
The portal path has nowhere to stand
A developer opens Backstage, signs in with their corporate account, and asks for infrastructure. Backstage holds an Entra token. Zekt expects a GitHub identity. There is nothing in between that can turn the first into a request Zekt will trust.
The usual workarounds are worse
Associating a personal GitHub account with a corporate developer, or wiring a shared service account into the portal, both produce calls Zekt will accept and nobody can attribute. A credential that stands in for an enterprise is not an enterprise identity boundary.
So the request never gets made
In practice the portal integration stalls, or it ships with an exception written into a risk register. Neither outcome is the platform team getting what it wanted, which was to offer Zekt services from the place developers already work.
What it does
Four things, in order, on every call
Zekt Gate is deliberately thin. It is an ingress and trust layer, not a second platform, and what follows is very close to the whole of its job.
Prove the token is real
The signature is checked against the issuing tenant, the issuer is checked against the expected Entra issuer, the audience is checked against the Zekt Gate API, and the lifetime is checked against the clock. Decoding a token is not validating it, and Gate never treats the two as the same thing.
Work out whose call it is
The tenant claim in the validated token decides which enrolled Zekt customer this is — never a field in the URL or the request body. That single rule is what stops one customer reaching another by editing a request.
Decide whether it is allowed
A valid token is not permission to do everything. Delegated user scopes and application roles are evaluated separately, the requested operation is checked against your policy, and anything uncertain fails closed rather than open.
Hand Zekt a request it can trust
The call is metered for usage attribution, stamped with the caller, the application and the correlation context, and forwarded to the existing Zekt Directory, Registry or Orchestrator API. The result comes back unchanged.
What it is not
The list matters as much as the last one
A component that sits at your identity boundary earns trust partly by being small. These are commitments about scope, not features postponed to a later release.
Not an identity provider
Gate issues no identity and holds no credentials of yours. Entra remains the authority on who your people are; Gate only reads what Entra signed.
Not a directory management tool
Enrollment validates tokens rather than requesting broad access to your tenant. Gate does not ask for permission to manage your Entra environment, and cannot.
Not a second Zekt
The Directory, the Registry, the Orchestrator, service contracts and version semantics all stay in Zekt. Gate implements none of them and is not a place where they could drift.
Not a general API gateway
Gate translates enterprise identity into Zekt request context, for Zekt requests. It is not an API management product and is not intended to front anything else.
Not a second billing system
Metering happens at the call so that usage is attributable where it occurs, then feeds the billing model Zekt already has. There is no separate invoice to reconcile.
Not tied to Backstage
Backstage is the clearest example, not a dependency. Anything that can obtain an Entra access token for the Gate API is a client on the same terms.
Why it is separate
A boundary cannot live inside the thing it protects
Every other Zekt add-on ships inside Zekt Core and is switched on from within it. Zekt Gate is a separate product, deployed apart and licensed on its own. That is a design decision, and these are the reasons.
The check and the checked stay on opposite sides
Gate stands between your identity provider and Zekt. If it shared Zekt Core’s runtime, the component doing the validating and the component being protected would sit in the same trust context.
A failure at the edge stays at the edge
Enterprise ingress is the exposed surface. Keeping it decoupled means a compromise there does not widen into orchestration or into provider workflows.
Zekt stays GitHub-native for everyone else
Customers who do not need enterprise identity are not asked to absorb it. The core product keeps the model that suits its automation path, and this stays a premium capability for those who need it.
Is this you?
Who needs Zekt Gate
Zekt Gate assumes you are already a Zekt customer. It changes how requests reach Zekt, not what Zekt does once they arrive.
You probably need it
- Your developers reach internal tooling through a portal such as Backstage
- That portal authenticates people with Microsoft Entra ID
- You want Zekt services offered from inside it
- Your security review asks who made a call, from which application, on whose behalf
- Personal or shared GitHub accounts standing in for corporate identity is not something you can sign off
You probably do not
- Your teams consume Zekt entirely from GitHub Actions through zekt-action
- GitHub is already your organisation’s identity model
- No enterprise application needs to call Zekt on a person’s behalf
- You are evaluating Zekt itself and have not adopted it yet
What changes
Afterwards, the sentence you want to be able to say
Our enterprise identity is now a trusted way of consuming Zekt.
A developer signs into your portal with their corporate account and asks for a service. The portal presents its Entra token. Zekt Gate validates it, resolves your customer context, checks the permission and forwards the request. Zekt discovers, orchestrates and correlates exactly as it does for every other client, and the usage lands against the right customer. From Zekt’s side, nothing exotic happened: another trusted client entered the service model.
Enrollment runs through Zekt Core, which is where your Zekt account already lives.