Syndicate Code
Systems fail when their guarantees are implicit.
Syndicate Code defines explicit, bounded, and falsifiable claims about system behavior. The model runtime is not the authority; the control plane is.
System guarantees
The product is a governed execution layer between intent and side effects.
Policy is enforced in the control plane before tool execution.(via policy-outside-runtime)
Enforced at: control plane before any side effect
Applies to: direct execution paths routed through the control plane API
Excludes: indirect execution paths (subprocesses outside tool boundaries), offline or degraded mode where bootstrapEvaluator is used
Failure mode: if execution bypasses control plane API or spawns subprocess outside tool boundary, policy is not enforced
Approvals bind to exact normalized action arguments.(via approval-argument-binding)
Enforced at: control plane before execution via SHA-256 digest comparison
Applies to: normalized tool call arguments and execution context captured at approval time
Excludes: tool behavior differences despite identical arguments, environment state not in execution context, tool implementation changes between approval and execution
Failure mode: if arguments are modified after approval or execution context differs, approval is cancelled
Events record actor identity, session context, and policy version with hash chain.(via event-attribution-envelope)
Enforced at: event store via EventRecorder interface
Applies to: state transitions processed through EventRecorder within a session
Excludes: events from external systems or side processes, non-significant transitions not defined in event types, storage layer tampering, cross-session ordering
Failure mode: if a code path bypasses EventRecorder or a transition is added without event type, state occurs without attribution
Tool visibility and invocability are filtered by trust tier.(via capability-separation-trust-tier)
Enforced at: policy engine ValidateToolAccess() and runner filterTools()
Applies to: tool registry visibility and invocation per trust tier profile
Excludes: indirect tool-to-tool invocation where permitted tool invokes restricted capability, prompt injection manipulation, trust tier assignment manipulation
Failure mode: if permitted tool indirectly invokes restricted capability or tier assignment is manipulated, capability separation is bypassed
Known secret patterns are detected and filtered before model egress.(via secret-filtering-egress)
Enforced at: secrets PolicyExecutor and sanitizeToolInputForExternalEgress()
Applies to: tool I/O to external model providers via sanitization boundary
Excludes: novel secret formats not matching regex patterns, encoded or obfuscated secrets, secrets in intermediate processing steps, contextual inference without direct secret transmission, Class C summarize action which returns partial information
Failure mode: if secret format is not matched, path bypasses sanitization, or encoding evades detection, secret may reach model provider
L1 runner rejects shell binary execution and open network access.(via l1-shell-restriction)
Enforced at: L1Runner.Execute() with isShellBinary() and NetworkPolicy check
Applies to: direct command execution in L1 runner context
Excludes: indirect subprocess execution from allowed tools, interpreted scripts without shell binary names, kernel-level isolation (seccomp/cgroup), path-based shell evasion, network access via file triggers
Failure mode: if interpreter or script bypasses binary check, or subprocess spawns from allowed tool, shell-like behavior may occur
Approval enforcement
Naive assistant tooling often logs output but not authority.
Claim
Approvals bind to exact actions rather than broad prompts.
Status
partial
Mechanism
Control plane validates normalized payload digest, capability scope, and approval state before execution.
Source Ref
product-repo:internal/controlplane/approvals/*
Artifact IDs
approval-binding-evidence
Approval records include a normalized action payload hash and capability scope. Execution requires a matching approval hash.
Event attribution
Replayability enables post-incident reconstruction.
Example event envelope
{
"event_id": "evt_01HTP5H8EYAX6KQ8M8RNGF8D90",
"run_id": "run_01HTP5EFVCP0GDCY4EEWJ42MCM",
"actor": "user:[email protected]",
"action": "tool.exec.bash",
"input_hash": "sha256:81d7...",
"policy_decision": "approved",
"approval_id": "apr_01HTP5G7Q3Y3Q70G1BT22K8HZE",
"timestamp": "2026-03-19T04:22:17Z"
}Events record actor identity, session context, policy version, and a hash link to the previous event.
Threats this system addresses
Threats are explicit and tied to controls.
- Repository as untrusted input: repository content is treated as evidence, not instruction. (design principle)
- Approval scope: approvals bind to exact arguments, not broad prompts, preventing post-hoc semantic drift. (via approval-argument-binding)
- Attribution: every significant transition records who approved what under which policy version. (via event-attribution-envelope)
What this system does not claim
Constraints are design choices, not product gaps.
- Complete autonomous operation: no claim of human-out-of-loop for side-effecting actions without explicit approval.
- Generic security: no "secure by default" without mechanism and explicit scope definition.
- Evidence-based only: no maturity claims beyond shipped artifacts in changelog and proof sections.
How to read this system
Every claim on this site is bounded and falsifiable.
Each claim above is rendered with its scope, exclusions, and failure modes in the same block. This is not accident—it ensures interpretations are constrained at first contact.
If a claim's exclusion is not visible in the same block, the claim is not fully stated.
- Claims are bounded statements of Tier 1 behavior.
- Scope defines where the claim applies.
- Exclusions define where the claim does not apply— they are part of the definition, not caveats.
- Failure modes describe how the claim can be violated.