[feature] Initial Cognitive Firewall MVP — FastAPI façade + Python SDK + rule-based detection

[RachanaB5]

Summary

Deliver a minimal end-to-end “Cognitive Firewall” MVP that is easy to run and demo: an HTTP API (FastAPI) in front of the existing Python SDK and UDS sidecar, with rule-based detection/signals on the evaluation path (regex / pattern lists / simple scoring — exact scope in PR).

This issue is scoped to MVP: correctness and clear contracts over full Phase 2–3 pipeline parity.

Motivation

• Lower the barrier to try ACF without wiring UDS-only clients.
• Provide a stable /validate-style contract for tools and integrations without replacing the sidecar or IPC design from Phase 1.
• Align with #6 by not proposing FastAPI as the production PEP↔PDP transport; the hot path remains SDK → UDS → sidecar.

Scope (proposed)

• FastAPI app: health + at least one endpoint that accepts hook + payload and returns ALLOW / SANITISE / BLOCK (and optional sanitised body) matching existing SDK semantics.
• Uses acf Python SDK (Firewall) against the running sidecar (ACF_HMAC_KEY, socket path).
• Rule-based layer: configurable patterns/rules (YAML or JSON) applied in-process before or after sidecar round-trip — to be clarified in PR (prefer one clear story, e.g. “pre-filter + sidecar” or “sidecar-only + HTTP wrapper”).
• README or short doc section: how to run sidecar + API + example curl/HTTP client.
• Tests: FastAPI route tests with mocks or integration behind a flag.

Non-goals (for this MVP)

• Replacing UDS with HTTP for the PEP↔PDP path.
• Full OPA/Rego or full pipeline parity (tracked in roadmap phases).

Related

• Architecture: docs/architecture.md
• Overlap / alignment: #6

Acceptance criteria

• One-command or documented sequence to run sidecar + FastAPI + successful validation of a sample payload.
• CI passes; new code is tested.

[shayankashif123]

Hi — I’ve been going through the codebase in detail, including firewall.py, models.py, transport.py, the architecture docs, and the existing test structure, and I’d like to work on this.

My understanding of the problem is that the firewall currently has no HTTP interface. Using it requires writing Python code directly against the SDK, which makes demos, HTTP-based integrations, and usage from non-Python tooling difficult. Introducing an HTTP layer would solve this while keeping the hot path (SDK → UDS → sidecar) unchanged.

For the proposed design, I’m thinking of a pre-filter + sidecar approach. A rule-based pre-filter would run in-process before every sidecar call. Critical-severity patterns would short-circuit immediately to BLOCK without requiring a sidecar round-trip, while softer signals would be recorded and merged with the sidecar’s decision. The SDK would continue to handle the sidecar communication unchanged for all requests that pass the pre-filter.

The ValidateResponse would include the final decision, signals from both layers, an overall score, and a rule_based flag to indicate whether the decision came from the pre-filter or the sidecar.

One important detail I noticed is that sdk/python/pyproject.toml intentionally declares zero external dependencies. I’ll keep that untouched. Any HTTP-related dependencies like FastAPI, uvicorn, and pyyaml will be isolated in a separate api/requirements.txt so the SDK contract remains clean.

I also saw that jailbreak_patterns.json is currently empty. Since the rule engine depends on it, I plan to seed it with some initial patterns as part of this contribution.

One question before I begin: the issue mentions “pre-filter + sidecar OR sidecar-only + HTTP wrapper — prefer one clear story.” I’m leaning toward pre-filter + sidecar because it provides immediate, visible enforcement in the MVP without waiting for later pipeline phases. Does that align with your vision, or would you prefer starting with a sidecar-only HTTP wrapper and adding the rule layer afterward?

I’ll aim to have a draft PR ready within 3 days.

[EXDEV-oss]

Hey — I took a quick look at your API and had a thought.

I work with a couple of backend testers who focus on real usage scenarios (repeated calls, edge cases, and basic load behavior — not just manual QA).

If you’re open, I can run a short test on your current endpoints and send back a concise report on:

[shayankashif123]

@EXDEV-oss Hey — absolutely, that sounds valuable.Please go ahead and share your findings

[EXDEV-oss]

Hey — thanks for the green light here.

I’m starting a quick round of tests now. I’ll focus on:
• Endpoint reliability under repeated calls
• Latency / response consistency
• Edge cases (invalid inputs, limits, failures)

I’ll send back a concise report shortly.

Before I proceed — are there any specific endpoints or flows you want me to prioritize?

[EXDEV-oss]

I would prefer if we get connected on telegram
This is my user:@plotcrypt