Delegation Chain Calculus in SentinelAgent

• Delegation Chain Calculus (DCC) is a formal framework that models signed, hash-linked delegation tokens to verify multi-agent interactions in federal systems.
• It enforces seven core security properties—including scope narrowing, policy preservation, and probabilistic intent verification—to prevent delegated authority abuse.
• Paired with the Intent-Preserving Delegation Protocol and a non-LLM Delegation Authority Service, DCC guarantees runtime enforcement, auditability, and secure action reconstruction.

Searching arXiv for the specified paper to ground the article in the cited source. Delegation Chain Calculus (DCC) is the formal calculus introduced in SentinelAgent for verifiable delegation chains in federal multi-agent AI systems. It models the case in which Agent A delegates to Agent B, which invokes Tool C on behalf of User X, and is designed to answer whose authorization chain led to an action and where it violated policy. In SentinelAgent, DCC defines seven properties—six deterministic and one probabilistic—and is paired with the Intent-Preserving Delegation Protocol (IPDP), which enforces those properties at runtime through a non-LLM Delegation Authority Service (DAS) (Patil, 3 Apr 2026).

1. Conceptual role within SentinelAgent

DCC underlies SentinelAgent’s formal treatment of multi-agent handoffs. The framework is centered on verifiable delegation chains rather than isolated authorization events. In that formulation, delegation is not merely a transfer of execution responsibility; it is a sequence of signed, scope-constrained, policy-carrying, hash-linked tokens whose lineage can be reconstructed and audited (Patil, 3 Apr 2026).

The paper situates DCC around a core problem: when one agent delegates to another, and the downstream agent invokes tools on behalf of a user, existing frameworks do not answer whose authorization chain led to the action or where policy violation occurred. DCC addresses that gap by specifying a chain model, an operational semantics for chain extension and reconstruction, and a property set that constrains authority, policy, intent, revocation behavior, tool use, and output typing.

A key structural feature is that DCC is not only a static calculus. The paper presents it together with runtime enforcement machinery. This suggests that the calculus is intended as both a specification language and a systems security contract: the formal properties define what a valid chain must satisfy, while the protocol and service architecture determine how those properties are checked and maintained during execution.

2. Syntax and operational semantics

DCC models each delegation step as a token

$$\tau \;\;=\;\; (\mathit{id},\,\mathit{src},\,\mathit{dst},\,\sigma,\,\iota,\,\pi,\,h_p,\,t_{\exp},\,\mathit{sig})$$

where $\mathit{src},\mathit{dst}$ are agent identities (DIDs), $\sigma\subseteq\Sigma$ is the authority scope, $\iota\in\mathbb{R}^d$ is the intent embedding with associated NL text, $\pi\subseteq\Pi$ is the policy-constraint set, $h_p=H(\tau_{i-1})$ is the parent-token hash, $t_{\exp}$ is the expiry, and $\mathit{sig}$ is the DAS signature (Patil, 3 Apr 2026).

A delegation chain is a nonempty list

$C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$

satisfying three structural conditions: $\tau_0.\mathit{src}$ is a human user; $\mathit{src},\mathit{dst}$0 for $\mathit{src},\mathit{dst}$1; and $\mathit{src},\mathit{dst}$2 for $\mathit{src},\mathit{dst}$3. These conditions give DCC both endpoint continuity and cryptographic parent linkage.

The operational semantics is given through two inference rules. Under (D-Init), the user obtains the root token: $\mathit{src},\mathit{dst}$4 Under (D-Step), if a chain $\mathit{src},\mathit{dst}$5 exists and agent $\mathit{src},\mathit{dst}$6 requests delegation to $\mathit{src},\mathit{dst}$7 with proposed $\mathit{src},\mathit{dst}$8, then

$\mathit{src},\mathit{dst}$9

In words, DAS checks authority narrowing (P1), intent (P2), policy (P3), expiry and revocation (P5), then issues the new token $\sigma\subseteq\Sigma$0 with hash-linked parent. Reconstruction is defined as a hash-chain walk: given $\sigma\subseteq\Sigma$1, repeatedly look up parent hashes to recover $\sigma\subseteq\Sigma$2 in $\sigma\subseteq\Sigma$3 time. This reconstructibility requirement is elevated to a first-class security property rather than treated as an implementation convenience.

3. The seven properties

DCC defines seven security properties. The paper writes $\sigma\subseteq\Sigma$4 as $\sigma\subseteq\Sigma$5, $\sigma\subseteq\Sigma$6 as $\sigma\subseteq\Sigma$7, and $\sigma\subseteq\Sigma$8 as $\sigma\subseteq\Sigma$9. It also defines $\iota\in\mathbb{R}^d$0 as the manifest derived from $\iota\in\mathbb{R}^d$1, $\iota\in\mathbb{R}^d$2 as the permitted output tags, $\iota\in\mathbb{R}^d$3 as the set of API calls $\iota\in\mathbb{R}^d$4 attempts, and $\iota\in\mathbb{R}^d$5 as its typed output (Patil, 3 Apr 2026).

Property	Formal statement	Role
P1—Authority Monotonic Narrowing	$\iota\in\mathbb{R}^d$6	Child scope must narrow
P2—Intent Entailment Preservation	$\iota\in\mathbb{R}^d$7	Runtime intent check
P3—Policy Conjunction Preservation	$\iota\in\mathbb{R}^d$8	Root policy persists
P4—Forensic Reconstructibility	$\iota\in\mathbb{R}^d$9	Action-to-chain attribution
P5—Bounded Cascade Containment	On violation at step $\pi\subseteq\Pi$0, $\pi\subseteq\Pi$1	Violation bounds descendant damage
P6—Scope-Action Conformance	$\pi\subseteq\Pi$2	API calls limited by manifest
P7—Output Schema Conformance	$\pi\subseteq\Pi$3	Output tags limited by schema

The six deterministic properties are authority narrowing, policy preservation, forensic reconstructibility, cascade containment, scope-action conformance, and output schema conformance. The one probabilistic property is intent preservation. The distinction is significant because the paper does not treat intent checking as equivalent in character to the other enforcement goals. Instead, P2 is explicitly mediated by keywords, NLI, and override logic, while the remaining properties are formulated as hard structural or operational constraints.

The P2 formulation is layered. $\pi\subseteq\Pi$4 tests malicious keywords; Layer 2 uses a context-framed NLI check; Layer 3 does the benign-override. This structure shows that intent is handled as a semantic classification problem with explicit allowance for benign override, not as a purely syntactic acceptance criterion. A plausible implication is that DCC isolates natural-language ambiguity into one property while preserving deterministic guarantees elsewhere.

4. Meta-theorems and the infeasibility result

The paper states four meta-theorems and one proposition. Theorem 1, Property Minimality, says that every property $\pi\subseteq\Pi$5 is necessary: removing $\pi\subseteq\Pi$6 alone enables a concrete attack $\pi\subseteq\Pi$7 that succeeds iff $\pi\subseteq\Pi$8 is absent and all others hold (Patil, 3 Apr 2026). The proof sketch is constructive. Examples given include: without P1 one can escalate scope; without P6 one can call an unauthorized API; without P7 one can return a forbidden output tag.

The proposition on the practical infeasibility of deterministic intent verification states that no deterministic algorithm can achieve zero false positives and zero false negatives on natural-language delegation descriptions unless the input language is restricted to a formal grammar. The proof sketch invokes a Rice-style semantic-undecidability analogy and notes that, empirically, eight semantically ambiguous phrase pairs evade all deterministic filters without execution context. This proposition is central to the architecture because it explains why DCC treats P2 differently from P1 and P3–P7.

Theorem 2, Graceful Degradation, states that evading any single $\pi\subseteq\Pi$9 while holding $h_p=H(\tau_{i-1})$0 bounds the adversary’s damage envelope to strictly less than the unconstrained action space. In the paper’s 11-action model, each single evasion increases capability by at most one action, described as approximately $h_p=H(\tau_{i-1})$1 of the full space. Theorem 3, Defense-in-Depth Completeness, strengthens this claim by asserting that for any nonempty proper subset $h_p=H(\tau_{i-1})$2, the adversary’s capabilities remain bounded; only simultaneous evasion of all seven, that is, compromising the DAS itself, yields unconstrained access. The proof sketch exhaustively enumerates all $h_p=H(\tau_{i-1})$3 evasion subsets.

Theorem 4, Composition Safety with Write-Impact Notification, addresses concurrent chains. If two chains satisfying P1–P7 share no state or only read-shared state, then their parallel composition also satisfies P1–P7. If they share mutable state, then parallel composition satisfies P1–P7 provided a write-impact notification triggers re-verification of any chain whose assumptions are invalidated by the other’s write. The paper reports that empirically $h_p=H(\tau_{i-1})$4 tested scenarios required notification and all pass. This suggests that DCC is intended to scale beyond single isolated delegation paths to interacting multi-chain deployments.

5. Runtime enforcement: IPDP and the Delegation Authority Service

At runtime, IPDP implements DCC via the Delegation Authority Service, described as a non-LLM but model-backed HTTP service. The DAS contains the following components: Identity Registry; Policy Engine; Intent Verifier (three-layer NLI + keywords); Token Signer; Chain Store; Cascade Controller; Scope Enforcement Proxy; and Output Schema Validator (Patil, 3 Apr 2026). In the mapping given in the paper, these components correspond directly to the properties: Identity Registry to P1; Policy Engine to P3; Intent Verifier to P2; Token Signer to P1 and P4; Chain Store to P4; Cascade Controller to P5; Scope Enforcement Proxy to P6; and Output Schema Validator to P7.

The execution flow is defined in seven steps. In chain initiation, user $h_p=H(\tau_{i-1})$5 submits goal $h_p=H(\tau_{i-1})$6 and DAS issues $h_p=H(\tau_{i-1})$7. In the delegation request step, agent $h_p=H(\tau_{i-1})$8 requests $h_p=H(\tau_{i-1})$9 with $t_{\exp}$0. In seven-check verification, DAS performs C1 through C5: identity registry lookup; P1 check $t_{\exp}$1 and derivation of child manifest $t_{\exp}$2; P2 keyword + NLI + override; P3 check $t_{\exp}$3; and expiry/revocation check with P5 enabled. If all pass, DAS signs $t_{\exp}$4.

The subsequent enforcement points occur at tool execution and revocation time. For P6, all API calls go through Scope Enforcement Proxy blocking calls not in $t_{\exp}$5. For P7, all outputs go through Schema Validator blocking forbidden tags. For P5, on any violation DAS revokes $t_{\exp}$6 and descendants. For P4, DAS traverses the $t_{\exp}$7 chain to return $t_{\exp}$8. The paper therefore presents DCC not as an advisory policy layer but as a protocol with explicit interception points over delegation, API invocation, output release, revocation, and reconstruction.

A notable architectural claim is that IPDP enforces all seven properties at runtime through a non-LLM Delegation Authority Service. This is consistent with the infeasibility proposition: deterministic structural controls are delegated to non-LLM infrastructure, while the probabilistic intent check remains model-backed rather than fully deterministic.

6. Verification results, empirical behavior, and the worked chain

The paper reports a three-point verification lifecycle that achieves $t_{\exp}$9 combined TPR at $\mathit{sig}$0 FPR on DelegationBench v4, comprising $\mathit{sig}$1 scenarios, $\mathit{sig}$2 attack categories, and $\mathit{sig}$3 federal domains (Patil, 3 Apr 2026). Under black-box adversarial conditions, the DAS blocks $\mathit{sig}$4 attacks with $\mathit{sig}$5 false positives. Deterministic properties are described as unbreakable under adversarial stress testing, while intent verification degrades to $\mathit{sig}$6 against sophisticated paraphrasing. Fine-tuning the NLI model on $\mathit{sig}$7 government delegation examples improves P2 from $\mathit{sig}$8 to $\mathit{sig}$9 TPR, with 5-fold cross-validated $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$0. Even when intent verification is evaded, the remaining six properties constrain the adversary to permitted API calls, conformant outputs, traceable actions, bounded cascades, and compliant behavior.

For formal verification, the paper states that properties P1 and P3–P7 are mechanically verified via TLA$C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$1 model checking across $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$2 million states with zero violations. In the detailed model-checking section, two configurations are reported: one exploring $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$3 states and the other $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$4 states. The six invariants are Inv_P1, Inv_P3, Inv_P4, Inv_P5, Inv_P6, and Inv_P7, corresponding respectively to child-scope narrowing, child-policy inclusion of root-policy, parent-hash consistency, prohibition of action after revocation, API-call membership in manifest, and output-tag membership in schema.

The worked example is a three-step federal benefits chain: $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$5 Within that chain, P1 is witnessed by $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$6 and $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$7. P2 is witnessed by $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$8, likewise for $C \;=\; [\,\tau_0,\;\tau_1,\;\dots,\;\tau_n\,]$9, with no malicious keywords in either subtask. P3 is $\tau_0.\mathit{src}$0. P4 reconstructs $\tau_0.\mathit{src}$1 from any tool action under $\tau_0.\mathit{src}$2. P5 blocks $\tau_0.\mathit{src}$3 immediately if $\tau_0.\mathit{src}$4 is revoked, with $\tau_0.\mathit{src}$5. P6 blocks POST /external/send because it is not in $\tau_0.\mathit{src}$6, while permitting GET /records/query. P7 blocks demographic_profile because it is not in $\tau_0.\mathit{src}$7, while permitting record_data.

Taken together, these results characterize DCC as a calculus in which deterministic restrictions on scope, policy, chain integrity, revocation, tool calls, and output schemas are intended to remain intact even under adversarial stress, while intent preservation is treated as a probabilistic layer with empirically measurable degradation and improvement. The paper’s central claim is not that natural-language intent can be made perfectly decidable, but that the other six properties continue to bound the action space when intent verification fails.