Threat model summary
A digest of Kaizen's threat model: the trust boundaries, what sits behind each, and the control on the edge. The full model is maintained in the repository and goes considerably deeper.
Trace how untrusted input becomes a bounded request while identity, authority, effects, and audit stay server-owned.
Assets
| Asset | Why it matters |
|---|---|
| Member identity and roles | Everything else derives from it |
| Document ACL scope | The whole product promise is "only what you can see" |
| Conversation content | Private and shared chat history |
| Credentials and connector grants | Reach into external systems |
| Model access | Cost, and the ability to act |
| Audit evidence | Reviewability after the fact |
Boundary 1 — Inbound transport
Threat. A request that forges identity, replays a session, or reaches an operator route without the role.
Control. Identity comes only from the validated platform envelope. There is one construction chokepoint for a principal; no route, body, parameter, tool argument, or queue message can supply one. Operator routes re-check the admin role server-side, fail-closed. Missing envelope or missing email deny with a bounded reason.
Boundary 2 — Retrieval and per-user scoping
Threat. A query that returns, counts, or hints at content the requester cannot see.
Control. Access predicates live inside the SQL query. Every branch consumes the authorization relation before emitting output, and raw candidates never reach application code. Snippets, facets, counts, and anchors derive only from the authorized projection. Opening an anchor re-authorizes.
Documented residual. HNSW can inspect index rows before relational filters fully apply. Kaizen does not claim prefiltering; each indexed branch joins the full relation and exposes only survivors, and strict exact mode is available as both oracle and rollback.
Exported document images. Exported content is member-authored text that can
name pictures, which gives that text both a read path and a potential fetch
path. Both are closed. A reference resolves only through the owner-scoped
document and run-artifact reads, with the principal taken from the forwarded
platform envelope, so a foreign or unknown reference is indistinguishable from
a missing one. Remote and data: targets are dropped before resolution, so the
API performs no outbound request on exported content's behalf. Bytes must sniff
as a supported image type within the per-image ceiling, and the per-export
reference count is bounded. Anything unresolved renders as its description
text; the reason never reaches the exported file.
Boundary 3 — The model
Threat. Prompt injection from connector content, uploads, tool results, or a remote agent, aiming to exfiltrate data or trigger an action.
Control. Structural, not detective. Untrusted content arrives as evidence and cannot grant a tool, widen a scope, raise a capability ceiling, approve an action, supply an identity, or alter the authority bundle. A successful injection changes what the model says; it cannot change what the backend permits.
Model-authored inline canvas Markdown is treated as presentation, not authority. The backend bounds and types the item, retains it only with the conversation, and the browser renders React elements without executing embedded HTML or scripts. The canvas tool cannot create a Library object, invoke an external effect, or substitute for the guarded artifact writers.
Residual. A convincing injected answer is still a wrong answer. Citation discipline and grounding reduce it; they do not eliminate it. This is why citations are clickable.
An external credential recipient is also a deliberate trust decision. Kaizen shows the signed destination, defaults schemas to the same API origin, and scrubs exact values plus common wire encodings from returned content. A malicious recipient can still transform a value into a novel covert encoding that a generic response filter cannot prove came from the credential. Keep external capabilities scoped by egress and enable only reviewed destinations; the scrubber is defense in depth, not a substitute for destination trust.
Boundary 4 — The agent runtime
Threat. A compromised or misbehaving controller acts beyond the member, bypasses shared limits, changes its admission, or settles a run more than once.
Control. Each run receives one immutable admission from a static registry. Controllers can order typed requests only. The shared host owns model, tool, compaction, checkpoint, steering, budget, and lifecycle effects.
The runtime holds no data, secrets, identity, policy, credentials, or tool executors. Every consequential action calls the backend. The backend rechecks the authority bundle and current permissions. Python owns usage and terminal settlement.
Each Pi run carries a random per-run capability that authorizes its model proxy and callback requests while the run is registered. Because it is a bearer credential, it is never used as an identifier. A run with no member turn of its own, such as a prompt-chain step or a prompt-cache warm, is named by a domain-separated SHA-256 digest of the capability, and the sidecar rejects a run request that names no turn rather than substituting the capability. Model-call usage audit, agent-run and tool audit records, journal events, artifact checkpoints, persisted turns, tool idempotency keys and logs therefore never carry it.
Residual. The capability still travels between the backend and the sidecar inside the run manifest and each step snapshot, which bind every step to its run. A run without a durable session also uses it as its runtime session key inside those bodies, and both sides check that binding. Those bodies stay on the authenticated internal channel, and only their digests are persisted. A run without a durable session writes no runtime journal.
Reviewed shared-pipeline extensions run inside the trusted sidecar process. They are statically imported product code, identified by exact source-owned descriptors, and activated as one immutable set. The loader validates the complete candidate in temporary state. A duplicate order, incompatible host range, unsupported registration, or unknown reference prevents publication. Manifest order cannot change execution order.
Extensions receive credential-free projections of the admitted messages, approved sampling fields, tool-call arguments, bounded tool results, and opaque run metadata. The restricted Pi API does not provide identity, credentials, provider routes or headers, models, budgets, sessions, journals, UI, shell execution, direct messages, terminal publication, or direct tool execution. Disallowed calls through that API raise a typed boundary failure. Mutable hook outputs stay private until every handler completes and the host validates the complete draft.
An extension-declared tool must match the exact name and parameter schema in Python's frozen authorized tool snapshot. The sidecar discards the extension executor and keeps the authenticated Python callback. This preserves current permission checks and the secretless package-runner boundary.
Residual. The projection boundary is not a sandbox for shared extension source. Reviewed code and its dependencies execute in the trusted sidecar process. Source review, dependency review, and the static descriptor list are therefore part of the trust root. Member-authored package extensions are not eligible for this host and remain isolated from it.
Boundary 5 — The model gateway
Threat. Direct provider access, budget bypass, capability misuse, or raw provider errors leaking into member-visible surfaces.
Control. One gateway owns routing, policy, budgets, effort, retries, and
normalization. No component holds a model credential. A capability mismatch is
refused before the call. Pi reasoning parameters require exact authenticated
engine metadata, an answer-capacity reserve, and a Python-authored manifest
binding; member input and model names cannot select them. Provider errors are
normalized into safe categories. A missing or blank authorization value, or a
cookie without a platform access token, is rejected locally as
platform_auth_unavailable; Kaizen does not send an unauthenticated request and
substitute an upstream-specific error contract.
Boundary 6 — Code execution
Threat. Member code reading another member's data, reaching the host, or egressing freely.
Control. A hardened deployment-selected worker runtime, single-tenant leases, workspace keyed to actor and conversation, room resources mounted read-only outside the writable workspace, egress proxied and scoped, and package installation brokered. Standard Kubernetes runtime is supported; operators can select gVisor for stronger syscall isolation. Failure to prove the configured boundary is terminal — never a retry at a weaker boundary.
Boundary 7 — Third-party package code
Threat. A malicious or compromised package reaching credentials.
Control. Packaged code runs in a separate, secretless process. There is nothing sensitive in that process to reach, so containment does not depend on the package behaving.
Trusted Artifact renderer packs
Threat. Product-specific visualization code could execute without operator intent, drift between API and web images, alter validated data, or disclose an Artifact from the browser.
Control. Version 1 admits only reviewed first-party packs installed through signed, exact-digest OCI artifacts and immutable derived API/web images. Packs are default-off. The API imports only an exactly enabled distribution, requires the plugin identity and claims to match the byte-hashed install receipt, and gives validators detached inputs that they cannot rewrite. The browser requires the API and web receipt SHA-256 to match, selects only an exact renderer type, payload type, and payload version, and requires a current API admission bound to the exact stored content SHA-256 and pack identity. This read-time validation prevents content stored while the pack was disabled from bypassing its backend validator after enablement. The browser verifies every declared asset and runs the module in a fresh opaque scripts-only frame with bounded private-channel traffic. The banner text is a producer-authored marking, not a classification assigned or independently certified by Kaizen. The host renders that exact named top-level security banner in sticky parent chrome outside that frame, so loading, WebGL content, renderer failure, and fallback cannot remove or replace it. Pack code may render only subordinate portion detail.
Documented residual. Iframe CSP blocks ordinary fetch and subresource loads,
but current Chromium cannot provide complete egress denial for arbitrary
script-capable DOM/WebGL code: a child can issue a self-navigation request, and
WebRTC can emit STUN traffic outside connect-src. The frame is defense in
depth, not the trust root. The parent broker verifies the receipt declaration,
size, media type, and SHA-256 of each asset it supplies. The CSP permits the
nonce-bearing bootstrap, blob modules and workers, and WebAssembly compilation,
including runtime-generated byte sources; it does not restrict all executable
bytes to those supplied by the broker. JavaScript eval() and new Function()
remain denied. Reviewed signed first-party code is the trust root, and
supply-chain review must reject all renderer network behavior. Before release,
normal-operation UAT must demonstrate zero renderer-originated requests. If untrusted
runtime packs are ever required, they need a different execution boundary such
as a host-owned declarative renderer or a separately network-isolated browser
process.
Boundary 8 — Unattended execution
Threat. Scheduled work acquiring authority its owner never granted; a forged workload, stale revision, stolen bearer value, redelivered queue item, replayed proof, or expired lease executing; a partial platform being mistaken for ready; or an ambiguous write replaying.
Control. Core binds member consent to the exact registered client, workload role and revision, task revision, resources, limits, policy, and expiry. A projected assertion establishes only workload identity. Short-lived run and effect capabilities are sender-constrained to an in-memory P-256 key and checked with a fresh DPoP proof, fixed audience, current activation epoch, immutable authority deadline, atomic claim, and monotonic fence. Queue and database records contain opaque references only. Resource guards consume an exact effect once; ambiguous outcomes are terminal and never replayed.
Core keeps one durable capability-signing and nonce authority per cluster and projects it to every authority-bearing Core/Ray replica. Per-node authority is forbidden because a request routed to another replica would otherwise fail or split the trust domain. The private material is never projected into Kaizen. FIPS deployments require an externally generated P-256 key with validated provider provenance; an algorithm name alone is not treated as compliance.
Kaizen accepts one complete server-derived readiness decision and applies it to every entry and effect boundary. Missing capability families, unhealthy attestation, stale reports, incompatible model or dataset guards, revocation, or dependency loss closes new work immediately. No path falls back to local policy, workload identity alone, stored member snapshots, bearer credentials, or a weaker attestation profile outside the registered acceptable set.
Boundary 9 — Collaboration
Threat. A collaborator borrowing the owner's authority, or a removed member retaining access through a stale cursor or card.
Control. Three separate identities — collaboration scope, conversation stream, actor scope. Every turn runs as its initiating participant. Membership and policy are re-checked before publication. Removal clears retained state from the client, and an old cursor cannot regain access.
Boundary 10 — A2A
Threat. An external agent asserting identity, approval, or capability.
Control. A card is a description, not permission. Inbound payloads are untrusted content and cannot select a member, role, or approval. Execution stops at the member approval gate. Proof of concept, intended for isolated deployments.
Out-of-band assumptions
Stated, not enforced by Kaizen:
- The platform authenticates correctly and forwards a trustworthy envelope.
- Network policy restricts what can reach the deployment's services.
- Connected systems apply their own permissions correctly to per-member reads.
- Operators do not place secrets in non-secret configuration.
- Backups are protected to the same standard as the live database.
Image-owned tokenizer integrity
The API-family image used by API, background-worker, and document-worker
contains the exact cl100k_base tokenizer payload used by Kaizen. A repository test derives its
cache key and expected SHA-256 from the pinned tiktoken implementation and
fails if the image constants drift. The build retries and verifies the download
before dropping privileges, makes the cache read-only, and proves the non-root
runtime can load it with build networking disabled. Every API-family process
then rechecks the exact payload before application code starts.
TIKTOKEN_CACHE_DIR is not an operator extension point. A changed path,
missing file, or digest mismatch exits with code 78 rather than making a
runtime download. This closes an accidental runtime-egress path; it does not
make an untrusted image safe. Operators must still install the exact reviewed
release image and must not repair a running container by copying in cache
bytes or mounting a writable replacement.
Known gaps, stated plainly
- Delegated Tasks depend on live platform readiness. Kaizen does not expose new work when exact unattended approval, credential brokering, dual-ledger model admission, protected resource guards, attestation, or another required platform component is unavailable.
- IT-issued standing approval is not available. Durable task-owner approvals are exact one-shot tool decisions, not IT-role authorization.
- Package-declared MCP tool descriptors are recorded but not executed. They are forward compatibility, not a live capability; separately installed platform MCP Guard tools remain subject to deployment, agent, and current member authority.
- A2A's shared secret is a proof-of-concept control, not a substitute for network policy.
- Prompt injection is contained, not prevented.
Demo Builder's direct SDK tools narrow the control-plane threat surface rather than exposing the SDK generically. Identity and workroom come only from the validated forwarded envelope. The model cannot supply endpoints, credentials, method names, delete actions, or arbitrary bodies. Result allowlists omit live endpoints, raw logs, host details, and provider payloads; transport and tool timeouts bound calls. The residual risk after an apply timeout is an ambiguous external effect, so the workflow must inspect current exact state before retry. The adapter does not delegate to the operator CLI. It reuses only in-process SDK seeding primitives with the request-scoped client, avoiding CLI token caches, environment credentials, subprocess authority, and human-output parsing. Extension endpoints remain internal derived state and never cross the model-facing result projection.