FCC Security Review¶
This page is deprecated in v1.3.10. See MIGRATION.md. Content moved to for-developers and for-architects.
Security posture reference for FCC v1.3.3 deployments. Use this document during procurement reviews, security questionnaires, and audit cycles. Paired with cost analysis and enterprise deployment.
Scope¶
This review covers:
- FCC framework (the
fccPython package) - Official Docker images (
docker/Dockerfile.*) - Official Helm chart (
charts/fcc/) - Official plugins shipped in-tree
It does not cover third-party plugins - those must be reviewed independently; see the "Plugin supply chain" section below.
Attack surface overview¶
flowchart TB
subgraph External
U["Users / Browsers"]
API_PROV["AI provider APIs"]
PLUG["Plugin packages<br/>(PyPI / internal)"]
end
subgraph Ingress
ING["Ingress / LB<br/>TLS 1.3"]
end
subgraph Cluster["Kubernetes cluster"]
FE["Frontend pod<br/>(read-only FS)"]
BE["Backend pod<br/>(fcc protocol ws-bridge)"]
ST["Streamlit pod"]
JP["Jupyter pod<br/>(optional, gated)"]
ES["ExternalSecrets<br/>controller"]
end
subgraph Data
VAULT["Secret store<br/>(Vault / AWS SM)"]
EVENTS["Event log store"]
end
U --> ING
ING --> FE
ING --> BE
ING --> ST
ING -.optional.-> JP
BE --> API_PROV
BE --> EVENTS
ES --> VAULT
ES -.injects.-> BE
PLUG -.loaded at start.-> BE
style External fill:#ffebee
style Cluster fill:#e8f5e9
style Data fill:#e3f2fd
Threat surfaces are numbered below and mapped to controls.
Threat model¶
| # | Threat | Surface | Severity |
|---|---|---|---|
| T1 | Arbitrary code execution via malicious plugin | Plugin loading | High |
| T2 | API-key exfiltration via logs or events | Observability | High |
| T3 | Prompt injection leading to data exfiltration | AI provider call path | High |
| T4 | Container escape / privilege escalation | Pod runtime | High |
| T5 | Cross-tenant data leakage via shared registry | Multi-tenant deploy | Medium |
| T6 | WebSocket bridge hijack (unauth'd clients) | Protocol layer | Medium |
| T7 | Supply-chain compromise of dependencies | PyPI / base images | Medium |
| T8 | DoS via runaway simulation | Resource controls | Low-Medium |
| T9 | Audit-log tampering | Event store | Medium |
| T10 | Insecure defaults in local-dev docker-compose | Dev environment | Low |
Controls inventory¶
C1. Plugin loading discipline (T1, T7)¶
- Plugins are discovered via
fcc.pluginsPython entry points only -- no dynamic import paths taken from user input. - Each plugin declares a
plugin_typefrom the 11 fixed types; FCC routes calls based on type, so a plugin cannot claim capabilities beyond its declared interface. - Recommended hardening:
- Pin plugin versions in
requirements.txt/pyproject.toml. - Sign wheels with Sigstore / cosign for internal plugins.
- Run
pip-auditin CI.
C2. Secret management (T2)¶
charts/fcc/ships with anExternalSecretsintegration pattern; secrets are injected via environment variables at pod start.- Never commit
.envfiles to the repo..gitignorealready excludes them. - The event bus has no redaction by default; wrap API responses before
publishing events that carry sensitive context. Use
EventSerializer.with_redaction(paths=[...]). - Constitution registry supports a
secret_scopehard-stop tier for personas that must not see production credentials.
C3. Prompt-injection mitigation (T3)¶
- Every call emits a
LLM_CALLevent with the rendered prompt; you can inspect suspicious inputs post-hoc. - Use the
ComplianceAuditorto flag personas whoseconstraintsblock doesn't cover data-handling rules. - Recommend deploying a content-filter plugin (custom, not shipped) that intercepts outbound tokens for policy checks.
C4. Pod security (T4, T10)¶
Defaults in charts/fcc/:
| Setting | Default | Rationale |
|---|---|---|
runAsNonRoot |
true |
No root processes in pods |
runAsUser |
10001 |
Fixed, non-privileged UID |
allowPrivilegeEscalation |
false |
- |
capabilities.drop |
["ALL"] |
Least-privilege capabilities |
readOnlyRootFilesystem |
true on frontend; false on backend |
Backend writes traces to /var/lib/fcc |
seccompProfile |
RuntimeDefault |
- |
For high-sensitivity environments, set readOnlyRootFilesystem: true on the
backend and mount a dedicated PVC at /var/lib/fcc.
C5. Network policies (T5, T6)¶
Ship-with-chart network policies:
- Frontend -> Backend: allowed on port 8080 (HTTP + WS upgrade)
- Backend -> AI provider egress: restricted by
egress.cidrallowlist - Streamlit -> Backend: allowed on port 8080
- Default deny for all other pod-to-pod traffic
For multi-tenant deployments, use a namespace-per-tenant pattern and extend the default-deny policy to cross-namespace traffic.
C6. TLS and ingress hardening (T6)¶
- Ingress terminates TLS 1.3; older versions explicitly disabled in the chart.
- HSTS enabled with
includeSubDomains; preload. - WebSocket bridge requires the same origin (CORS enforced on the HTTP upgrade handshake).
- For zero-trust environments, front the ingress with an authenticating proxy (OIDC-aware).
C7. Authentication and authorization (T5, T6)¶
- FCC framework is auth-agnostic; authz is expected at the ingress layer.
- WebSocket bridge supports bearer-token auth via
FCC_WS_BEARER_TOKENenv. - The protocol bridge does not perform tenant isolation; separate deployments per tenant if cross-leakage is a concern.
C8. Audit logging (T9)¶
- Event bus persists every state transition (81 event types).
CompliancePipelinegenerates tamper-evident audit reports.- Recommend forwarding events to a write-once store (e.g., AWS S3 Object Lock, Azure Immutable Blob).
- For SOC 2 / HIPAA, enable at-rest encryption on the event store and integrity-check via hash chains.
C9. Resource limits (T8)¶
Ship-with-chart defaults:
The simulation engine enforces max_steps and max_duration_ms per
scenario; override per tenant if needed.
C10. Supply-chain hygiene (T7)¶
Dockerfileuses pinned base images; rebuild weekly to pull security patches.pyproject.tomluses>=bounds but CI runs with a pinnedconstraints.txt.- GHCR images are signed via cosign starting v1.1.1.
- SBOM generated via
make sbom(Syft); stored underpublications/_output/.
Compliance mapping¶
| Control | SOC 2 CC | ISO 27001 | HIPAA Security Rule |
|---|---|---|---|
| C1 Plugin loading | CC6.1 Logical Access | A.12.1 Operational security | 164.308(a)(4) Info access management |
| C2 Secret management | CC6.1, CC6.7 | A.9.2 User access mgmt, A.10.1 Cryptography | 164.312(a)(1) Access control |
| C3 Prompt injection | CC7.2 System monitoring | A.12.6 Technical vulnerability mgmt | 164.308(a)(1)(ii)(B) Risk management |
| C4 Pod security | CC6.6 | A.13.1 Network security | 164.312(c)(1) Integrity |
| C5 Network policies | CC6.6 | A.13.1 | 164.312(e)(1) Transmission security |
| C6 TLS/ingress | CC6.7 | A.13.2 Information transfer | 164.312(e)(1) |
| C7 AuthN/Z | CC6.1 | A.9.4 System access control | 164.312(a)(2)(i) Unique user ID |
| C8 Audit logging | CC7.2, CC7.3 | A.12.4 Logging and monitoring | 164.312(b) Audit controls |
| C9 Resource limits | A1.2 Availability | A.12.1.3 Capacity mgmt | - |
| C10 Supply chain | CC8.1 Change mgmt | A.14.2 Security in development | 164.308(a)(8) Evaluation |
See also src/fcc/data/compliance/eu_ai_act_requirements.yaml for EU AI
Act mapping and src/fcc/data/compliance/nist_ai_rmf_mapping.yaml for the
NIST AI RMF crosswalk.
Vulnerability disclosure¶
Report security issues privately:
- Email: security@informationcollective.example (replace with real contact)
- GitHub Security Advisories: https://github.com/rollingthunderfourtytwo-afk/l2_fcc_agent_team_ext/security/advisories
- Expected response: 72 hours for acknowledgment, 30 days for triage
- Safe-harbor policy: good-faith research is welcome; do not exfiltrate data or disrupt production systems
Security checklist (pre-production)¶
- All plugins reviewed and pinned
-
ExternalSecretswired; no raw secrets in env files - Pod security context applied in every namespace
- Network policies enforced; default deny
- TLS 1.3 only on ingress; HSTS enabled
- WebSocket bridge authenticated (bearer or mTLS)
- Event store is write-once / integrity-checked
- Resource limits set on every pod
- Weekly base-image rebuilds scheduled
- SBOM archived per release
-
pip-auditand image scanners green in CI - Incident runbook attached to on-call rotation
Related resources¶
- Cost analysis -- TCO and provider mix
- Enterprise deployment -- deployment topologies
- Governance and compliance -- quality gates and audit workflow
- AI compliance -- EU AI Act / NIST AI RMF coverage
- Integration guide -- CI/CD + toolchain
charts/fcc/values.yaml-- all security-relevant defaultssrc/fcc/compliance/-- auditor, evidence graphs, pipelines