Auth and tenancy¶
Callers prove identity differently per product. Do not assume one header works everywhere.
Fraud Detection¶
Evidence: fraud-detection-ai-backend/src/auth/, stream */src/auth/, appconfig.py.
| Mechanism | Role | Status |
|---|---|---|
| Bidirectional RS256 JWT | AI services ↔ software/dashboard backend | IMPLEMENTED |
Authorization: ApiKey <jwt> |
Bearer scheme used by auth utils | IMPLEMENTED |
x-tenant-id |
Tenant scope on stream predict routes and report/dashboard handoff; required on /chapelhill/instruction_check |
IMPLEMENTED |
AI_PRIVATE_KEY / BACKEND_PUBLIC_KEY |
Sign outgoing / verify incoming | IMPLEMENTED |
AUTH_ENFORCEMENT_ENABLED |
Kill-switch (default enforce) | IMPLEMENTED |
SERVICE_NAME |
JWT sub / service identity (optional; defaults vary) |
IMPLEMENTED |
JWT claims (verify path): incoming tokens expected iss=software-service, aud=ai-service (see bidirectional_jwt_service.py). Outgoing tokens use iss=ai-service, aud=software-service, short TTL (~5 minutes).
Checks /report → dashboard: signs with AI private key, sends Authorization: ApiKey … and x-tenant-id.
Pub/Sub push handlers on the checks service are primarily invoked by GCP push (OIDC at the edge is UNKNOWN from app code alone). For local tests they also accept raw JSON or Pub/Sub envelopes.
KYC / KYB¶
Evidence: kyc-kyb-ai-backend/src/app.py, src/config/appconfig.py.
| Mechanism | Role | Status |
|---|---|---|
CORS allow_origins=["*"] |
Browser origins unrestricted in app | IMPLEMENTED (harden at gateway) |
| Prembly / Serper / Mistral / Whisper keys | Upstream vendors | IMPLEMENTED via env |
GCP ADC / GOOGLE_APPLICATION_CREDENTIALS |
Vertex, BigQuery, GCS | IMPLEMENTED |
| Bidirectional JWT on routes | — | NOT FOUND on listed HTTP routes |
| Gateway API key in front of Cloud Run | — | UNKNOWN (confirm per env) |
Banking Reconciliation¶
Evidence: service READMEs, exception resolution docs, route payloads.
| Mechanism | Role | Status |
|---|---|---|
tenant_id / partner_id (and related scope fields) |
Multi-tenant isolation on ingest / exception resolve | IMPLEMENTED in contracts |
| Cloud Run service identity | Service-to-service HTTP + Pub/Sub | IMPLEMENTED (platform) |
| Bidirectional JWT (fraud-style) | — | NOT the primary documented pattern for recon HTTP |
Exception resolve is scoped by partner_id + tenant_id + domain + cluster_type (+ optional ids / status band) — see exception resolution.
Integrator checklist¶
- Product + environment (local / staging / production)?
- Auth mechanism for that environment?
- Tenant / partner scope fields required?
- Trigger = HTTP, Pub/Sub, or both?
- Idempotency / dedupe key on retries?