Skip to content
ProxyAi
Open navigation

PROXIAI · REQUEST GATEWAY

Govern enterprise AI before sensitive data reaches a provider.

ProxiAI is a tenant-aware AI gateway that applies policy, protects sensitive information, and records auditable operational evidence before approved requests reach an AI provider.

Interactive demo may be started on demand.

request-trace.log
  1. authtenant verified · org_4f2a
  2. policyPII detected · scope: contact_info
  3. decisionALLOW_WITH_MASK
  4. providergroq · streaming response
  5. auditrequest logged · append-only

Representative trace · actual output streams live in the demo.

WHY A GATEWAY

Enterprise AI needs more than a direct provider key.

ProxiAI inserts one trusted control boundary between employees and the external model path.

Uncontrolled provider access

Direct AI access can bypass organisation policy, identity boundaries, and consistent operational controls.

SYSTEM SHAPE

A policy-aware gateway with explicit trust boundaries.

The Express API stays authoritative. Every tenant-owned query uses trusted organisation context, while provider SDK details remain inside adapters.

User / Client
Auth + Tenant Context
PII + Policy
Provider Abstraction
Groq

MongoDB

Tenant records, append-only usage/audit, encrypted or metadata-only history

Redis + BullMQ

Idempotency, rate limits, workers, health, and durable enqueue recovery

Operations

Low-cardinality metrics, safe logs, dashboards, alerts, and runbooks as code

REAL REQUEST LIFECYCLE

Every request follows a deterministic order.

Security checks happen before provider execution. Persistence and background work happen only through approved boundaries after the outcome is known.

Select or hover a policy outcome to trace it through the pipeline →

  1. 01Authentication
  2. 02Trusted tenant and permissions
  3. 03Strict request validation
  4. 04Idempotency and rate limits
  5. 05Authoritative token budget
  6. 06PII detection, classification, and risk
  7. 07ALLOW / MASK / BLOCK policy
  8. 08Provider retry, circuit, and routing
  9. 09SSE response
  10. 10Retention, accounting, and audit
  11. 11BullMQ background jobs

PRODUCT SURFACES

Chat for employees. Evidence and controls for administrators.

The product UI exposes the same backend truth rather than recreating policy, billing, or provider rules in the browser.

app.proxiai.me / workspace

SURFACE 01

Chat workspace

Conversation navigation, policy-aware streaming, safe Markdown, and explicit retention context.

Interactive product preview

Incident review

Policy-aware conversation

Summarize last quarter's incidents.
MASKEDIncidents declined after the updated policy rollout.
Ask a governed question…

SECURITY DESIGN

Protect data without hiding the enforcement boundary.

Implemented controls are explicit, tenant scoped, and tested. ProxiAI does not convert planned capabilities into public claims.

Deterministic sensitive-data controls

Rule-based detection preserves source spans, classifies without raw values, scores risk, and masks derived prompts without mutating the original request.

  • CONTACT_INFO
  • FINANCIAL
  • GOVERNMENT_ID
  • CREDENTIAL
  • INTERNAL_SECRET
  • BUSINESS_CONFIDENTIAL

Encrypted or metadata-only retention

AES-256-GCM storage uses a versioned runtime keyring, unique IVs, and tenant/resource-bound AAD. Encryption failure is strict: there is no plaintext fallback.

METADATA_ONLY

No message content is stored.

ENCRYPTED_STORAGE

Completed user and assistant content is stored as ciphertext for owner-authorized reads.

Database-backed RBAC

Access tokens identify the session; current user status, organisation status, role, and canonical permissions are reloaded from the database.

Restricted chat and own-conversation access through canonical permissions.

Append-only audit trail

  • Tenant-scoped, bounded safe metadata.
  • Required admin mutations commit with their audit event.
  • AuditLog update and delete operations are forbidden.
  • CSV export protects against spreadsheet formula injection.
  • No raw prompt, password, token, or secret payload.

RELIABILITY + ASYNC

Failures are normalized, retried carefully, and recorded safely.

Provider execution and background accounting use separate, bounded failure paths so chat delivery does not invent billing truth.

Provider boundary

Canonical adapters normalize completion, streaming, health, usage, and failures. Bounded retry and circuit state are reusable across candidates.

SCOPE

Groq is the only enabled production provider. The ordered fallback abstraction is tested, but the current production chain has one candidate.

Async accounting

Append-only RequestLog records known usage. Idempotent BullMQ workers reconcile billing and tenant-scoped analytics without mutating the source record.

SCOPE

Unknown provider usage remains unknown; no synthetic token or cost value is created.

Operational recovery

Worker heartbeats, provider-health state, failed-job retention, analytics/anomaly processing, and durable enqueue recovery make background failure visible and bounded.

SCOPE

Prompt, response, PII, credentials, and raw provider errors stay out of job payloads and logs.

OBSERVABILITY BOUNDARY

Instrumentation exists without pretending hosted delivery is always running.

Safe structured logs, a protected Prometheus-compatible metrics endpoint, low-cardinality labels, dashboard and alert definitions, and runbooks are implemented. Continuous hosted collection and alert delivery can remain intentionally deferred while the demo environment is deep-stopped.

VERIFIED RELEASE EVIDENCE

Engineering claims tied to a named evidence baseline.

This is dated internal release evidence from the repository audit baseline. It is not an external certification and does not silently track later commits.

evidence
Final gap audit baseline
verified_at
2026-08-22
source_commit
789136c

269 / 269

Backend tests

28 / 28

Frontend tests

63 / 63

Isolated integration

78.24%

Backend line coverage

77.62%

Frontend line coverage

CANONICAL DEPLOYMENT

AWS ECS/Fargate with a private application tier.

Immutable ECR images define separate frontend, API, and worker ECS/Fargate services. Secrets stay in AWS Secrets Manager rather than the frontend bundle or image layers.

PRIVATE APPLICATION NETWORKRoute53 + ACMDNS · TLSLoad Balancerpublic entryNext.js taskproduct surfaceExpress API taskauthoritativeBullMQ workerbackground jobsAtlasdatabaseRedisqueue + cacheGroqprovider

EXPRESS API TASK

Authoritative application boundary — every policy, auth, and PII decision happens here.

The low-traffic demo uses one task per service and snapshot-driven deep stop/start for cost control. This is not a multi-task high-availability claim.

HONEST LIMITATIONS

What the current release does not claim.

A trustworthy demo states what is deferred and what cannot be recovered, rather than filling the gaps with synthetic evidence.

  • LIMIT_01The interactive demo may be deep-stopped and started on demand for cost control.
  • LIMIT_02Attachments are deferred; there is no upload or multipart API in this release.
  • LIMIT_03Prompt caching and completed-response replay remain deferred pending safe storage contracts.
  • LIMIT_04Interrupted provider usage stays unknown when the provider supplies no authoritative usage; ProxiAI never estimates it as zero.
  • LIMIT_05Continuous hosted metrics collection and alert delivery may be intentionally deferred while demo infrastructure is stopped.
  • LIMIT_06No external penetration-test or compliance certification is claimed.

READY WHEN YOU ARE

See the governed request path in action.

The public demo account is restricted to employee chat permissions and must not be used with real personal or confidential data.