Only the latest 1.x minor line receives security patches. All other branches are provided as-is.

Please report security vulnerabilities privately to:

tamer.atesyakar@bk.ru

Do not open a public GitHub issue for suspected vulnerabilities and do not disclose details publicly until they have been acknowledged and addressed. We aim to acknowledge reports within two business days and to ship a patch within fourteen days for critical issues.

When reporting, please include:

• A description of the vulnerability.
• Steps to reproduce (a minimal proof-of-concept is ideal).
• The affected version / commit hash.
• Any known mitigations.

Reports may be encrypted with the maintainer's public PGP key on request.

Implicit Interaction Intelligence is built around an unusual constraint: the system has to build a deep behavioural model of its user without ever retaining the content of anything they actually typed. Privacy is therefore enforced at the architecture layer, not merely the configuration layer:

1. Raw user text is never persisted. The database schema in i3/diary/store.py has no column capable of holding a user message, an AI response, or a conversation turn. The only strings stored are topic keywords (three per exchange, extracted by TF-IDF) and an aggregate session summary generated from metadata only.
2. Embeddings are encrypted at rest. The user-state and baseline embeddings produced by the TCN encoder are serialised via NumPy and wrapped by ModelEncryptor (Fernet AES-128-CBC + HMAC-SHA256) before being written to disk.
3. PII is sanitised before any cloud call. PrivacySanitizer applies ten regex patterns (email, US/UK/international phone, SSN, credit card, IP, physical address, date of birth, URL) to every string that is about to leave the device. The sanitised result is what ends up in the Claude API request body.
4. Only aggregated metadata is sent to the cloud. The Anthropic prompt builder (i3/cloud/prompt_builder.py) encodes the current adaptation vector and topic history as instructions, not user text. See the privacy auditor (PrivacyAuditor.audit_request) for the automated compliance check.
5. Defence-in-depth auditing. PrivacyAuditor.audit_database walks every text column of every SQLite table, samples up to 100 rows, and flags anything that looks like natural-language prose or contains PII. This runs as part of make security-check.

The system is scoped to defend against the threats enumerated below. Threats outside this table (e.g., supply-chain attacks on PyTorch wheels, kernel-level memory scraping) are acknowledged but out of scope.

The audit was conducted in four passes over the repository:

1. Static inventory — grep/rg sweep for torch.load, yaml.load, pickle.*, subprocess, os.system, eval(, exec(, hardcoded sk-ant-/password=/token=/secret=, and allow_origins=["*"].
2. Per-file manual review — each hit was read in context to distinguish genuine issues from false positives.
3. Fix application — all critical and high findings were fixed in-place.
4. Post-fix verification — a second grep pass confirmed that the surface area had been reduced.

• L-1 — yaml.safe_load already in use. i3/config.py uses yaml.safe_load. No occurrences of yaml.load were found.
• L-2 — No pickle.loads in repository. grep for pickle.load and pickle.loads returned no matches.
• L-3 — No subprocess / os.system. Repository is free of direct shell invocations in production code.
• L-4 — SQL queries already parameterised. Every CRUD method in i3/diary/store.py and i3/user_model/store.py uses ? placeholders; no concatenation or f-string SQL was found.
• L-5 — No hardcoded secrets. grep for known secret prefixes returned only .env.example, which contains a placeholder.
• L-6 — Static file mount order. StaticFiles is mounted last in server/app.py so API and WebSocket routes take precedence, and its request body is subject to the same middleware stack.
• L-7 — SLM generation is already bounded. The generation loop in i3/slm/generate.py iterates strictly range(max_new_tokens).

The following recommendations go beyond what is enforced in code. None of these are required for the demo; they are the next steps before a production rollout.

1. Authenticate WebSocket clients. The current build accepts any user_id that matches the regex; no session token, JWT, or cookie is required. In production, prefix the WebSocket URL with a signed token (e.g., an HS256 JWT bound to the user_id) and validate it in the connect method before accepting the socket.
2. Use a distributed rate limiter. The in-memory sliding-window limiter in server/middleware.py is per-process. Behind a multi-worker uvicorn or a Kubernetes deployment, replace it with Redis (e.g., redis-py's INCR + EXPIRE) or an API gateway feature (Envoy, nginx limit_req).
3. Put the server behind TLS. HSTS is only emitted on HTTPS requests. Terminate TLS at a reverse proxy (nginx, envoy, caddy) and add trust_forwarded_for = True on the request state so the rate limiter sees the real client IP.
4. Rotate the Fernet key on a schedule. Call ModelEncryptor.rotate_to(new_key) in a nightly cron, re-wrap the embedding blobs in place, and then flip I3_ENCRYPTION_KEY.
5. Enable audit logging. Configure structured JSON logging (structlog or python-json-logger) with a field whitelist so that PII and secrets cannot accidentally enter logs.
6. Scan dependencies continuously. Add make security-check to CI (GitHub Actions) and fail the build on any high finding from bandit, pip-audit, or safety.
7. Sign model checkpoints. For the trusted-input torch.load code path in i3/slm/train.py, produce a SHA-256 of the checkpoint at training time, store it next to the .pt file, and verify it before loading.
8. Disable /api/demo/reset and /api/demo/seed in production. These endpoints are intended for the live demo only; gate them behind a config flag or remove them in the production build.
9. Constrain uvicorn workers. uvicorn --limit-concurrency 100 and --timeout-keep-alive 5 cap total connections; add a process manager (systemd, supervisord) with Restart=on-failure.
10. Monitor PrivacyAuditor.audit_database results. Run it on every deploy and again in a nightly cron; alert on any violation.

We use the following tools to monitor dependency security:

• pip-audit — scans installed Python packages for known CVEs from the PyPI advisory database.
• safety — cross-checks against the Safety CLI vulnerability database.
• bandit — static analysis for the most common insecure Python patterns (hardcoded passwords, weak hashes, shell injection, etc.).

Run them all with:

make security-check

Under the hood this executes:

bandit -r i3/ server/ -ll     # line-level severity: low and above
pip-audit                      # dependency CVE scan
safety check                   # second-source CVE scan

The [tool.poetry.group.security.dependencies] section of pyproject.toml pins bandit>=1.7, pip-audit>=2.6, and safety>=3.0.

• Fernet symmetric encryption (cryptography library) for user models at rest. Fernet = AES-128-CBC + HMAC-SHA256 + random IV, which gives authenticated encryption without a custom construction.
• TLS 1.2+ for all cloud API calls via httpx (which delegates to the system OpenSSL). Certificate validation is enabled by default.
• No custom crypto. All cryptographic operations go through the cryptography package. No hand-rolled hashing, padding, or encryption is used anywhere in the codebase.
• Keys are 256 bits of random entropy generated by Fernet.generate_key() (URL-safe base64 encoding of os.urandom(32)).

To rotate the encryption key without downtime:

from i3.privacy.encryption import ModelEncryptor
encryptor = ModelEncryptor()
encryptor.initialize()

new_key = ModelEncryptor.generate_key()
mf = encryptor.rotate_to(new_key)

# Re-encrypt in place:
for row in db.iter_rows():
    row.baseline_embedding = mf.rotate(row.baseline_embedding)

# Finally update I3_ENCRYPTION_KEY in your secret store.

• Raw user text is never persisted to disk. The diary schema has no column capable of holding it.
• PII is sanitised via 10+ regex patterns in PrivacySanitizer before any string leaves the device.
• Embeddings are encrypted at rest with Fernet (see above).
• Session summaries are generated from aggregated metadata only (message counts, engagement averages, topic keywords, dominant emotion). The cloud LLM never sees individual messages.
• PrivacyAuditor.audit_database is a database-level scanner that walks every text column and flags prose-like content or PII; PrivacyAuditor.audit_request is a payload-level scanner that is run immediately before any cloud call.

• Max inbound frame size: 64 KiB. Frames larger than this cause a WebSocket close 1009.
• Max message text length: 8 KiB. Chat messages larger than this are rejected with WebSocket close 1009.
• Max messages per session: 1000. Exceeding this closes the socket with code 1008.
• Max session duration: 1 hour wall-clock. On expiry the socket is closed with code 1008 and the pipeline cleans up the session.
• User ID validation: ^[a-zA-Z0-9_-]{1,64}$. Non-conforming IDs are rejected before the socket is accepted.
• Rate limiting: 600 messages per minute per user_id, via a shared in-memory sliding-window limiter. Exceeding the limit sends an {"type":"error","code":429} frame and closes the socket.
• Duplicate-connection eviction: If a new socket arrives for an already-connected user_id, the earlier socket is closed with code 1001 ("going away").
• Fail-closed teardown: Any JSON parse error, schema violation, or handler exception closes the socket immediately and triggers pipeline.end_session in a finally block.

• CORS origins: configurable via configs/default.yaml or the I3_CORS_ORIGINS env var. Wildcard * is only accepted if I3_ALLOW_CORS_WILDCARD=1 is also set, otherwise it falls back to localhost:8000.
• Rate limiting: 60 requests per minute per client IP on /api/* paths (excluding /api/health).
• Request size limit: 1 MiB on the Content-Length header; larger requests receive a 413.
• Security headers injected on every response:
  • X-Content-Type-Options: nosniff
  • X-Frame-Options: DENY
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy: camera=(), microphone=(), geolocation=(), ...
  • Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; ... frame-ancestors 'none'
  • Strict-Transport-Security: max-age=63072000; includeSubDomains (HTTPS only)
  • Cache-Control: no-store for /api/*
• Exception handlers: Any unhandled exception, validation error, or HTTPException returns a sanitised JSON body. Stack traces are written to the server log, never to the response.
• Loopback-only by default: server.host defaults to 127.0.0.1; operators must explicitly set I3_HOST=0.0.0.0 to expose the server on all interfaces.

• Inference-time torch.load: every call passes weights_only=True. This disables the pickle path inside torch.load and forbids arbitrary code execution during deserialisation.
• Training-time torch.load: the one code path that still passes weights_only=False is SLMTrainer.load_checkpoint, which is required because the optimiser state dict cannot be loaded under weights_only=True. This code path is documented as trusted-input only; do not point it at checkpoints from untrusted sources.
• Checkpoint signing (recommended, not yet implemented): compute a SHA-256 of every saved checkpoint and verify it on load.

• Logs use Python's standard logging module at module level.
• No secrets are ever logged. The Anthropic API key is redacted via _redact_api_key before it enters any log record.
• No PII is ever logged. PrivacySanitizer.sanitize removes PII before any text could be passed to a log call, and PrivacyAuditor.audit_database provides an after-the-fact scan.
• No stack traces are returned to clients. The FastAPI exception handlers in server/app.py always return a sanitised JSON body.
• Recommendation: switch to structured JSON logging in production so that downstream tooling can field-filter logs and so that a log search for baseline_embedding or message_text cannot match a stringified Python object.

This code was developed for an interview project and underwent a formal security review as documented in this file. The audit covered input validation, authentication boundaries, cryptography, secrets management, transport security, denial-of-service mitigations, and dependency hygiene. All critical and high findings have been fixed in-place; medium findings have been either fixed or documented with a mitigation note; low / informational findings are noted for future iterations.

Last audit: see git log -- SECURITY.md for the most recent review date.