Robust Canary Constructions

• The paper presents robust canary mechanisms that decouple mutable state from diagnostic probes to prevent identity drift and related failure modes.
• These constructions stabilize identity in safety-critical agents, dynamically generate PA-backed canaries for memory defense, and optimize canaries to reduce interference in privacy auditing.
• Empirical and formal evaluations demonstrate zero identity drift, minimal performance overhead, and improved canary detectability across diverse security and privacy settings.

Robust canary constructions are mechanisms that preserve the diagnostic role of a “canary” under adversarial, safety-critical, or statistically confounded conditions. In the cited literature, the term spans at least three distinct technical settings: identity-stable canary deployment for safety-critical embodied agents, PA-based stack canaries for memory-corruption defense, and optimized canaries for one-run privacy auditing in machine learning. In each case, the underlying problem is that a naive canary mechanism can fail for structural reasons: the deployed identity can drift during progressive rollout, a fixed stack canary can be disclosed or brute-forced, and multiple privacy-auditing canaries can interfere with one another. The resulting constructions—ICAN-Deploy (Qin et al., 27 May 2026), PCan (Liljestrand et al., 2019), and IBIS (Dagréou et al., 26 May 2026)—address those failure modes by redesigning what is held fixed, what is varied, and what is verified.

1. Conceptual scope and failure modes

Across the three settings, a canary is a deliberately inserted probe whose integrity or detectability is meant to reveal an undesirable condition. In mainstream software deployment, canary deployment routes a fraction of traffic to a new version, monitors metrics, and rolls back on regression; the issue identified for safety-critical embodied agents is that mainstream controllers such as Argo Rollouts, Spinnaker, and Flagger change the deployed system’s cryptographic identity during the canary window (Qin et al., 27 May 2026). In memory safety, a stack canary is placed between vulnerable local buffers and the return address so that an overflow must overwrite the canary before return metadata; the cited work argues that conventional stack canaries are fragile because they are fixed during a program run, their reference value is stored in memory, and a single canary per frame does not protect local variables (Liljestrand et al., 2019). In privacy auditing, canaries are points whose inclusion or exclusion in training must be detected by a membership inference attack; the one-run setting is weakened because canaries can interfere with one another, making individual membership effects harder to separate (Dagréou et al., 26 May 2026).

These failure modes differ operationally, but they share a common structure. A canary loses robustness when it becomes entangled with mutable state that should not define identity, when it is stored as a reusable secret, or when its signal is confounded by correlated probes. This suggests that robust canary constructions are characterized less by the mere presence of a canary than by control over the dependency structure around it.

2. Identity-stable canary deployment for embodied agents

ICAN-Deploy addresses a specific incompatibility between standard progressive delivery and certification for persistent embodied agents. The concern is that identity drift breaks the claim that “the agent you certified is still the agent you have,” which in turn makes certificates, regulatory filings, and audit trails tied to that identity ambiguous (Qin et al., 27 May 2026). The construction is designed for safety-critical embodied agents, including LLM-driven robots, where stable identity is part of the trust boundary.

The core design move is a type-level separation between capability names and capability versions. The paper defines the frozen capability name set as

$\mathbf{N} = \{n_1, n_2, \ldots, n_k\},$

the active version map as

$\mathbf{V}: \mathbf{N} \to \mathit{semver},$

and the provisional version map as

$\mathbf{V}': \mathbf{N} \to \mathit{semver}.$

Only $\mathbf{N}$ is hashed into identity; $\mathbf{V}$ and $\mathbf{V}'$ are mutable runtime state and are not hashed into identity. The identity is given as

$identity = H\big(m_{\mathrm{prelude} \,\Vert\, h_{\mathrm{env} \,\Vert\, h_{\mathrm{policy} \,\Vert\, h_{\mathrm{registry} \,\Vert\, h_{\mathrm{persona} \,\Vert\, v_{\mathrm{rt}\big)$

with $H$ specified as SHA-256, $h_{\mathrm{registry}}$ defined over registered capability names, lexicographically sorted, and the remaining manifest inputs described as frozen.

The rollout protocol is an eight-state machine with seven transition families:

1. pending → validating
2. validating → shadow_running
3. shadow_running → shadow_passed
4. shadow_passed → canary_running
5. canary_running → canary_promoted
6. canary_promoted → promoted
7. any canary state → rolled_back

These transitions are grouped into pure bookkeeping, provisional writes to $\mathbf{V}'$, and an atomic flip that writes $\mathbf{V}: \mathbf{N} \to \mathit{semver},$0 and clears $\mathbf{V}: \mathbf{N} \to \mathit{semver},$1 in one critical section guarded by asyncio.Lock. The explicit invariant is

$\mathbf{V}: \mathbf{N} \to \mathit{semver},$2

for any sequence of allowed pipeline transitions. The paper’s version-and-name envelope anchors identity to the frozen name set plus other stable manifest fields, while version changes remain outside the hashed identity envelope. Within that envelope, a system certified once at identity-creation time can ship arbitrary capability evolution under that same certification (Qin et al., 27 May 2026).

3. Formal and empirical verification of deployment invariance

The formal statement in ICAN-Deploy is given as the property of identity invariance under canary: if $\mathbf{V}: \mathbf{N} \to \mathit{semver},$3 is a persistent embodied agent with identity manifest $\mathbf{V}: \mathbf{N} \to \mathit{semver},$4 and identity hash $\mathbf{V}: \mathbf{N} \to \mathit{semver},$5, then for any sequence of allowed pipeline transitions, the hash remains unchanged (Qin et al., 27 May 2026). The proof is by induction on transition count. The base case is immediate from construction; the inductive step relies on the fact that each transition writes only to $\mathbf{V}: \mathbf{N} \to \mathit{semver},$6, $\mathbf{V}: \mathbf{N} \to \mathit{semver},$7, the audit log, or job-store metadata, none of which are components of $\mathbf{V}: \mathbf{N} \to \mathit{semver},$8. A structural lemma identifies the implementation reason the invariant holds: _compute_identity_hash consumes only the six frozen manifest fields, and ecm_registry_hash hashes capability names only, not (name, version) pairs.

The paper uses three verification layers. The closed-form proof establishes the mathematical invariant. An AST lint parses EvolutionPipeline.run and rejects writes to the manifest fields m_prompt, h_env, h_policy, h_registry, h_persona, and v_rt, making the check structural rather than behavioral. A TLA+ specification models the seven pipeline transitions plus three failure branches and checks four invariants: IdentityInvariant, StateInvariant, VInvariant, and VpInvariant. The spec also includes an explicit UNCHANGED <<manifest>> clause in the atomic promote action.

Empirical validation is reported on a Franka Panda 7-DOF arm in MuJoCo using a runtime governance bridge based on AEROS. The experiments include $\mathbf{V}: \mathbf{N} \to \mathit{semver},$9 canary cycles for ICAN-Deploy, a matched $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$0 strawman run, 1,708 integration tests in the full suite, and 10,000 fuzzer-seeded runs for additional identity checks (Qin et al., 27 May 2026). The reported result is zero identity drift across 100 canary cycles and 400 logged transitions, with one unique identity hash and zero drift events. Entry latency is reported with mean 1.7 ms and 95% BCa CI $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$1 ms; for validator+shadow, $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$2 is 3.05 ms and $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$3 is 4.06 ms. By contrast, a feature-flagged strawman that folds versions into the identity manifest shows identity drift in $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$4 cycles, producing distinct hashes at pre-canary, post-provisional-flip, and post-promotion stages.

The paper also states a critical limitation: identity invariance is not behavioral invariance. Capability-name changes, persona edits, and policy-file edits are treated as separate re-keying events rather than canary operations, and behavioral safety still depends on the validator, contract layer, and runtime governance. The deployment scope is validated on a Franka Panda in MuJoCo; generalization to ROS 2 or AUTOSAR-like environments is argued rather than demonstrated (Qin et al., 27 May 2026).

4. PA-based robust stack canaries

PCan redesigns stack canaries so that they are not fixed secrets stored in memory but dynamically generated, function- and call-specific values backed by ARMv8.3-A Pointer Authentication (Liljestrand et al., 2019). The requirements stated for a better scheme are: $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$5

$\mathbf{V}': \mathbf{N} \to \mathit{semver}.$6

$\mathbf{V}': \mathbf{N} \to \mathit{semver}.$7

The attacker model is a user-space adversary exploiting a stack-buffer overflow, possibly with stack-buffer over-reads and repeated restarts or forking to brute-force canaries. The scheme does not defend against arbitrary memory read/write access, and it does not consider higher-privilege adversaries such as kernel attackers (Liljestrand et al., 2019).

PCan relies on Pointer Authentication operations pacia / autia, pacda / autda, and pacga. A key property used in the design is that if authentication fails, the pointer is corrupted so that later use causes a fault. The paper notes that ordinary PA return-address protection such as -msign-return-address is insufficient on its own because PA is vulnerable to reuse attacks when the same key and modifier are reused.

The canary-generation modifier is defined using the least-significant 48 bits of SP and a 16-bit function identifier, making canaries function-dependent and call-dependent. The first canary $\mathbf{V}': \mathbf{N} \to \mathit{semver}.$8 is defined as

$\mathbf{V}': \mathbf{N} \to \mathit{semver}.$9

and subsequent canaries are chained as PA-signed pointers to the previous canary: $\mathbf{N}$0 The canary chain is verified backward from the last canary to the first. In the LLVM implementation, each vulnerable alloca-allocated buffer in the entry basic block is followed by a new 64-bit allocation, the canary is generated with a PA-based intrinsic, and the canary is stored immediately after the corresponding buffer. At function exit, canaries are authenticated in reverse order with autda; failure causes a fault or error handler invocation before returning.

The construction yields several robustness properties stated in the paper: no need for secure storage of a reference canary, runtime-generated canaries that are statistically unique to a call, protection of individual variables from buffer overflow, and hardware-assisted generation and verification (Liljestrand et al., 2019). Fine-grained placement after each vulnerable buffer addresses the limitation of one canary per frame and is intended to detect overflows that corrupt local variables without reaching the return address.

Performance was evaluated on SPEC CPU 2017 using ARMv8-A Base Platform FVP for functional evaluation and a HiKey board with Cortex-A53 for performance via a PA-analogue approach. The reported key result is a geometric mean overhead of 0.30% (Liljestrand et al., 2019). The stated limitations include lack of protection for dynamic allocations, no defense against arbitrary memory read/write, the possibility that an attack succeeds before the epilogue, and the need for stronger handling across process boundaries if fork/restart behavior is relevant.

5. Optimized canaries for one-run privacy auditing

In one-run privacy auditing, the auditor chooses canaries

$\mathbf{N}$1

includes each with probability $\mathbf{N}$2, and trains a single model on

$\mathbf{N}$3

Each canary is scored with a membership score $\mathbf{N}$4, typically the negative loss,

$\mathbf{N}$5

and the scores are used either for membership inference metrics such as TPR at low FPR or for a privacy leakage estimate $\mathbf{N}$6 in DP auditing (Dagréou et al., 26 May 2026). The central issue is that one-run auditing has only one trained model, so canaries must be simultaneously detectable and separable.

The paper formalizes memorability and interference through influence functions. For the ERM solution

$\mathbf{N}$7

the influence of $\mathbf{N}$8 on the score of $\mathbf{N}$9 is

$\mathbf{V}$0

When $\mathbf{V}$1, this is self-influence; when $\mathbf{V}$2, it is cross-influence. For loss-based scores under strong convexity,

$\mathbf{V}$3

The paper explicitly emphasizes that large $\mathbf{V}$4 is good and large $\mathbf{V}$5 for $\mathbf{V}$6 is bad (Dagréou et al., 26 May 2026).

The first stage of IBIS is greedy influence-based initialization. The selection objective is

$\mathbf{V}$7

approximated by a greedy heuristic that preselects the top $\mathbf{V}$8 points by self-influence, initializes with the strongest self-influence point, and iteratively adds the next point maximizing

$\mathbf{V}$9

The second stage is a bilevel optimization that refines canaries while promoting diversity in representation space. The diversity regularizer is

$\mathbf{V}'$0

and the simplified bilevel objective is

$\mathbf{V}'$1

subject to

$\mathbf{V}'$2

The hypergradient is derived under differentiability and strong convexity, and efficient optimization uses Approximate Implicit Differentiation via an adapted SOBA-style procedure that jointly updates model parameters $\mathbf{V}'$3, an auxiliary vector $\mathbf{V}'$4, and the canaries $\mathbf{V}'$5 (Dagréou et al., 26 May 2026). The full pipeline, named IBIS, is: greedy influence-based selection, removal of selected points from $\mathbf{V}'$6, approximation of $\mathbf{V}'$7 and initialization of $\mathbf{V}'$8, and SOBA-style bilevel refinement.

Experiments are reported on CIFAR-10 with ResNet9, WRN16-4, and CNN, under both non-private and DP-SGD training. Evaluation uses $\mathbf{V}'$9 and a GDP-based one-run auditing estimator for $identity = H\big(m_{\mathrm{prelude} \,\Vert\, h_{\mathrm{env} \,\Vert\, h_{\mathrm{policy} \,\Vert\, h_{\mathrm{registry} \,\Vert\, h_{\mathrm{persona} \,\Vert\, v_{\mathrm{rt}\big)$0. The main reported findings include that influence-based initialization beats random initialization even before refinement, regularized IBIS with canaries crafted on WRN16-4 achieves near-perfect [email protected] of

$identity = H\big(m_{\mathrm{prelude} \,\Vert\, h_{\mathrm{env} \,\Vert\, h_{\mathrm{policy} \,\Vert\, h_{\mathrm{registry} \,\Vert\, h_{\mathrm{persona} \,\Vert\, v_{\mathrm{rt}\big)$1

and total IBIS cost is about 1.5–2.5 GPU hours depending on architecture, compared with 90–120 hours reportedly needed by the prior retraining-based approach for 1000 canaries (Dagréou et al., 26 May 2026). In DP auditing, performance is described as competitive rather than uniformly better, and transferability across architectures is imperfect.

6. Comparative structure of robustness

The three constructions can be organized by the object that is stabilized and the confounder that is excluded.

Setting	Robustness target	Failure mode addressed
ICAN-Deploy	Identity hash across the canary window	Identity drift during progressive delivery
PCan	Canary integrity without reusable in-memory secret	Memory disclosure, brute-forcing, and incomplete local-variable coverage
IBIS	Detectability of each canary in one-run auditing	Canary interference in score space or representation space

In ICAN-Deploy, robustness comes from excluding $identity = H\big(m_{\mathrm{prelude} \,\Vert\, h_{\mathrm{env} \,\Vert\, h_{\mathrm{policy} \,\Vert\, h_{\mathrm{registry} \,\Vert\, h_{\mathrm{persona} \,\Vert\, v_{\mathrm{rt}\big)$2 and $identity = H\big(m_{\mathrm{prelude} \,\Vert\, h_{\mathrm{env} \,\Vert\, h_{\mathrm{policy} \,\Vert\, h_{\mathrm{registry} \,\Vert\, h_{\mathrm{persona} \,\Vert\, v_{\mathrm{rt}\big)$3 from the hashed identity and constraining the state machine so that canary transitions do not write identity inputs (Qin et al., 27 May 2026). In PCan, robustness comes from making canaries runtime-generated, function- and call-specific, and chained via PA-signed pointers rather than stored as a reusable master value (Liljestrand et al., 2019). In IBIS, robustness comes from maximizing self-influence while suppressing cross-influence, then preserving diversity in embedding space during bilevel optimization (Dagréou et al., 26 May 2026).

This suggests a common design pattern: a canary is strengthened by narrowing the set of state variables on which its validity depends. In one case the excluded variables are mutable capability versions; in another they are memory-resident reference secrets; in the third they are correlated neighboring canaries in representation space. The pattern is interpretive, but it aligns closely with the explicit constructions in the cited works.

7. Assumptions, limitations, and common misconceptions

A recurrent misconception is that a robust canary guarantees full system-level safety. The cited literature does not support that claim. ICAN-Deploy states explicitly that identity invariance is not behavioral invariance; a new capability version may behave very differently while leaving identity unchanged, and behavioral safety still depends on the validator, contract layer, and runtime governance (Qin et al., 27 May 2026). PCan does not defend against an adversary with arbitrary memory read/write access, does not yet protect dynamic allocations, and may detect corruption only at epilogue unless earlier checks are inserted (Liljestrand et al., 2019). IBIS derives its hypergradient exactly only under strong convexity assumptions, whereas the experiments are in non-convex deep networks; the regularizer can be slightly worse in the private case, and optimized canaries may lose semantic interpretability (Dagréou et al., 26 May 2026).

Another misconception is that robustness is synonymous with immutability. The three papers instead separate a stable reference structure from an allowed mutation path. ICAN-Deploy permits arbitrary capability evolution within the version-and-name envelope. PCan regenerates canaries on each call rather than freezing a single process-wide secret. IBIS improves canary detectability not by fixing a single probe design, but by optimizing a set of canaries subject to low interference. In that sense, the robust constructions are not static defenses; they are constrained mutation schemes whose invariants are chosen to preserve the meaning of the canary.

For certification, systems security, and privacy auditing, the practical implication is that canary mechanisms must be designed around the dominant failure mode of the surrounding system. The cited works indicate three different answers: preserve cryptographic identity during rollout, avoid reusable stack secrets through PA-backed dynamic generation, and craft auditing canaries that are both memorable and minimally interfering.