When Valid Tool Calls Change Meaning: Formation-Consistent Dispatch for LLM Agents

• A handler selected after formation can reverse an unchanged, schema-valid call’s security effect, a failure the paper names schema-epoch drift.The descriptor may stay unchanged while the handler or execution context changes.Source: §1 · p. 1
• Existing defenses protect definitions, arguments, servers, policies, or execution capsules, while FCD extends protection to a successor’s effects on a pending call.Prior TOCTOU work concerns changes between separate model-issued calls.Source: §1 · p. 1
• FCD separates effect compatibility, formation-time authorization, and lifecycle eligibility; a compatible successor is not automatically authorized or ready to execute.The exact source remains preferred, and the captured successor may execute only after source retirement.Source: §1 · pp. 1–2
• FCD captures a successor only when a reviewed, provenance-bound effect summary shows that the concrete call fits its security contract.Profiles bound supported source structures, arguments, declared effects, and assumptions.Source: §1 · p. 2
• Stock releases, profiles, policy comparisons, lifecycle tests, and replicated-gateway experiments evaluate whether FCD carries call-specific decisions from formation to effect.The evaluation also tests stock-handler traces and deployment paths.Source: §1 · p. 2

2.1. The agent tool path

• MCP gives the model a tool name, description, and schema, but the host separately selects the binary, configuration, and replica for execution.The ordinary call payload carries only the name and arguments.Source: §2.1 · p. 2
• Approval, retry, reconnect, rollout, or retirement can change the handler after formation, leaving a valid call with a different visibility, destination, access, or mutation effect.This separation creates schema-epoch drift when execution selects a different descriptor–handler relation.Source: §2.1 · p. 2

2.2. Failure and adversary model

• A rollout, rollback, retry, or reconnect can route a retained call to an older handler that changes private intent to public intent.The adversary can control availability and route selection, but cannot forge trusted credentials or alter authenticated registry state.Source: §2.2 · p. 2
• FCD fixes the source and any authorized successor at formation, then uses the exact source while eligible and the captured successor only after safe retirement.The trusted authorization plane retains formation state, authenticates targets, orders lifecycle decisions, and connects admission to the final effect.Source: §2.2 · p. 2, Figure 1 · p. 3

3.1. Stock release semantics

• GitHub and Azure stock releases assigned different effects to omitted arguments: the same calls requested private versus public repository creation and disabled versus enabled network access.GitHub’s explicit private:true control preserved private intent; Azure tested 30 paired resource names.Source: §3.1 · p. 3
• With unchanged descriptors, older Git handlers created a canary file while patched handlers rejected the fixed argument in 3/3 runs; DBHub changed state while read-only, but its newer handler rejected the call in 5/5 runs.The paper concludes that descriptor comparison and relisting cannot detect these hidden handler or policy changes.Source: §3.1 · p. 3
• OpenClaw’s payload-blind reconnect selected a different session containing a seeded task in 3/3 runs, while exact execution returned the empty formation session in 3/3.Descriptor and argument digests remained identical.Source: §3.1 · p. 3

3.3. Deployment reachability

• In mixed GitHub replicas, each new-descriptor/old-handler match produced public intent; sticky routing removed the mismatch, and explicit private:true preserved intent.The hosted-model run retained the name-only arguments and reproduced the reversal.Source: Figure 2 · p. 4, §3.3 · p. 4

3.2. Hosted-model update path

• A hosted model retained arguments formed under v1 while v2 changed an omitted recipient’s default; all 12 held calls produced the protected effect across four update patterns.Six stable or compatible controls produced SAFE, while two strict controls stopped without effect.Source: §3.2 · pp. 3–4

3.3. Deployment reachability

• A Kubernetes RollingUpdate replaced v1.4 backends with v1.3 before release, and every held call produced public intent despite the stable Service endpoint.Stable controls produced private intent.Source: §3.3 · p. 4

4.1. Security objective

• FCD separates effect compatibility, invocation authority, and lifecycle eligibility; a successor executes only when all three permit it.Compatibility evidence alone does not authorize substitution for an earlier invocation.Source: §4.1 · p. 4

4.2. Design overview and requirements

• The design preserves formation provenance, authenticates registered targets, orders admission against retirement, and requires explicit evidence for substitution.Configured action policy covers the complete formation record before the enforcement boundary.Source: §4.2 · p. 5

4.3. Catalog snapshot and authenticated context

• A trusted host retains the exact catalog snapshot used for generation and approval, and dispatch uses its credential rather than a mutable latest lookup.Relisting creates a distinct snapshot, preserving the provenance of pending calls.Source: §4.3 · p. 5

4.4. Atomic admission and retirement

• Admission and drain are serialized: a committed admission pins its target, while a drain that wins first prevents dispatch.The SQLite and etcd realizations order credential and lifecycle checks with lease creation; registry unavailability stops dispatch.Source: §4.4 · p. 6

4.5. Uncertain outcomes and recovery

• An uncertain transport result keeps the source DRAINING and blocks replay or substitution until signed resolution or a newer backend generation releases the lease.Recovery creates a new formation record and reruns any configured action decision.Source: §4.5 · p. 6

4.6. Formation-bound compatibility authority

• A pending call fixes its source and at most one successor at formation; later certificates govern new calls rather than expanding that call’s authority.The source has priority, and a captured successor can execute only after source retirement.Source: §4.1 · p. 4, §4.6 · p. 6

4.7. Profile-guided call-specific evidence

• The call-specific profile pipeline matches reviewed handler paths, checks callee identities, regenerates provenance-bound summaries, and issues a certificate only when every effect satisfies the contract.A recognized callee outside the reviewed inventory stops registration; the profile records its supported arguments, modeled effects, assumptions, and rejection conditions.Source: §4.7 · pp. 6–7
• A target summary captures a successor only when its modeled effects fit the concrete call’s security contract; unsupported or ambiguous cases stop automatic capture.Profiles bound supported source structures, arguments, dependencies, environments, and modeled effects; missing facts can instead require exact execution or review.Source: §4.7 · pp. 6–7

5. Security Analysis

• Every protected effect uses an interpreter authorized at formation when P1–P4 hold, and a non-source effect occurs only after the source reaches STALE.P1–P4 retain provenance, prevent authority expansion, order admission against lifecycle changes, and carry the admitted identity to the effect.Source: §5 · p. 8

5.1. P1: Formation provenance

• The host’s immutable snapshot and credential bind each invocation to its descriptor, epoch, tool, artifact, and session, preventing relisting or reconnection from replacing formation provenance.Faithful registration connects the artifact to the model-visible contract.Source: §5.1 · p. 8

5.2. P2: Monotonic target authority

• Formation fixes the source and at most one target; expiry or pre-admission revocation can remove that target, but later certificates cannot add or replace it.Using a new target requires a new formation record and any configured action approval.Source: §5.2 · p. 8

5.3. P3: Atomic lifecycle admission

• Admission pins the selected pool if its transaction commits first; drain or revocation rejects the call if its transaction commits first.A DRAINING source cannot trigger substitution; retirement reaches STALE only after lease markers clear.Source: §5.3 · p. 8

5.4. P4: Execution identity

• A fixed authenticated mapping preserves the admitted pool and artifact, while mutable routing requires a signed generation checked by a nonbypassable final guard.The guard rejects stale, mismatched, or replayed tokens before the effect.Source: §5.4 · p. 8

5.5. P5: Profile-bounded effect containment

• Under the reviewed envelope premise, the certificate establishes that a target’s modeled effects fit the call contract, and P1–P4 ensure execution reaches that target and environment.Unsupported arguments, unknown effects, unreviewed call sites, or identity mismatches stop the generated path.Source: §5.5 · p. 8
• Together, P1–P4 establish registered-target safety, while P5 adds call-specific semantic containment; availability remains limited to the authorized set’s eligible interpreters.The call ends when that set contains no eligible interpreter.Source: §5.5 · p. 8

6.1. Prototype and setup

• The prototype combined local and replicated gateways, four source-analysis profiles, framework integrations, and model-facing tests using frozen versions and effect recorders.The evaluation covered LangGraph, LangChain MCP, PydanticAI, and the Python MCP SDK, alongside local and Kubernetes deployments.Source: §6.1 · p. 9

6.2. RQ1: Profile-guided compatibility evidence

• Across 32 official releases, 29 required no release-specific change and three left reviewed source structures and escalated.A frozen 16-release expansion matched a separate source oracle without profile changes; all 20 supported safe calls remained preserved.Source: §6.2 · p. 9

6.3. RQ2: Formation authority and lifecycle

• FCD completed all three pending calls whose effect remained private and blocked all three whose omission became public; release-wide approval produced three public effects.Exact pinning and release-wide denial stopped all six calls; FCD required new approval only for the three calls whose effect changed.Source: §6.3 · p. 10, Table 6 · p. 10
• The lifecycle ablation rejected the fallback’s unsafe executions in 20/20 schedules, while FCD’s final guard stopped all 20 mutable-route executions before effect.A formation-captured generated certificate executed after source retirement in 3/3 trials; the same certificate installed later produced zero old-call callbacks.Source: §6.3 · p. 11

6.4. RQ3: Integration and deployment transfer

• In 64 local Kubernetes schedules, each produced one registered effect or a pre-effect rejection; EC2 schedules rejected configuration mismatches, quorum loss, and drains before effect.Five cross-replica calls reached the registered target; the same authenticated formation record and shared admission order governed tested framework, process-handoff, and cross-replica paths.Source: §6.4 · p. 11

6.5. RQ4: Model-facing agreement and runtime cost

• At concurrency 64, per-lease markers sustained 256.72 requests/s with a 248.42 ms p95, versus 38.56 requests/s and 3,753.11 ms p95 for the shared-record design.The optimized EC2 path reached 62.7% of the matched TLS baseline at concurrency 32, with all 1,200 protected requests reaching the registered fixture without a drifted effect.Source: §6.5 · p. 11, Figure 5 · p. 11

7.1. Authority beyond version pinning

• A compatible successor is not automatically authorized for a pending call; formation captures authority, and lifecycle state determines when it may execute.The evaluated prototype records one successor; a finite ordered successor set is future work and would fix membership and order at formation.Source: §7.1 · pp. 11–12

7.2. Semantic trust boundary

• Profile authors and the reviewed call-site classifier define the semantic trusted computing boundary, including supported structures, arguments, effects, and assumptions.Unsupported source shapes and arguments stop automatic capture, and an independent process regenerates each summary.Source: §7.2 · p. 12

7.3. Prompt and model controls

• Prompt policies can materialize known fields but cannot select the handler; nine of 16 prompt-only calls reached a release different from the visible schema.Schema rereading produced no wire-level relist in eight trials; FCD authenticates formation identity outside the model interface.Source: §7.3 · p. 12

7.4. Cost, availability, and recovery

• Local enforcement adds sub-millisecond work, while replicated admission adds registry and final-fence latency before model and external-tool execution.A registry outage suspends admission; retirement, expiry, mismatch, or unresolved timeout ends or quarantines the call rather than redirecting it.Source: §7.4 · p. 12

8.1. API evolution and update consistency

• API compatibility and update-consistency work studies behavioral changes, affected paths, or workflow and routing history, while FCD binds a concrete-call effect bound to invocation authority and artifact identity.FCD uses lifecycle and routing mechanisms as execution substrate, but its profile checks the call’s effect contract and its formation record checks whether that invocation authorized the target.Source: §8.1 · pp. 12–13

8.2. Agent and tool defenses

• Agent defenses validate policies, definitions, servers, or execution capsules; FCD adds source-derived effects for the concrete call and formation-scoped successor authority.Unlike work on changes between separate calls or staged effects before commit, FCD covers a call whose source can retire before execution.Source: §8.2 · p. 13
• Action-policy and isolation systems constrain intent or mediate components, while FCD carries an action-policy decision to an interpreter authorized at the same formation point.Remote attestation and in-toto can strengthen FCD’s artifact evidence.Source: §8.2 · p. 13

9. Conclusion

• FCD binds a target’s declared in-scope effects, formation authorization, and lifecycle eligibility before allowing an effect.It prefers the exact source and permits a captured successor only after completed retirement.Source: §9 · p. 13
• Stock releases and deployment paths reproduced schema-epoch drift, while experiments preserved the formation decision through execution.Under the closed-target policy, later rollout decisions may contract pending authority but cannot expand it.Source: §9 · p. 13
• The policy comparison retained existing approval only for the safe pending call.Reviewed profiles reused effect evidence across releases, and stock-handler traces connected that evidence to admission and effect.Source: §9 · p. 13

Appendix A. Registration Completeness

• The deployment defines the target’s runtime inputs, and must cover every input that can change a call’s security-relevant meaning.FCD separately determines whether a pending call may execute on a registered target.Source: Appendix A · p. 15

A.1. Authenticated registration manifest

• Each epoch’s signed canonical manifest binds tool and descriptor identities to artifact, deployment, configuration, feature-flag, downstream-service, and policy identities.Secrets are represented by immutable version identifiers, and changing any covered field creates a different epoch, including for same-image deployments.Source: §A.1 · p. 15
• The manifest’s authenticated scope includes registered inputs that can change authorization, defaults, validation, destination, visibility, or other security-relevant effects.Operators declare these inputs; covered changes force a new epoch, while configuration-read tracing and dependency declarations help audit omissions.Source: §A.1 · p. 15
• The registrar asserts that the source interpreter implements the registered contract, while profile-guided certificates bind analyzed source, profile, summary, and execution context to the manifest.Services with bounded configuration and dependencies can review the manifest schema directly; dynamic per-request dependencies use signed snapshots or enforced contracts.Source: §A.1 · p. 15

A.2. Example: Kubernetes deployment

• Two independently addressed gateways, three etcd members, and backend fixtures implement the evaluated deployment, with a same-image fixture testing changed security-relevant configuration.The local setup used one kind node; transfer testing used k3s across three EC2 guest VMs in one availability zone.Source: §A.2 · pp. 15–16
• A capability formed through one gateway can be executed through another only after atomic etcd admission checks epoch, assertion, revocation-policy, and target identities.Admission creates a durable lease marker; registry unavailability stops dispatch, and races with drain or revocation have one serial outcome.Source: §A.2 · p. 16
• The backend fixture checks artifact and configuration identities in the request that records the effect, fencing identity validation to the final effect path.A production deployment could substitute a backend-native guard or authenticated sidecar mediating the only effect path; Kubernetes metadata alone does not provide fence authority.Source: §A.2 · p. 16
• Unique per-lease markers replace a contended shared epoch record, while retirement drains and scans active leases before marking the epoch stale.The optimized registry reproduced safety outcomes; production admission can also enforce digest-pinned images and signed manifest references.Source: §A.2 · p. 16

A.3. Dynamic flags and dependencies

• Mutable flags require signed immutable snapshots, and downstream behavior is bound through immutable service revisions or boundary-enforced contract versions.Changes to covered inputs register a new epoch; a pending call uses its exact epoch, a captured edge only after safe retirement, or rejects before effect.Source: §A.3 · p. 16
• The conditional consequence covers request interpretation under registered inputs, while mutable application data and external authorization policy rely on their own consistency and authorization mechanisms.The operator defines the manifest schema; profile authors define transition analysis, and compatibility issuers review escalations.Source: §A.3 · p. 16

A.4. Reviewed profile acceptance envelopes

• Reviewed profile envelopes specify source structures, argument domains, effect bounds, and stopping conditions; releases outside an envelope escalate rather than receive a certificate.The table records the reviewed envelopes, and unknowns produce no certificate while rejection stops summary registration.Source: §A.4 · p. 16, Table 9 · p. 17