Source-linked AI summary
From Review to Authorization: Key-Isolated Threshold Signing for LLM Agents
Yu Zheng, Qizhi Zhang
TL;DR
LLM agents can turn untrusted content into consequential actions when the same process interprets it and holds reusable signing authority. KITA separates review from key custody and requires threshold authorization of the exact action; its prototype passes six enforcement tests, while reviewer correlation remains a limit on semantic quality.
Problem
When an LLM process both reads untrusted content and controls a reusable signing credential, prompt injection can lead to an unauthorized transfer or permission change.
Source: §1 · p. 1Method
Results
Takeaways & Limitations
KITA makes semantic review an enforceable condition for exact-action authorization while keeping reusable signing authority outside LLM processes.
Source: §2 · p. 3, §4 · p. 4Semantic quality remains limited by correlated reviewer judgments; heterogeneous reviewer ensembles with calibrated confidence and abstention are proposed as future work.
Source: §4 · p. 4
Abstract
from arXiv · showhide
Autonomous LLM agents can turn untrusted content into effectful actions such as payments and permission changes. If the same process interprets this content and controls a reusable signing credential, prompt injection can cross the judgment boundary and reach execution authority. We present KITA, a review-to-authorization architecture that keeps the user's personal secret signing key and every threshold signing-key share outside all LLM processes. Under threshold signature unforgeability and our system assumptions, compromising 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. Thus, any such authorization includes a share from an uncompromised domain, bound to the canonical action and released only after authenticated reviewer approval. This establishes execution-bound authorization integrity. We implement the complete reviewer-to-executor path with a structured-output LLM adapter and threshold BLS. Six system tests validate quorum gating and message binding at this interface, while cryptographic microbenchmarks measure the online signing path and its scaling behavior.
1 Introduction
Autonomous agents combine fallible judgment over untrusted content with actions that can change user state. KITA addresses the gap between semantic review and execution authority by binding review to threshold authorization of the exact action.
1 Introduction
- A single process that reads untrusted content and controls a reusable signing credential can turn prompt injection into an unauthorized transfer or permission change.The security question is whether an LLM process can execute its decision on its own, not only whether its decision is sound.Source: §1 · p. 1
- KITA complements mandate-based delegation by making semantic approval enforceable, a threshold that AP2 does not require for its Agent Key signature.AP2 binds a concrete closed mandate to a user-authorized open mandate and validates mandates in deterministic code.Source: §1 · p. 1
- Multi-agent debate and model panels can improve semantic judgment, but their output remains advisory unless another component enforces it.Source: §1 · p. 1
- KITA composes model-based review with threshold authorization for the exact executable action, while keeping all signing-key material outside LLM processes.The executor accepts an action only with a valid quorum signature over the reviewed bytes.Source: §1 · p. 2
2 Threshold-Enforced Agent Authorization
KITA separates proposal, review, signing, and execution so that LLMs never hold signing-key material and all approvals and signatures bind to one canonical action. A valid threshold signature is required for execution, providing authorization integrity under the stated assumptions.
2 Threshold-Enforced Agent Authorization
- The executor accepts a reviewed action only with a valid threshold signature, rather than relying on a software vote count or a key-holding agent.KITA separates proposal, review, signing, and execution while preserving autonomous execution.Source: §2 · pp. 2–3
- During setup, isolated signers use verifiable distributed key generation to obtain shares and a group public key without reconstructing the group secret key.For each request, the proposer constructs the action, evidence manifest, and policy; all reviewers inspect the same inputs.Source: §2 · pp. 2–3
- An authenticated reviewer approval unlocks only its paired isolated signer, which releases a signature share on the exact canonical message.A requested change creates new message bytes and restarts review.Source: §2 · pp. 2–3, Figure 1 · p. 3
- The canonical message binds action fields and execution context, while its evidence-manifest hash prevents evidence substitution after review.The verifier checks the signature, policy and key epochs, expiry, and replay state before executing exactly the signed action.Source: §2 · pp. 2–3
- A coalition controlling the proposer and fewer than t reviewer–signer domains cannot authorize a new action without t distinct valid signing contributions, absent a threshold-signature forgery.Thus, a below-threshold coalition needs a share from an uncompromised domain, released only after authenticated approval of the canonical action.Source: §2 · p. 4
3 Evaluation
The evaluation tests exact-action enforcement, reviewer-threshold behavior under correlated judgments, and online signing cost. The prototype passes six enforcement tests; simulations and microbenchmarks characterize threshold trade-offs and signing-path scaling.
3 Evaluation
- All six 2-of-3 prototype tests pass, covering valid quorum, below-threshold rejection, digest mismatch, action substitution, replay, and key-isolated inputs.Three live Codex reviewers also exercise the path; model text alone cannot execute an action without matching authenticated approvals and a valid threshold signature.Source: §3 · p. 4
- At ρ = 0.2, a 4-of-7 threshold yields false-approval (FA) and false-rejection (FR) rates 0.083 and 0.017, versus 0.20 and 0.10 for one reviewer.Unanimity yields FA 0.0013 but FR 0.45; at t = 4, FA rises from 0.033 at ρ = 0 toward 0.20 as ρ →1.Source: Figure 2 · p. 4, §3 · p. 4
- Signature-share generation averages 4.9–5.7 ms, while combination grows from 5.0 ms at t = 2 to 62.0 ms at t = 22.Pairing-based share and final verification average 0.55–0.59 s; final verification is independent of (t, n), the final signature is 48 bytes, and the online path needs no inter-signer communication.Source: §3 · p. 4
4 Concluding Remarks
KITA is presented as a starting point for making collective agent judgment an enforceable authorization boundary. Its semantic quality remains limited by correlated reviewer judgments.
4 Concluding Remarks
- KITA keeps reusable secret-key material outside LLMs and requires t approvals on the exact action, separating semantic review, credential custody, and execution.The authors identify correlated reviewer judgments as a limit on semantic quality and propose heterogeneous ensembles with calibrated confidence and abstention as future work.Source: §4 · p. 4
A Protocol Specification
KITA serializes an authorization as canonical bytes and binds review, signing, and execution to that same object. Its state machine requires a new review and quorum for revisions, while the stated integrity guarantee depends on explicit system assumptions.
A.1 Canonical Authorization Object
- Sign a structured authorization object in one documented canonical encoding, not an LLM transcript or human-readable summary.Reviewers and the verifier re-encode and reject bytes that do not match the canonical form; profiles may add fields but must retain verifier-required bindings.Source: §A.1 · p. 6
A.2 Review and Execution State Machine
- A request advances from draft through authenticated review and quorum to execution or expiry; nonce consumption is atomic with the action.Revisions create a new object and nonce or revision counter, and no share on the prior object is reused.Source: §A.2 · p. 6
B.1 Threat Model and Authorization-Integrity Claim
- With threshold unforgeability and the stated system assumptions, at most t−1 corrupt reviewer–signer domains still leave an honest contribution necessary for a new executed action.The action must receive valid contributions from at least t distinct signer indices on its exact bytes.Source: §B.1 · p. 7
B.2 Proof Sketch and System Composition
The system composes threshold unforgeability with exact-message verification and execution checks to provide authorization integrity. It instantiates the signing path with threshold BLS and describes key lifecycle controls and an alternative signature option.
B.2 Proof Sketch and System Composition
- Exact-message execution, verified and deduplicated shares, canonical encoding, and atomic nonce consumption compose threshold unforgeability into end-to-end authorization integrity.Reviewer-level auditability is provided separately through approval envelopes, signer indices, policy versions, evidence commitments, and execution receipts.Source: §B.2 · p. 7
- Authorization integrity is the formal guarantee; semantic quality, confidentiality, and availability are supported through deployment measures.The listed measures include reviewer diversity, protected transport, disclosure minimization, monitoring, and recovery procedures.Source: §B.2 · p. 7
C.1 Threshold BLS Instantiation
- The BLS profile uses deterministic one-element signatures, encoding the signature in 48 bytes and the public key in 96 bytes.The stated sizes apply to the minimal-signature-size BLS12-381 profile.Source: §C.1 · p. 8
- Threshold BLS uses Shamir sharing in the exponent: independently produced shares are verified, then any t valid indices can be interpolated into one signature.Each signer releases a share only after its paired reviewer approves the exact message; the final signature remains one group element as the committee grows.Source: §C.1 · p. 8
C.2 Key Setup and Lifecycle
- Production setup uses verifiable DKG so the group secret is never reconstructed; the controlled prototype instead uses a deterministic dealer profile.Shares are kept in separate failure domains, epochs are advanced for new keys or policies, and KITA fails closed if healthy reviewers fall below t.Source: §C.2 · p. 8
C.3 Alternative Signature Schemes
- Threshold ECDSA may suit payment stacks requiring it, but reconstructing the group secret for a conventional signing API recreates a single point of failure.The stated deployment trade-offs do not change the review-to-authorization composition.Source: §C.3 · pp. 8–9, Table 3 · p. 9
D Agent-Payment Deployment
KITA replaces the autonomous Agent Key boundary with a committee key and bounded policy while leaving existing checkout and payment checks in place. Its payment flow fixes fields before review, binds approval and shares to one canonical mandate, and executes only after verification.
D Agent-Payment Deployment
- KITA substitutes a reusable policy and committee key for the autonomous Agent Key while keeping signing material outside the agent.The conventional flow instead has the user interpret and sign each order; the merchant-signed checkout and payment-tool checks remain unchanged.Source: D Agent-Payment Deployment · p. 9, Figure 3 · p. 9
D.1 Nine-Step Payment Protocol
- The agent proposes a merchant-signed order, reviewers assess identical evidence, and isolated signer services authorize the same canonical mandate.The user first authorizes a bounded policy, and all payment fields are fixed before approval and share generation.Source: Figure 4 · p. 10, §D.1 · p. 10
- Review binds the closed mandate to the open mandate, checkout, payee, amount, audience, nonce, expiry, policy and key epochs, and evidence commitment.The payment tool verifies the mandate and signatures, consumes the nonce, executes exactly that object, and returns a receipt.Source: §D.1 · pp. 10–11
- The committee signature supplies autonomous authorization while existing mechanisms continue to provide merchant attestation, payment authentication, settlement, and receipts.For BLS interoperability, the AP2 extension profile requires agreement on the algorithm identifier, key representation, canonical signing input, verifier, and tests.Source: §D.1 · p. 11
E Evaluation Details
The prototype connects a structured-output reviewer interface to authenticated signing and execution. Deterministic tests exercise the real cryptographic path, complemented by one run with live reviewers.
E.1 End-to-End Enforcement and LLM Integration
- The live reviewer backend sends each separately instantiated model call identical canonical bytes, evidence, and policy, and requires a structured decision with the message digest.The gateway authenticates an approval that echoes the expected digest, and the signer independently checks it before producing a share.Source: §E.1 · p. 11
- The deterministic suite replaces model calls with a scripted backend but retains real share generation, pairing checks, signature interpolation and verification, and nonce recording.The same path was also run once with three live Codex reviewers.Source: §E.1 · p. 11
- The live run demonstrates interface compatibility and end-to-end execution, while the deterministic suite tests enforcement invariants.The harness connects a reviewer backend, authenticated review gateway, BLS signer service, and verifier/executor.Source: §E.1 · p. 11
E.1.1 Live Codex-model execution
The live Codex-model execution connected three independent reviewer sessions to the authenticated gateway, threshold-BLS, and verifier path. The laptop request allowed example-merchant payments in USD up to $1,500, and no signing or approval-channel keys were supplied to the sessions.
E.1.1 Live Codex-model execution
- Three independent, ephemeral, read-only Codex CLI sessions reviewed the same canonical USD 1,299 laptop payment request.Each used gpt-5.6-sol with medium reasoning effort and returned a strict schema; the request allowed example-merchant payments up to USD 1,500 and asserted a valid merchant signature.Source: §E.1.1 · p. 11
- No personal key, signing-key share, or approval-channel key was included in the reviewer sessions.The table caption describes one live execution demonstrating compatibility across the reviewer, authenticated gateway, threshold-BLS, and verifier path.Source: §E.1.1 · p. 11, Table 4 · p. 12
- The sessions returned reviewer decisions and verifier outcomes for the live execution.The supplied text refers to Table 4 for those outcomes but does not provide its cell values.Source: §E.1.1 · p. 11, Table 4 · p. 12
E.1.2 Deterministic execution trace and enforcement tests
A deterministic trace exercises reviewer-to-executor enforcement for a canonical laptop-payment authorization. Matching authenticated approvals unlock paired signature shares, while quorum verification and nonce consumption govern acceptance and replay.
E.1.2 Deterministic execution trace and enforcement tests
- The trace used a 2-of-3 committee with deterministic reviewer fixtures at the typed boundary of the live LLM adapter.Gateway, threshold-BLS, verifier, and replay operations ran; the trace is an implementation-level view of the enforcement boundary.Source: §E.1.2 · p. 12
- The USD 1,299 payment authorization bound the merchant, product, principal, policy version, committee epoch, nonce, expiry, and evidence hash.The policy allowed example-merchant and USD payments up to USD 1,500; the canonical bytes were represented by their SHA-256 digest D.Source: §E.1.2 · p. 12
- Reviewers received the same canonical request, evidence, and policy as data, with no personal key or signing share in their inputs.The reviewer instruction treated evidence as untrusted, required rejection for policy violations or missing authenticated evidence, and required exact digest echoing.Source: §E.1.2 · p. 12
- Two approving reviewers supplied shares that reached threshold, producing an accepted signature for the exact canonical authorization; replay failed after order-001 was spent.The third reviewer rejected, and its signer released no share.Source: §E.1.2 · p. 12
- Table 5 is identified as deterministic end-to-end tests validating enforcement at the LLM reviewer interface.The supplied caption gives no test counts or individual outcomes.Source: Table 5 · p. 13
E.2 Committee Sensitivity Model
The committee sensitivity model relates reviewer dependence and threshold choice to authorization error rates. The threshold-BLS prototype measures the online signing path and its scaling behavior.
E.2 Committee Sensitivity Model
- Reviewer latent scores use a shared-dependence parameter ρ, with thresholds set for marginal approval probabilities of 0.90 on legitimate requests and 0.20 on out-of-policy requests.The text distinguishes ρ, which correlates latent scores, from the separately estimated binary-vote correlation.Source: §E.2 · p. 13
- The n = 7, latent ρ = 0.2 sweep reports induced binary correlations of 0.106 for out-of-policy requests and 0.080 for legitimate requests.Each cell used 400,000 Monte Carlo trials; the largest reported 95% interval halfwidth was below 0.0016.Source: Table 6 · p. 13, §E.2 · p. 13
- At t = 4, false approvals rise from 0.033 at ρ = 0 toward the single-reviewer rate of 0.20 as ρ approaches 1.The model identifies threshold choice as setting the security/utility point and correlation as determining how much decision benefit a committee retains.Source: §E.2 · p. 13
E.3 Threshold-BLS Prototype
- The prototype generates Shamir shares, verifies admitted signature shares, interpolates t valid shares, verifies the aggregate, and rejects a mutated share.The controlled benchmark uses deterministic dealer-generated shares; the target deployment instead uses verifiable DKG with cryptographic randomness.Source: §E.3 · pp. 13–14
- Every measured configuration produced a 48-byte signature and 96-byte public key, with online signing requiring no inter-signer communication.The reported means characterize pure-Python py_ecc scaling and protocol structure; optimized native implementations set deployment latency.Source: Table 7 · p. 14, §E.3 · p. 14