Product documentation
What Syndicate Code Is
Syndicate Code is a governed AI code execution control plane that evaluates policy, checkpoints approvals, issues permits, and records append-only evidence before side effects execute.
Direct answer
Syndicate Code is a governed AI code execution control plane. Its full governed pipeline has six stages: five control decisions before the side effect executes, then execution plus evidence once the action is allowed to run.
The important point is not that Syndicate Code helps only after the fact. The important point is that the control plane evaluates the action before the side effect happens. Depending on trust tier and active policy, that checkpoint may require human approval or may resolve automatically, but no governed side effect proceeds without a control-plane outcome.
Syndicate Code is therefore not a chat wrapper, not a runtime sandbox, and not an observability-only dashboard. It is a governed AI code execution control plane for engineering teams that need attributable approvals and append-only evidence when AI-generated actions can change code, invoke tools, or touch external systems.
What happens before a side effect executes?
| Stage | What happens | Why it exists |
|---|---|---|
| 1. Proposal | The model or operator proposes an action. | Creates a candidate action that can be evaluated instead of executed immediately. |
| 2. Canonicalization | Action arguments are normalized into a deterministic representation. | Prevents approvals from binding to ambiguous or presentation-level variations. |
| 3. Policy evaluation | The control plane checks trust tier, capability rules, and active policy. | Ensures governance happens outside the model runtime. |
| 4. Checkpoint decision | The system decides whether the action can proceed automatically or requires human approval. | Separates low-risk flows from actions that require explicit operator review. |
| 5. Permit issuance | The approved action receives a bounded permit tied to the normalized arguments. | Prevents execution from drifting away from what policy and approval authorized. |
| 6. Execution plus evidence | The action runs only after the earlier control decisions succeed, and the system appends evidence about who approved what and what executed. | Produces attributable replayable lineage rather than best-effort logs. |
What Syndicate Code is
Syndicate Code is a CLI/TUI-first product built around a local authoritative control plane embedded in the syndicate binary.
The control plane is authoritative for:
- policy decisions about whether an action is allowed
- argument normalization before approval and execution
- checkpoint and approval handling
- permit issuance for allowed execution
- append-only event recording and audit verification
The practical result is that the model proposes and the control plane decides.
Guarantees and limitations
| Category | What Syndicate Code guarantees | Scope and limitation |
|---|---|---|
| Policy-before-execution | Governed actions are evaluated against active policy before execution. | Applies to actions inside the managed execution path only. Indirect or bypass paths are outside scope. |
| Approval binding | Approvals bind to normalized action arguments rather than loose prompt intent. | Protects the governed execution path. It does not claim universal protection against all bypass or side-channel execution. |
| Attributable evidence | The system records append-only audit events for approvals, denials, and execution outcomes. | Evidence covers significant events in the governed path, not every possible system event outside that path. |
| Trust-tier capability control | Tool visibility and invocability can change by trust tier and policy. | Effective only where the control plane is authoritative. It is not kernel-level isolation. |
| Secret filtering | Known secret patterns can be detected before outbound model or tool requests are sent. | Detection is pattern-based and does not claim perfect coverage for novel formats. |
| Runner restrictions | L1 runner restrictions can block shell binary execution and open network access in defined modes. | This is not a claim of universal sandboxing or system-wide containment. |
Approvals and audit chain
Approvals are not generic yes or no signals attached to a conversation. They are tied to the normalized action that is about to run.
That means Syndicate Code is designed to answer questions such as:
- who approved the exact action that ran?
- what arguments were approved?
- which trust tier and policy version were active?
- what actually executed?
- can the evidence chain still be verified?
The append-only local ledger is stored in the workspace-local Syndicate state and can be verified with syndicate audit verify.
This is why the product matters in regulated or incident-sensitive environments: it creates attributable evidence for the action path itself, not just a post-hoc narrative about what might have happened.
Why this category exists
AI coding adoption is moving faster than governance controls in many organizations:
- Gravitee's 2026 survey reports 88% of organizations observed a confirmed or suspected AI-agent incident.
- Only 47.1% of deployed agents were reported as actively monitored or secured.
- OWASP's 2025 LLM Top 10 still ranks prompt injection as a top category of unresolved risk.
Syndicate Code exists for the gap between AI proposal and real-world side effect. It is built for teams that need governance and attribution after proposal, before execution.
What Syndicate Code does not claim
This page does not claim:
- universal security
- kernel-level isolation
- complete mediation of all indirect execution paths
- perfect secret detection
- deterministic model behavior
- complete replay for every possible event outside the governed path
Syndicate Code is a governance and audit layer, not a universal security product. Its guarantees are bounded by scope, exclusions, and explicit failure modes.
Operating profile
Syndicate Code governance is explicit and countable:
- 4 trust tiers materially alter approval and capability behavior.
- 6 stages determine whether a side effect reaches execution.
- 3 core architectural guarantees define the product: policy-before-execution, argument-bound approvals, and attributable event lineage.
Those are architectural guarantees inside enforced execution paths, not universal guarantees across every path a developer workstation could take.
Proof links
If you want evidence rather than category language, start here:
- Approval argument match proof
- Replay lineage envelope proof
- What Syndicate Code does not claim
- Why audit trails need attribution