From Review to Authorization: Key-Isolated Threshold Signing for LLM Agents

Yu Zheng; Qizhi Zhang

cs.CRSep 5, 2026

From Review to Authorization: Key-Isolated Threshold Signing for LLM Agents

Authors: Yu Zheng, Qizhi Zhang

Organizations: University of California, Berkeley · Independent Researcher

Abstract

Autonomous LLM agents can turn semantic judgments into consequential actions such as payments and permission changes. If the same process makes these judgments and controls a reusable signing credential, a mistaken judgment can reach execution without further approval. To make LLM review govern execution, we present KITA, an authorization architecture that keeps the user's personal signing key and every threshold signing-key share outside all LLM processes. Under threshold-signature unforgeability and our system assumptions, an adversary controlling the proposer and fewer than t reviewer-signer domains cannot produce a valid authorization for a new action without signing contributions from t distinct domains. This execution-bound authorization integrity ensures that each accepted authorization includes a share from an uncompromised domain, bound to the canonical action and released only after authenticated reviewer approval. We implement an in-process prototype of KITA with a structured-output LLM adapter and threshold BLS. Six system tests validate quorum gating and message binding, seven controlled baseline scenarios compare authorization outcomes, and cryptographic microbenchmarks measure online signing cost and its scaling behavior.

Figures & tables

Panel of Figure 1 — Figure 1: Review and key custody occupy separate components within each domain. An authenticated approval activates the paired signer; only action-bound signature shares leave it. The proposer combines a quorum into one signature, and the verifier executes the signed action. The diagram shows the authorization path after candidate selection and reviewer feedback. Dashed arrows denote user inputs and setup; solid arrows denote the authorization path.

Figure 2: Quorum size trades safety for completion; shared errors erode committee gains. Gaussian sensitivity model with

n=7

f=0

, and marginal rates

\bar{q}=0.20

and

\bar{r}=0.10

: (a) threshold sweep at latent correlation

\rho=0.2

; (b) dependence sweep at

t=4

. Each estimate uses

400{,}000

trials.

Appendix figures & tables7 assets

Supplementary material from the paper’s appendix.

Appendix

Field group	Example fields	Why it is signed
Protocol context	domain separator, schema version	Prevents a signature from being reused in another protocol or parser.
Principal and committee	principal ID, committee ID, group-key ID, key epoch	Binds the action to one delegator and the currently authorized share holders.
Policy and request	policy ID/version/digest, request ID, attempt budget	Binds user requirements and request-level execution and review limits.
Action	type, normalized parameters, execution audience	Defines exactly what the verifier may execute and where it may execute it.
Evidence	manifest digest $H(E)$ , source types, freshness requirements	Prevents evidence substitution while leaving source validation to reviewers.
Freshness and replay	attempt ID, nonce, issue time, expiry	Separates final review attempts and limits authorization lifetime.

Appendix

Table 1: Minimum content of the canonical authorization object.

Design	Credential custody	Quorum enforcement and failure boundary
Agent-held key	Complete key accessible to $P$	$P$ can sign any action within the delegation.
Isolated central signer	Complete key in one remote service	Service checks $t$ approvals; its compromise bypasses that check.
Direct approvals at $V$	Separate reviewer authentication keys	$V$ checks $t$ identities and action bindings; fewer than $t$ credentials cannot bypass the quorum.
KITA	One key share per reviewer domain	Signers gate shares; $V$ verifies one group signature. Fewer than $t$ exposed shares cannot bypass the quorum.

Appendix

Table 2: Authorization baselines. All quorum designs remain subject to mistaken reviewer approvals.

Failure	Treatment in the security model
Misleading input causes a wrong reviewer decision	False approval $X_{i}=1$ ; its signer can release a valid share while retaining key secrecy.
Proposer process is controlled	Adversary chooses proposals, evidence, and submissions; worst-case $p=1$ .
Worker/gateway takeover permits arbitrary approvals	Count the approval domain in $f$ ; full-domain corruption conservatively grants its key share as well.
Signer store or host is compromised	Its share is exposed and the domain counts in $f$ .
Shared administration exposes several domains	Count every affected domain; separate model calls do not create separate administrative boundaries.
Verifier or user setup is compromised	Violates the trusted setup/execution assumptions.

Appendix

Table 3: Mapping deployment failures to semantic error, domain corruption, and trusted components.

Check	Purchase requirement	Review operation
Deterministic	Total including fees $\leq\$ 1,500$ ; permitted payee and currency	Compare canonical fields with authenticated policy.
Semantic	New unit; supported configuration for the named application	Interpret condition qualifiers and match exact SKU/OS to vendor support documentation.
Evidence	Order identity, provenance, and freshness	Verify checkout signatures; retrieve approved sources; resolve conflicts or request more evidence.

Appendix

Table 4: Illustrative purchase requirements and corresponding review operations.

#	Test	Setup	Required outcome
1	Quorum authorizes	Two approvals, one rejection	Combined signature verifies; $V$ executes.
2	Insufficient quorum	One approval, two rejections	One valid share; no signature is formed.
3	Digest mismatch	One reviewer approves a different digest	Gateway rejects that approval; quorum is not reached.
4	Post-review substitution	Amount changed from 1,299 to 1,499 after signing	$V$ rejects the signature on the modified action.
5	Replay	Accepted action resubmitted	Spent nonce blocks the second execution.
6	Key-free identical input	Evidence containing injected instructions	All reviewers receive identical bytes with no key or channel-secret fields.

Appendix

Table 5: Scripted system tests of the in-process prototype.

Scenario	Agent key	Central signer	Direct approvals	KITA
Valid, two approvals	Accept	Accept	Accept	Accept
Unsafe, zero approvals	Accept	Block	Block	Block
Unsafe, one false approval	Accept	Block	Block	Block
Unsafe, two false approvals	Accept	Accept	Accept	Accept
One custody domain breached	Accept	Accept	Block	Block
Post-review substitution	Accept	Block	Block	Block

Appendix

Table 6: Execution outcomes under controlled review decisions and credential exposure. The custody row uses the scheme-specific compromise defined above. Two mistaken approvals authorize an unsafe action in all three quorum designs.

$n$	$t$	share sign (ms)	share verify (ms)	combine (ms)	final verify (ms)
3	2	4.907	558.237	5.045	586.684
5	3	5.708	565.976	5.536	561.076
7	5	5.058	567.418	11.367	555.983
10	7	5.054	558.328	16.724	554.668
16	11	5.117	560.180	28.711	565.716
24	17	4.936	556.257	47.746	567.630

Appendix

Table 7: Threshold-BLS operation times in milliseconds. All configurations use a 48-byte signature, a 96-byte public key, and noninteractive signature-share generation.

LLM Agent Security

Large language model agent security studies attacks and safeguards for systems that plan, use tools, retain memory, and act across applications.

See all 332 papers

Who Speaks, Who Authorizes, Who Acts? Understanding Trust Boundaries in Multi-Agent LLMs
Oct 16, 2026Junru Zhu, Xin Chen, Hang Lyu +6Multi-Agent LLM Systems AI Agent Security
Act on Your Behalf, Beyond Your Authorization: Benchmarking LLM Agent Authorization Alignment
Oct 20, 2026Zhiping Zhang, Franklin Mingzhe Li, Zihao Huang +1LLM Agent Evaluation AI Agent Safety Benchmarks
Northeastern University · Carnegie Mellon University · UNC-Chapel Hill
Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems
Aug 31, 2026Panduranga Sai Varma Dantuluri, Jyotirmoy SundiMulti-Agent LLM Systems LLM Agent Security
VotalAI

Oct 16, 2026J/K move · Enter open · S save

Who Speaks, Who Authorizes, Who Acts? Understanding Trust Boundaries in Multi-Agent LLMs

Junru Zhu, Xin Chen, Hang Lyu, Jiayue Meng+5

Multi-Agent LLM Systems AI Agent Security LLM Agent Safety Trustworthy AI Tool Access Control for LLM Agents

Open paper AskPDF arXiv

Multi-agent LLM systems exchange messages before acting through tools, but message delivery, signing authority, and tool-side enforcement are separate trust boundaries. We represent them as communication, authorization, and execution structures, and use the authority cut to characterize the smallest independently compromised signer coalition that can construct a policy-valid false-claim proof under stated assumptions. Controlled paired hidden-state studies reveal four distinctions. First, no fixed-message routing contrast across four models meets the prespecified large-effect criterion; when relays rewrite messages, executed false-state action rates vary by model and route configuration. Second, presented source-identity cues do not uniformly increase protected-action selection across three models. Third, on invalid-proof cases, Nemotron and Llama request protected actions in 52.1% and 54.2% of trials, respectively, yet a deterministic tool gate commits none: request-level and commitment-level safety readouts diverge. Finally, a separate single-model authorization check shows that a false claim with a policy-valid compromised-signer proof can pass the gate, since proof validity is not factual truth. These findings motivate evaluating delivered information, qualified authorization, model proposals, and committed actions separately.

Abstract

LLM Agent Security

Explore similar work

Who Speaks, Who Authorizes, Who Acts? Understanding Trust Boundaries in Multi-Agent LLMs

Act on Your Behalf, Beyond Your Authorization: Benchmarking LLM Agent Authorization Alignment

Delegation Without Trust: An Empirical Gap Analysis of Identity, Authorization, and Runtime Governance in Multi-Agent LLM Systems