Architecture

Architecture | Honeypot Kkuldanji

A repository-derived architecture review covering components, control flow, operating boundaries, and the evidence a technical reviewer should inspect.

Reviewed 2026-07-28. This page is derived from checked-in repository evidence and links back to its source.

Service Architecture - honeypot

This document describes the implemented prototype and the controls required before it can become a deployable service.

Technical Role

Recommended Architecture

~~~text Reviewer with synthetic data -> static proof surface -> local React client -> FastAPI prototype -> demo-local users and self-issued JWT role claims -> process-local refresh, CSRF, rate-limit, task, and demo index state -> optional Azure document/search/model adapters in APP_MODE=live -> human-reviewed handover draft ~~~

APP_MODE=live means cloud adapters are connected. It does not mean the security or tenancy layer is production-ready.

Resource Plan

ResourceUseEnable timing
Static hostingPublic, cacheable proof surface and documentation.Keep as the default until server-side state is required.
App/API runtimeLocal or isolated integration-evaluation runtime.Do not expose to untrusted users with the current security profile.
Identity providerOIDC/SSO verification, tenant membership, server-authoritative roles, and access reviews.Required before staging or production can start.
Shared security stateRefresh-token revocation, CSRF/session state, and distributed rate limits.Required before multiple replicas or production traffic.
Data layerTenant-scoped workflow state, audit history, retention, and deletion records.Required before customer data is accepted.
Object storageUploads, reports, screenshots, model artifacts, or signed exports.Enable only when persistent artifacts are required.
Queue/cacheAsync jobs, retries, scheduled checks, and rate-limited workflows.Enable when reliability needs exceed direct request handling.
ObservabilityError tracking, performance traces, and privacy-safe usage signals.Enable before external users test the workflow.

Repo-Specific Resources

Security Promotion Gate

The repository deliberately implements no bypass flag for production. staging and production fail startup while the following are absent:

  1. External identity verification with issuer, audience, algorithm, and key-rotation validation.
  2. Server-authoritative tenant membership and role lookup; token role strings alone are insufficient.
  3. Shared refresh revocation, CSRF/session, and rate-limit state.
  4. Document-level authorization at both ingestion and retrieval.
  5. Tenant-scoped persistence, audit events, retention, deletion, backup, and restore.
  6. Production CORS/proxy trust configuration, observability, incident response, and rollback validation.

Changing JWT_SECRET, overriding demo passwords, or connecting Azure services cannot satisfy this gate.

Information Needed From Account Owner

Prototype Review Checklist