Default Pipelines

Each builder installs its own set of controls

Neither named default contains the other. The library default covers paths, shell commands, egress, tool names, secrets, and patches; the runtime profile covers internal networks, agent velocity, and output sanitization.

The library default leaves output hooks to the host: it registers the composed pipeline and configures each control. The runtime profile returns input guards and an output pipeline, and the host installs both, then adds its policy-specific controls. An empty pipeline from GuardPipeline::new() or Default holds whatever guards the host adds.

A compiled HushSpec policy can produce yet another set. A guard’s catalog entry describes the control; the host’s registration path installs it, so read that path to know what runs. For a policy file, chio policy explain prints the set and order it compiles to. The HushSpec example team policy compiles to eight guards, with velocity second and internal-network beside egress-allowlist, a set neither builder produces:

chio policy explain hushspec-policies/team-policy.yaml

policy     hushspec-policies/team-policy.yaml  extends hushspec-policies/builtin-default.yaml
grants     read_file on server *       max_args_size 8192
           list_directory on server *  max_args_size 8192
           search_files on server *    max_args_size 8192
           sql on server *             max_args_size 8192
           export_to_csv on server *   max_args_size 8192, approval required
guards     1 forbidden-path
           2 velocity
           3 egress-allowlist
           4 internal-network
           5 mcp-tool
           6 secret-leak
           7 patch-integrity
           8 path-allowlist
output     1 hook
approvals  export_to_csv on every call

Seven guards run in a fixed order, and order decides which refusal you see

The library default registers its seven guards in one sequence and evaluates them in that sequence. The first denial ends evaluation, and an error counts as a denial.

for guard in &self.guards {
    match guard.evaluate(ctx) {
        Ok(decision) => {
            evidence.extend(decision.evidence);
            match decision.verdict {
                Verdict::Allow => continue,
                // … PendingApproval
                Verdict::Deny => {
                    // … record the denial
                    return Ok(GuardDecision::deny(evidence));
                }
            }
        }
        Err(e) => {
            // Fail closed: guard errors are treated as denials.
            // … record the error
            return Ok(GuardDecision::deny(evidence));
        }
    }
}

Each guard answers to a runtime name, such as forbidden-path. A denial reason, a metric label, and a GuardEvidence row all carry that name. For independent, total, stateless checks over the same immutable input, conjunction gives the same allow or deny result in any order; short-circuiting still changes which refusal and evidence you see. Stateful guards, timeouts, and failures need a stronger analysis.

A rate check can consume a token before a later guard denies, so reordering that pipeline changes future admission as well as this call’s evidence and cost. The builder registers a fixed sequence and never measures request cost or reorders checks. Choose another order from your workload and your guards’ semantics, then test it.

Read more in Pipelines & Composition, which owns the combination rules.

The runtime profile checks both sides of dispatch

default_runtime_guard_profile() returns a RuntimeGuardProfile that the standard runtime installs: three controls before dispatch and a post-invocation pipeline after it.

pub fn default_runtime_guard_profile() -> RuntimeGuardProfile {
    let mut post_invocation_pipeline = PostInvocationPipeline::new();
    post_invocation_pipeline.add(Box::new(SanitizerHook::new()));

    RuntimeGuardProfile {
        pre_invocation_guards: vec![
            Box::new(InternalNetworkGuard::new()),
            Box::new(AgentVelocityGuard::new(AgentVelocityConfig::default())),
            Box::new(AdvisoryPipeline::new(PromotionPolicy::new())),
        ],
        post_invocation_pipeline,
    }
}

Three controls an operator might expect to wire by hand arrive with it. InternalNetworkGuard (internal-network, on Network) prevents server-side request forgery. AgentVelocityGuard (agent-velocity, on Rate Limit) limits an agent’s rate across capabilities. ResponseSanitizationGuard runs through the post-invocation SanitizerHook, named output-sanitizer (Sanitization).

The AdvisoryPipeline (advisory-pipeline) is installed empty. The session-journal advisory guards that populate it, and any promotion rules, stay operator-wired; Advisory Signals covers PromotionPolicy.

Opt-in guards wait for the configuration they read

The full chio-guards catalog ships more than the two defaults install, and the rest stay operator-wired even with the runtime profile enabled. Each depends on something only the deployment can supply.

• Thresholds and tuning. Jailbreak and prompt-injection detection carry inference cost and false-positive risk that vary by deployment.
• History. Behavioral profiles read a receipt feed, and session-aware guards read a session journal that not every edge maintains.
• Connections and credentials. External adapters and data-layer guards reach a provider or a data store.
• The tool interface itself. Computer-use, code-execution, content-review, and memory-governance guards apply only where that interface exists.

Each guard’s requirement is listed under Opt-in guards in the installation reference.

A host extends or trims the default by registering guards itself

Start from the default and append controls that should run after its checks. Choose their order from dependency, state, and failure semantics as well as measured cost.

use chio_guards::{
    GuardPipeline, AgentVelocityGuard, AgentVelocityConfig,
    DataFlowGuard, DataFlowConfig,
};
let mut pipeline = GuardPipeline::default_pipeline();

// AgentVelocityGuard keeps its own in-memory rate buckets.
pipeline.add(Box::new(AgentVelocityGuard::new(
    AgentVelocityConfig::default(),
)));
// DataFlowGuard is session-aware and needs a journal handle.
pipeline.add(Box::new(DataFlowGuard::new(
    journal.clone(),
    DataFlowConfig::default(),
)));

// Custom guards last: refuse a refund above USD 50.00 (amounts in cents).
pipeline.add(Box::new(RefundCeilingGuard::new(5_000)));

kernel.add_guard(Box::new(pipeline));

The response side registers separately: add a PostInvocationPipeline on the kernel, as Sanitization shows. To trim instead, build the pipeline by hand; the kernel accepts a manually registered pipeline. Omit a default guard only when another control closes its interface, such as a network sandbox, an immutable filesystem, or the absence of a shell tool.

use chio_guards::{
    GuardPipeline, ForbiddenPathGuard, PathAllowlistGuard,
    McpToolGuard, SecretLeakGuard, PatchIntegrityGuard,
};

// A pipeline without ShellCommandGuard or EgressAllowlistGuard,
// for a deployment that has no shell or network surface to begin with.
let mut pipeline = GuardPipeline::new();
pipeline.add(Box::new(ForbiddenPathGuard::new()));
pipeline.add(Box::new(PathAllowlistGuard::new()));
pipeline.add(Box::new(McpToolGuard::new()));
pipeline.add(Box::new(SecretLeakGuard::new()));
pipeline.add(Box::new(PatchIntegrityGuard::new()));

kernel.add_guard(Box::new(pipeline));

Read more in Custom Guards, which covers authoring the guards you append.

Next: implement a guard of your own