If Kalitka cannot confirm that a request was approved, the request does not pass. No approval, no exception.
Kalitka only accepts forwarded request metadata from proxies you declare as trusted. Everything outside that boundary is treated as untrusted input, including headers a client can set itself.
Approval links carry a short-lived, single-use capability. Once it is resolved — approved or denied — it cannot be replayed, which is what makes email a usable approval channel.
A grant is bound to the resource it was requested for. Approving access to one application does not open any other resource behind the same gate.
Requested → approved or denied → active → expired. Every transition is deliberate and recorded, and the resolution is atomic so a request cannot be decided twice.
Who asked, for which resource, who decided, when, and how long the grant lasted — persisted as durable audit events you can inspect later in the control plane.
Report suspected vulnerabilities privately using the process in the repository's SECURITY.md rather than in a public issue.
Kalitka is an additional gate. It does not replace the authentication and authorization of the protected application.
Keep your existing login — Google, LDAP, local credentials, MFA. Kalitka decides whether the request should reach it at all, right now, and writes that decision down. Questions and findings belong in the repository.
