CFAM

The architecture overview. The diagram shows the full pipeline: the agent proposes an action, it enters only through the GovernedToolGateway, is checked against the signed capability manifest, then cleared (or stopped) by Policy → Sentry → Isolation, with every decision written to the Audit Ledger. Outcomes are ALLOW (executes), ESCALATE (held for a human), or BLOCK (denied).

The interactive heart of the demo. With CFAM vs without runs the same agent plan governed and ungoverned side-by-side (the incident happens without, is prevented with). Emergency stop trips the kill switch. Governed agent loop runs a model's tool-use loop through the gateway (scripted by default; live LLM when enabled). Industry scenario packs run finance / healthcare / support missions against their own signed manifests. Gate-by-gate steps a single action through the stack, and Transaction rollback shows a saga unwinding a partially-executed plan.

Propose a single action (tool, payload, endpoint, cost, recipient) and see the decision, the risk score, and every gate. Shows the manifest in force. The Outbound DLP card classifies a payload and redacts / blocks / flags disallowed data classes (PII, secrets) before egress.

Author a capability manifest with no code; on save it's Ed25519-signed and instantly enforced, then test an action against it. The Policy-as-code lifecycle card composes a candidate from base + environment overrides, scores it against a labeled corpus, and refuses promotion on a safety regression — with per-environment versioning and rollback.

“Don't trust our test data — use your own.” Paste JSONL test cases (or generate them with any AI via the prompt) and CFAM reports attack recall, false-positive rate, a confusion matrix, blocks-by-layer, and an explicit list of what it missed. Numbers are measured on your data, never asserted.

The tamper-evident record of every decision (append-only, SHA-256 hash-chained). Prove it's tamper-evident lets you edit an entry and watch verify() catch the broken chain. SIEM export & alerting streams decisions as CEF and raises routed alerts. External anchoring shows how a WORM/transparency log catches truncation a local chain can't. Download signed report saves an Ed25519-signed session report anyone can verify with the public key.

Live governance telemetry from the ledger — decision mix and rates, a decision-stream sparkline, where actions are stopped, top blocked tools, and ledger integrity. Gate performance measures latency (p50/p95/p99) and throughput in this environment (measured, not asserted).

Maps CFAM's controls to the OWASP LLM Top 10 and NIST AI RMF with honest done / partial / out-of-scope labels and live evidence counted from the ledger. A control map, not a certification.

Copy-pasteable snippets to wire CFAM into your agent: gate your tools, author a signed manifest, and wrap an MCP or LangChain tool surface. The snippets are kept API-accurate by tests.

The human-in-the-loop reviewer console. Escalated actions are held, a notification fires, and an approver (role-gated) approves or denies; if no one acts within the SLA it auto-denies (fails closed). Every outcome is audited.

Plain-language answers with the full system network diagram — how CFAM sits between the agent and its actions, how it installs, and how it works with any model.

It isn't a network proxy. It sits at the tool-invocation boundary: instead of the real tools, your agent is handed a GovernedToolGateway and can only act through it. Every proposed action runs Policy → Sentry → Isolation → Ledger before any side effect — and if any layer says no, the real tool is never called. The one rule: the gateway must be the agent's only path to side effects.

CFAM is a small Python package plus an optional FastAPI service, packaged as a container and deployed once per customer on your own infrastructure. You author a signed capability manifest, register your tools through the gateway (or wrap an existing MCP / LangChain tool surface with the adapters), point it at your OIDC identity provider, and run it next to your agent. Ledger goes to durable storage. Full steps are in the deployment docs.

It governs actions, not the model, so it's provider-agnostic. The model reasons and proposes tool calls; CFAM decides whether each call executes. Wire it via function-calling, an MCP wrapper, or a LangChain tool wrapper. Switching models changes nothing about your policy. Honest limit: CFAM stops the agent from doing something harmful — it isn't a content filter for what the model says.

No. The governance path is deliberately deterministic and explainable — no ML, no second LLM. The Policy Engine is an exact allow-list check; the Sentry is a transparent multi-signal risk model where every firing signal carries a weight and a human-readable reason. A rules-based detector will miss novel phrasings, so the Sentry is defense-in-depth on top of the hard policy boundary, never a replacement for it.

The per-task contract: which tools, endpoints, cost ceiling, and time window an agent is allowed. It's Ed25519-signed, so the authority can't be silently edited — every layer verifies the signature before enforcing it. That turns "this agent may only email the customer domain" into a cryptographically anchored fact.

The ledger is append-only and hash-chained: each record commits to the previous one, so any edit, deletion, or reorder breaks the chain. The head is signed to catch truncation of recent entries, and you can verify the whole chain offline at any time with python -m cfam.verify, independent of the running service.

Code-execution tools run in a separate process with real OS resource limits (CPU, memory, process count, file size), a stripped environment, an isolated temp dir, and a hard timeout — genuine containment of CPU/memory/filesystem blast radius. Honest scope: full network-egress isolation needs OS namespaces (deny egress at the container boundary today); the production target is gVisor / Firecracker micro-VMs.

Usually no — you re-point your tool layer. If you expose tools via MCP or LangChain, wrap them with the adapters and your agent barely changes; otherwise you route calls through gateway.invoke(...) instead of calling tools directly. The work is "make the gateway the only door," not "rebuild the agent."

Three outcomes: allow (executes), block (denied; the agent gets a structured refusal it can reason about), and escalate (held in the approval queue for a human). An authorized approver releases or denies it, and that decision is itself recorded. Blast-radius ceilings also cap cumulative spend or action count so many individually-allowed actions can't add up to harm.

CFAM is an OIDC relying party: it validates your IdP's tokens (issuer, audience, signature) and maps your IAM groups to CFAM roles — operator, approver, auditor, read-only. It owns no user accounts, pins token algorithms (no alg=none), and requires a real expiry. SAML can be added behind the same interface.

Only if you give it an ungoverned route to a side effect. The guarantee is structural: the agent holds the gateway and nothing else, so a denied action can't fall through to the real tool. Your job is to ensure there's no second door — a stray API key, a tool registered outside the gateway, raw network access. That invariant is worth pen-testing.

It fails closed at the action boundary: no gateway, no governed actions. We treat "agent silently acts ungoverned" as the unacceptable outcome, so the design biases toward denying rather than letting actions through unchecked.

It's an honest, working pre-1.0 build, not vaporware: policy engine, signed manifest, multi-signal Sentry, OS-level code isolation, hash-chained ledger, mandatory gateway, MCP/LangChain adapters, human-in-the-loop approvals, blast-radius ceilings, and OIDC are implemented and tested. The road to production is stronger isolation (micro-VMs), richer detection, durable/operational hardening, and packaging. We'll tell you exactly what's GA vs. roadmap for your use case rather than blanket-claim "enterprise-ready."