What Syndicate Code Doesn't Claim (And Why That Matters)

Published: 2026-03-21

Every governance tool has boundaries. A firewall does not prevent social engineering. An access control system does not encrypt data at rest. Antivirus software does not patch vulnerable dependencies.

Syndicate Code has explicit boundaries. This document describes what Syndicate Code does not claim—and why that clarity is part of the governance model, not a limitation of it.

What Syndicate Code does not prevent

Prompt injection attacks

Syndicate Code does not detect or prevent prompt injection attacks. Prompt injection occurs when adversarial instructions are embedded in content that an AI model processes—README files, code comments, documentation, external web content.

Syndicate Code treats all repository content as untrusted evidence (an architectural principle from the threat model). But it does not filter or sanitize content before it reaches the model. The injection happens at the model layer; Syndicate Code's governance controls operate at the execution layer.

What Syndicate Code does: If an AI model with manipulated context proposes an action, that action still requires human approval through Syndicate Code before execution. Syndicate Code does not prevent the injection; it ensures that actions resulting from injection are not executed without authorization.

Social engineering of human approvers

Syndicate Code cannot prevent a human from approving an action they do not understand. The approval workflow requires human attention; Syndicate Code enforces that approvals are tied to specific arguments, but it cannot evaluate whether the approver's judgment is sound.

What Syndicate Code does: Syndicate Code provides transparency—the TUI displays exact arguments before approval. It records the approver's identity for every approval. But the judgment call is the human's.

Kernel-level isolation

Syndicate Code's L1 and L2 sandbox runners enforce command allowlists and working directory restrictions. However, Syndicate Code does not claim kernel-level isolation via seccomp, cgroups, or similar mechanisms.

What Syndicate Code does: The L1 runner restricts shell execution to a predefined allowlist (go test, go vet, go fmt, golangci-lint, env, sleep). The L2 runner allows symbolic command execution with path confinement. These are enforcement mechanisms at the tool runner level, not kernel isolation.

Universal secret detection

Syndicate Code's secret detection uses regex-based pattern matching for known secret formats. Novel secret formats—new API key patterns, custom credential schemes, proprietary token formats—may not be detected.

What Syndicate Code does: Syndicate Code scans content before model prompt inclusion and before event log persistence. Detected secrets are redacted using a sensitivity class system (Class A secrets are denied; Class B secrets are masked). Detection effectiveness depends on pattern coverage.

Actions that bypass the control plane

Syndicate Code's governance scope is limited to actions that route through the Syndicate Code control plane. Direct execution paths—actions that invoke system utilities directly without going through the tool registry—are outside enforcement scope.

What Syndicate Code does: All structured tools in Syndicate Code's tool registry route through the control plane. The architectural invariant that all requests must flow UI → Control Plane → Agent → Control Plane → Tool Runner is enforced for registered tools. Direct system calls that bypass the tool registry are not governed.

Offline or degraded mode

When the Syndicate Code control plane is unavailable, governance controls are not enforced. The system uses a bootstrap evaluator in degraded mode, which bypasses policy enforcement.

What Syndicate Code does: This is a documented operational exclusion. The event store records that the system was in degraded mode, but events during degraded mode do not have standard governance attribution. Operators should avoid degraded mode in production environments.

Actions by operators with elevated trust tiers

Trust tiers in Syndicate Code materially alter system behavior—but they do not eliminate governance. At higher trust tiers (tier2, tier3), more actions are auto-approved. At tier3, no approvals are required for most actions.

What Syndicate Code does: Trust tiers are a configuration choice made by operators. Higher trust tiers mean fewer approval prompts and faster execution. The tradeoff is documented: at tier3, the operator accepts execution without per-action approval for most operations.

What Syndicate Code does not integrate with

External AI coding tools

Syndicate Code is a standalone tool with its own AI planner. It connects directly to AI model providers (Anthropic, OpenAI, Google). Syndicate Code does not currently integrate with external AI coding tools such as Cursor, Windsurf, or GitHub Copilot.

What Syndicate Code does: Syndicate Code provides its own governed coding experience. The AI is part of the Syndicate Code system; governance controls apply to all AI-initiated actions within Syndicate Code.

CI/CD pipelines without explicit configuration

Syndicate Code's API supports integration with external systems, but CI/CD pipelines are not automatically governed by Syndicate Code unless explicitly configured.

What Syndicate Code does: Syndicate Code provides a REST API for session management, approval workflows, and event retrieval. Integration with CI/CD systems requires explicit configuration and is context-dependent.

Why explicit exclusions matter

Governance theater occurs when a system claims to provide protection it does not actually provide. A tool that claims to prevent prompt injection but only logs attempted actions is governance theater.

Syndicate Code's explicit exclusions are part of the governance model. They define the actual protection surface—so operators understand what is covered and what is not.

This matters for two reasons:

1. Operators can make informed decisions: When you understand what is not covered, you can implement compensating controls for those cases.
2. Auditors can evaluate actual risk: A compliance audit that assumes Syndicate Code covers prompt injection will reach the wrong conclusions. Explicit exclusions prevent this.

FAQ

Why doesn't Syndicate Code prevent prompt injection?

Prompt injection is a fundamental vulnerability in how LLMs process instructions. It occurs at the model input layer, before any governance system can act on it. Syndicate Code's approach is to ensure that even if injection succeeds, the resulting actions require human approval before execution.

Can Syndicate Code work in environments where the control plane might be unavailable?

Syndicate Code is designed for environments where the control plane is consistently available. If the control plane becomes unavailable, governance is suspended and events are not recorded with standard attribution. For high-availability requirements, operators should ensure control plane availability.

Does Syndicate Code replace security tools?

No. Syndicate Code is an audit and governance layer. It does not replace:

• Secret scanning tools (like git-secrets or TruffleHog)
• Static analysis tools
• Runtime security monitors
• Network segmentation
• Input validation systems

Syndicate Code addresses one specific risk vector: unauthorized AI-initiated actions. A complete security posture requires multiple layers.

What happens if an operator approves a harmful action?

Syndicate Code records the approval with the operator's identity. The action proceeds. Syndicate Code provides attribution—it does not prevent authorized actions. If an operator approves a harmful action, that is an operational and organizational concern, not a product defect.

How do I know what Syndicate Code actually covers?

The claims page (/product) documents Syndicate Code's guarantees with explicit scope and exclusions. Every claim in Syndicate Code documentation follows the pattern: what it guarantees, what scope it applies to, what it excludes, and what failure modes exist.