SOC Analyst Labs

How This Came Together

Here's the quick version of how it went. I started with Ollama (a tool for running AI models locally) running a small local model, llama3.2:1b, so I had something to actually test against. Then I built a FastAPI backend with a chat endpoint to handle incoming messages, and wrote the risk scoring logic myself, checking each prompt against patterns like ignore previous instructions or reveal your system prompt. Every message gets logged two ways, to a plain text file and a SQLite database (a lightweight file-based database), so nothing gets lost and I can go back through it either way. On top of that I built a dashboard in Streamlit (a framework for building data dashboards) so I'm not just collecting data, I'm actually reviewing it, risk scores, trends, what got flagged and why. Once it was live and getting real traffic, I went back through the whole thing with a security review mindset, found gaps, and locked it down properly before calling it done.

How It Works

The stack combines a FastAPI backend, a local Ollama model, SQLite logging, a Streamlit dashboard, and a text report generator. A prompt is submitted to the /chat endpoint, sent to a local Ollamaⓘ instance running llama3.2:1b, and reviewed by a keyword based risk scoringⓘ function. Higher risk prompts are logged as security events, and the visitor does not see the model's reply for them.

I designed it to do two things at the same time. First, it gives me a safe place to study how users might try prompt injectionⓘ against a local LLM. Second, it creates a monitoring trail that I can review through raw logs, a SQLiteⓘ database, a Streamlitⓘ dashboard, and a text summary report.

• FastAPI backend that accepts prompts and forwards them to a local Ollama llama3.2:1b model
• Keyword-based scoring logic that detects common prompt override and jailbreak language
• Dual logging to plain text files and a SQLite database for both quick review and structured analysis
• Streamlit dashboard with summary metrics, recent events, and basic trend views
• Plain-text reporting that summarizes prompt counts, high-risk events, critical events, and average risk score
• Honey Support, a public demo chat that looks like a normal customer support assistant but scores and logs every message
• Live API documentation, rate limiting, and an admin token (a secret credential that authorizes admin actions) for approving submitted findings, all hosted on Oracle Cloud

The project flow is intentionally simple and easy to audit. A client sends a prompt to the FastAPI /chat endpoint. The backend checks the message length and the rate limit, forwards the content to Ollama, scores the prompt for injection indicators, and decides whether the visitor gets the reply. It then writes the response and risk metadata to the standard chat log, copies higher risk events into a separate security log, stores the event in SQLite, and exposes that history to both the dashboard and the report generator.

Client (Honey Support demo page or API client)
  |
  v
FastAPI /chat endpoint (500 character limit, rate limit per IP)
  |
  +--> Ollama /api/generate (llama3.2:1b, Honey support persona)
  |
  +--> calculate_risk() + get_risk_level()
  |       |
  |       +--> response policy (score 50 or higher: reply withheld from visitor)
  |       +--> chat_log.txt
  |       +--> security_events.txt (risk score >= 50)
  |       +--> logs/honey_ai.db
  |                 |
  |                 +--> Streamlit dashboard
  |                 +--> report_generator.py -> report.txt

1. Client request: a visitor submits a prompt from the Honey Support demo page, or an API client sends one to the chat endpoint.
2. Input checks: FastAPI rejects messages over 500 characters and, by default, limits each IP address to 10 messages per hour.
3. Model proxy: FastAPI sends the prompt to the local Ollama generate API with a short instruction that sets the Honey support persona.
4. Risk review: the backend normalizes the text, checks it for prompt injection phrases, and assigns a score plus a severity label.
5. Response policy: at a score of 50 or higher, the visitor sees a notice instead of the model's reply. The original reply is still saved so I can review it.
6. Log handling: every event is written to chat_log.txt, and higher risk events are copied to security_events.txt.
7. Structured storage: the same event is stored in logs/honey_ai.db so it can be queried later.
8. Analyst visibility: the Streamlit dashboard uses the stored data for metrics, daily counts, and recent event review.
9. Reporting: the report generator creates a plain text summary that can be saved with the rest of the project notes.

Risk Scoring Methodology

The current logic is intentionally lightweight. Each suspicious pattern adds 25 points, each pattern is counted once no matter how many times it appears, and the total is capped at 100. A prompt that matches four or more patterns still receives a score of 100. That makes the scoring easy to explain, easy to test, and easy to tune later if I want to expand the pattern list.

• Low: 0 to 24
• Medium: 25 to 49
• High: 50 to 74
• Critical: 75 to 100
• Security event logging threshold: prompts scoring 50 or higher are written to security_events.txt, and the visitor does not receive the model's reply

My first version matched exact phrases only. Live testing showed that adding one word to an attack got past it, so the current version lowercases the text, removes punctuation, collapses extra spaces, and matches close variants of each pattern. I then tested harmless questions, such as a password reset, to make sure the wider matching did not create false alarms.