Product
An approval-gated AI code execution control plane.
Syndicate Code defines explicit, bounded claims about enforcement, approvals, and attribution. Every claim has defined boundaries, exclusions, and failure conditions.
System architecture
The control plane is the authoritative system.
The model runtime proposes actions. The control plane authorizes or denies those actions according to policy, capability scope, and approval state.
This is not a chat interface. The user interface is an interaction surface. The control plane is the authoritative system for:
- policy decisions
- approvals
- action normalization
- execution attribution
- replayable event history
Each of these is governed by explicit claims with defined boundaries. See the claim system below.
Claim system
6 claimsTier 1 claims with enforcement layers, scope, and evidence.
Claim
Policy is enforced in the control plane before tool execution.
Enforced at
Control plane: Server.evaluateSessionPolicy(), Server.executeApprovedAction()
Applies to
Direct execution paths routed through the control plane API
Excludes
Indirect execution paths (subprocesses outside tool boundaries); offline or degraded mode (bootstrapEvaluator)
Failure mode
If execution bypasses control plane API or spawns subprocess outside tool boundary, policy is not enforced.
policy-enforcement-gate
Claim
Approvals bind to exact normalized action arguments.
Enforced at
Control plane: ApprovalTokenManager, ConstantTimeCompare
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 via digest comparison.
approval-argument-match-event
Claim
Events record actor identity, session context, and policy version with hash chain.
Enforced at
Event store: EventStore.Append(), EventRecorder
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.go; 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.
replay-lineage-envelope
Claim
Tool visibility and invocability are filtered by trust tier.
Enforced at
Policy engine + Runner: Engine.ValidateToolAccess(), 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.
Claim
Known secret patterns are detected and filtered before model egress.
Enforced at
Secrets policy executor: sanitizeToolInputForExternalEgress()
Applies to
Tool I/O to external model providers via sanitization boundary
Excludes
Novel secret formats not matching regex; encoded or obfuscated secrets; secrets in intermediate processing steps; contextual inference without direct transmission
Failure mode
If secret format is not matched, path bypasses sanitization, or encoding evades detection, secret may reach model provider.
Claim
L1 runner rejects shell binary execution and open network access.
Enforced at
L1 Runner: L1Runner.Execute(), isShellBinary(), NetworkPolicy check
Applies to
Direct command execution in L1 runner context; hardcoded shell binary list: sh, bash, zsh, fish, cmd, powershell, pwsh
Excludes
Indirect subprocess execution from allowed tools; interpreted scripts without shell binary names; kernel-level isolation (seccomp/cgroup); path-based shell evasion
Failure mode
If interpreter or script bypasses binary check, or subprocess spawns from allowed tool, shell-like behavior may occur.
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 approval.
- Universal security: no "secure by default" without mechanism and explicit scope.
- Complete mediation: indirect execution paths are outside policy enforcement scope.
- Comprehensive secret detection: detection is regex-based; novel formats may not be matched.
- Kernel-level isolation: shell/network restrictions are runner-level; kernel isolation not claimed.
- Complete replay: event attribution is scoped to defined significant transitions.
Claim → Evidence pathway
Each claim links directly to its proof record and source code.
Every claim above includes a direct link to its proof record and source code. The pathway is: claim → proof record → source artifact.
Pathway structure
- Claim block — defines what the system claims, with scope, exclusions, and failure mode bounded in the same unit
- Proof record link — direct link to the specific proof record (e.g.,
/proof/policy-enforcement-gate) that substantiates this claim - Source code link — direct link to the enforcing code in the product repository (GitHub)
Proof record status meanings
- Implemented: claim is enforced and evidence is published
- Partial: claim is enforced but evidence is illustrative or redacted
- Planned: claim structure is defined but public evidence not yet published
Proof records with amber warning indicate claims that are structurally defined but lack published proof records. These are explicitly noted to prevent composite inference.