Understanding Trust Tiers in Syndicate Code

Published: 2026-03-21

Trust tiers in Syndicate Code are not labels. They are operational configurations that materially alter system behavior.

Each trust tier defines which actions require explicit human approval, which are auto-approved, and which capabilities are available to the AI. The tiers exist because different contexts warrant different levels of oversight. A local development session on a personal machine has different risk characteristics than a production-adjacent deployment on a shared infrastructure.

The four tiers

tier0: Untrusted External

tier0 is the most restrictive tier. It treats all AI activity as untrusted and requires explicit approval for most operations.

Typical use case: Evaluating new AI tools, working in high-security repositories, or when first deploying Syndicate Code.

Characteristics:

• Read operations require approval in some configurations
• Write and execute operations always require approval
• No plugin access
• Maximum output size: 64KB
• Maximum loop depth: 1
• Timeout: 30 seconds per turn

tier1: Internal Low Risk

tier1 is the standard operating tier for most development work. It balances productivity against governance.

Typical use case: Day-to-day development in trusted repositories where the operator wants governance coverage without per-action prompting for low-risk operations.

Characteristics:

• Read operations: auto-approved
• Write operations: approval required
• Execute operations: approval required
• Plugin access: limited
• Maximum output size: 256KB
• Maximum loop depth: 3
• Timeout: 120 seconds per turn

tier2: Production Adjacent

tier2 is for operators who have established workflow patterns and want reduced friction for routine operations.

Typical use case: Experienced operators working in well-understood codebases with established patterns.

Characteristics:

• Read operations: auto-approved
• Write operations: auto-approved for defined patterns
• Execute operations: approval required for non-standard commands
• Plugin access: standard
• Maximum output size: 512KB
• Maximum loop depth: 5
• Timeout: 300 seconds per turn

tier3: Restricted

tier3 is the most autonomous tier. It provides minimal friction but requires operators who understand the risk tradeoffs.

Typical use case: Running well-tested scripts, automated workflows with pre-authorized operations, or operators who have explicitly accepted the risk of reduced oversight.

Characteristics:

• Read operations: auto-approved
• Write operations: auto-approved
• Execute operations: auto-approved for allowlisted commands
• Plugin access: disabled
• Maximum output size: 1MB
• Maximum loop depth: 10
• Timeout: 600 seconds per turn

What "approval required" means

When an action requires approval at the current trust tier, the following flow occurs:

1. The AI proposes an action with specific arguments
2. The control plane checks the trust tier configuration
3. If approval is required, the action enters the approval queue
4. The human approver reviews the exact arguments in the TUI
5. If approved, the action proceeds with those exact arguments
6. If the AI modifies arguments before execution, a new approval is required

Approval is a gate, not a notification. The action does not execute until the human approves.

What "auto-approved" means

When an action is auto-approved at the current trust tier, the control plane evaluates the action against policy and executes it without requiring human input.

Auto-approval does not mean no governance. The action is still recorded in the event store with full attribution. The difference is temporal: instead of waiting for human approval before execution, the action executes immediately and is recorded for audit purposes.

Trust tier enforcement is mandatory

Trust tiers are not advisory. The SYSTEM_INVARIANTS.md document specifies:

"Trust tiers must materially alter system behavior." "Trust tiers as metadata only" is a forbidden pattern.

This means that in code, the trust tier configuration directly controls:

• Which tools are visible to the AI
• Which tools can be invoked without approval
• How arguments are processed before execution
• What event attribution is recorded

How to choose a trust tier

Choosing a trust tier is an operational risk decision. Consider:

1. Repository sensitivity: Public repositories warrant different oversight than private repositories with sensitive code.

2. Operator experience: New operators should start at tier0 or tier1 until they understand how Syndicate Code's governance model works.

3. Action type: Write and execute operations warrant more oversight than read operations, regardless of tier.

4. Session context: A session debugging a complex issue might warrant a higher tier temporarily, then revert to a lower tier.

Trust tiers can be changed during a session. The change takes effect immediately and is recorded in the event log.

What each tier does not change

Trust tiers affect approval requirements and capability limits. They do not affect:

• The control plane's authority: All actions route through the control plane regardless of tier.
• Approval binding: If an action requires approval, it is still bound to exact arguments regardless of tier.
• Event recording: All actions are recorded in the event store regardless of tier.
• The digest comparison: If arguments change after approval, execution is denied regardless of tier.

FAQ

Can I create custom trust tiers?

Syndicate Code's default trust tier profiles are defined in the policy engine. Custom tier configurations can be defined by modifying the policy profile. The policy engine supports custom tier definitions with per-tier approval rules, capability restrictions, and execution limits.

What happens if I approve an action at tier3 and the AI modifies it?

Even at tier3, if the AI modifies the arguments of an approved action, execution is denied and a new approval is required. Approval binding applies regardless of trust tier.

Does moving to a higher tier reduce security?

Moving to a higher trust tier (more autonomy) reduces the friction of the approval workflow. It does not eliminate governance—the event store still records all actions with attribution. However, it does reduce the opportunity for human review before execution. The risk tradeoff is explicit: faster execution at the cost of reduced per-action oversight.

Can I set different tiers for different repositories?

Trust tier is a per-session configuration. Different sessions can use different trust tiers. For repository-specific governance, operators can configure sessions for high-sensitivity repositories to use lower tiers while using higher tiers for routine work.

Does tier3 completely eliminate approvals?

No. tier3 eliminates per-action approvals for many operation types, but:

• Actions outside the defined allowlist still require approval
• Plugins are disabled at tier3
• If arguments change after approval, execution is denied regardless
• The event store records all actions regardless of tier

How does the trust tier affect secret detection?

Secret detection operates independently of trust tier. Regardless of tier, Syndicate Code scans content for secrets before model prompt inclusion and before event log persistence. Trust tier affects approval requirements, not secret detection.