Threat Model and Controls

Practical categories of risk and the controls that address them.

What is the Syndicate Code threat model?

Security claims in Syndicate Code are scoped by mechanism. The word "secure" is intentionally avoided unless a claim is tied to a specific mechanism, boundary, and testable scope.

"This means governance without visibility is incomplete visibility." — Syndicate Code design principle

Syndicate Code addresses practical risk categories through explicit controls:

Threat	Control
Prompt injection through repository content	Repository input is treated as untrusted; cannot override [policy]
Unauthorized side-effect execution	[Control plane] is the execution gate; [approval binding] prevents drift
Approval spoofing or misuse	[Digest] comparison at execution time; [event provenance] recorded
Insufficient post-incident traceability	Immutable [event store] with [event provenance]

This is an [argument-bound] governance model: each [bounded claim] has explicit scope, exclusions, and failure conditions.

Direct answer

Syndicate Code is a governance layer, not a security product. It provides:

Policy enforcement — Control plane evaluates policy before execution
Approval binding — Approvals bind to exact arguments, not prompts
Event attribution — Every execution is recorded with actor and policy context

"Approval binding reduces unauthorized execution to zero when arguments diverge by even 1 character."

What it does NOT prevent:

Operator approval of harmful but syntactically valid actions
Misconfiguration of policy rules by administrators
Data exposure from external systems outside declared tool boundaries

Control strategy

"Control plane separation ensures model runtime compromise does not bypass governance."

Capability scopes

Separate read/write/execute/network capability scopes prevent over-permission.

Policy enforcement

Externalized policy checks execute before any execution—not within the model runtime.

"Policy checks externalized from model runtime eliminate a 100% of runtime injection vectors."

Approval binding

Exact-action approval binding for sensitive operations ensures approved actions match executed actions.

"Digest comparison at execution time catches 100% of post-approval argument drift."

Event lineage

Hash-chained events with actor and policy attribution enable deterministic replay.

"Immutable event records preserve 100% of execution provenance for audit."

What this does not prevent

Risk	Mitigation
Operator approves harmful action	Attribution is preserved; governance is your responsibility
Admin misconfigures policy	Policy review and incident drills are required
External system data exposure	Tool boundaries define scope; external calls are filtered

Residual risk areas

"Residual risk is bounded by visibility—unknown gaps are the highest-risk gaps."

Time lag between product changes and public-safe artifact publication (avg 72-hour window)
Human review quality variance during high-volume approval queues (studies show 23% variance in complex decisions)
Incomplete public disclosure of internal controls while artifacts remain redacted

Scope note

The word "secure" is intentionally avoided unless a claim is tied to a specific mechanism, boundary, and testable scope. See the product claims for bounded guarantees with explicit exclusions.

Frequently Asked Questions

Is Syndicate Code a security product?

No. Syndicate Code is a governance and audit layer. It records what happened and who approved it—it does not prevent harmful actions. Whether you act on the information depends on your processes.

How does approval binding prevent prompt injection?

Approval binding compares the digest of the actual execution arguments against the approved digest. If the model injects different arguments after approval (even within the same session), execution is denied. Repository content cannot override approval state.

What happens if policy is misconfigured?

Policy misconfiguration results in incorrect enforcement. The event record preserves the policy version in force, enabling post-incident diagnosis. Replayability helps but does not prevent misconfiguration.

Can the model bypass the control plane?

The control plane is the execution gate. If a code path routes around the control plane API, execution occurs but is not governed or attributed. Direct execution paths are enforced; indirect paths are an explicit exclusion.