Security
Zekt Gate sits at the point where corporate identity crosses into a SaaS platform, which makes it the thing a security reviewer will want to understand before approving anything. It validates Microsoft Entra tokens, derives customer context from the token rather than the request, authorizes every operation, and asks for no standing access to your directory.
Enrollment establishes that Zekt Gate can validate tokens issued by your tenant. It does not request broad directory access, and it does not ask to manage your Entra environment.
Zekt Gate issues no identity of its own. There is no Gate login, no Gate password and no Gate credential for a person — sign-in happens at Zekt, and enterprise callers present tokens your own directory issued.
The token’s signature is verified against the issuing tenant’s published keys, and the issuer must be the expected Entra issuer. Signing key rotation is normal identity-provider behaviour, requires no action from you, and causes no outage here.
The audience must be the Zekt Gate API — a token minted for something else is refused even when it is otherwise valid — and the token must be inside its lifetime.
Delegated user access and application access are distinguished explicitly and carry different permission models. Scopes and application roles are evaluated against the requested operation.
Anything uncertain is refused rather than allowed. That is a deliberate posture, not a consequence of unfinished code.
The customer context is derived from the validated token. No request parameter selects a customer, so a token from one tenant cannot reach another customer by changing a URL segment or a body field.
This is a property of the code rather than of the infrastructure. Network rules and resource boundaries cannot supply it, which is why it is asserted by tests rather than assumed from the topology.
Zekt Gate is deployed apart from Zekt Core rather than inside it. A boundary cannot live inside the thing it protects: sharing a runtime would put the check and the checked on the same side of the line.
It also contains failure. Enterprise ingress is the exposed surface, and keeping it decoupled means a compromise there stays there rather than widening into orchestration or provider workflows.
Last updated 2026-09-19
