Identity-bound delegated authorization, connector mediation, and offline-verifiable receipt lineage for agentic systems

1 . A computer-implemented control architecture for agentic operations against protected resources, comprising:

one or more processors; and

memory storing instructions that, when executed by the one or more processors, cause the control architecture to:

(a) receive an action request from an agent, the action request identifying at least a requested operation, a target resource, and request context;

(b) verify an identity credential bound to an agent-held cryptographic key to obtain a verified identity credential and validate freshness of proof of possession using at least one of a nonce, a monotonic counter, or a replay cache;

(c) canonicalize selected fields of the action request according to a deterministic encoding rule and compute a request digest using a domain-separated hash;

(d) determine, under at least one policy, a capability scope and one or more temporal constraints for the action request;

(e) issue a capability token cryptographically bound to the verified identity credential, the request digest, the capability scope, and the one or more temporal constraints;

(f) verify a connector descriptor for a connector exposing a tool capable of carrying out the requested operation, including validating a cryptographic integrity assertion for the connector descriptor;

(g) derive an invocation scope for the tool as a constrained function of the capability scope, permissions declared in the connector descriptor, and one or more policy constraints;

(h) execute, using an ephemeral access credential limited to the invocation scope, a connector call to obtain tool output;

(i) apply a context firewall that stores instruction input and the tool output in separate channels and blocks promotion of the tool output into a privileged instruction or executable parameter absent satisfaction of a verification rule;

(j) generate a plurality of cryptographically linked receipts comprising at least a delegation receipt for issuance of the capability token, a tool-use receipt for the connector call, and at least one of a consumption receipt, a refusal receipt, a promotion receipt, or a revocation receipt;

(k) register the plurality of cryptographically linked receipts in an append-only transparency log and obtain at least one of an inclusion proof, a consistency proof, or a checkpoint commitment for the plurality of cryptographically linked receipts; and

(l) provide a verification bundle usable by an offline verifier to reconstruct lineage from the action request through the connector call and to verify the proofs without requiring online access to a receipt producer.

2 . The control architecture of claim 1 , wherein canonicalizing comprises encoding mandatory fields in a fixed order, encoding optional fields with explicit null markers or omission markers according to a canonicalization rule, ordering extension fields deterministically, and including an idempotency key and a critical-extension indicator in at least one of the action request or the plurality of cryptographically linked receipts.

3 . The control architecture of claim 1 , wherein validating freshness comprises checking a nonce signed or attested over at least a portion of the action request, checking a monotonic counter against stored state, invalidating stored freshness state responsive to revocation, and outputting a refusal receipt when freshness cannot be established within an allowed uncertainty window.

4 . The control architecture of claim 1 , wherein determining the capability scope and the one or more temporal constraints further comprises computing or retrieving a risk score based on at least one of target-resource sensitivity, connector trust level, anomaly indicators, or recent refusal history, and tightening at least one scope dimension or temporal limit responsive to the risk score.

5 . The control architecture of claim 1 , wherein the instructions further cause the control architecture to maintain a delegation graph recording parent-child relationships among capability tokens or sessions and, responsive to a revocation event, traverse the delegation graph to perform at least one of subtree invalidation, partial-scope revocation, stale-proof detection, or downstream receipt generation.

6 . The control architecture of claim 1 , wherein registering the plurality of cryptographically linked receipts further comprises obtaining one or more witness co-signatures satisfying a threshold rule and anchoring at least one checkpoint commitment to an external timestamping service or immutable ledger.

7 . The control architecture of claim 6 , wherein the threshold rule requires two-of-three witness co-signatures, and wherein at least two of the three witnesses are operated by different administrative domains such that compromise of any one administrative domain is insufficient to satisfy the threshold rule.

8 . The control architecture of claim 1 , wherein the verification bundle comprises selectively disclosed fields, a commitment or proof showing that one or more undisclosed fields remain bound to a disclosed receipt digest, and an audience-bound pseudonymous identifier for at least one subject identifier.

9 . The control architecture of claim 1 , wherein, responsive to temporary unavailability of the append-only transparency log, the instructions further cause the control architecture to issue a provisional local receipt with a deferred-registration indicator, later register the provisional local receipt upon restoration of log connectivity, and emit a reconciliation receipt linking the provisional local receipt to a registered receipt.

10 . The control architecture of claim 1 , wherein one or more of the delegation receipt, the tool-use receipt, the consumption receipt, the refusal receipt, the promotion receipt, or the revocation receipt are signed using a structured signature container selected from: a Dead Simple Signing Envelope (DSSE), a CBOR Object Signing and Encryption (COSE) structure, or a JSON Object Signing and Encryption (JOSE) structure.

11 . A computer-implemented context-firewall subsystem for an agentic control architecture that uses linked receipts in an append-only transparency log, comprising:

one or more processors; and

memory storing instructions that, when executed by the one or more processors, cause the context-firewall subsystem to:

(a) receive instruction data over a control-plane instruction channel and tool output over a data-plane tool-output channel;

(b) parse the tool output into typed segments and assign each typed segment one of a plurality of trust-state tags comprising UNTRUSTED_DATA, CANDIDATE_PARAMETER, VERIFIED_EVIDENCE, EXECUTABLE_PARAMETER, PRIVILEGED_INSTRUCTION, or BLOCKED_CONTENT;

(c) store typed segments associated with different trust-state tags in different queues, buffers, or memory regions;

(d) apply one or more promotion rules that require schema conformance, provenance validation, digest matching, and policy approval before a typed segment can move from UNTRUSTED_DATA or CANDIDATE_PARAMETER state to EXECUTABLE_PARAMETER or PRIVILEGED_INSTRUCTION state;

(e) block direct execution of a typed segment that fails the one or more promotion rules and emit a refusal receipt including a reason code; and

(f) emit a promotion receipt or a tool-use receipt for a typed segment that satisfies the one or more promotion rules, such that later offline verification can determine whether tool output affected execution only through an approved control point.

12 . The context-firewall subsystem of claim 11 , wherein the instructions further cause the context-firewall subsystem to maintain separate parsing, storage, or retrieval paths for the control-plane instruction channel and the data-plane tool-output channel such that natural-language content from the data-plane tool-output channel cannot be inserted into a policy buffer or system-instruction buffer without passing through a promotion rule.

13 . The context-firewall subsystem of claim 11 , wherein the one or more promotion rules require that a typed segment correspond to an allowlisted output field declared in a verified connector descriptor for a connector that produced the tool output, conform to an allowlisted parameter grammar, and satisfy a control-point policy before the typed segment is promoted to EXECUTABLE_PARAMETER state.

14 . The context-firewall subsystem of claim 11 , wherein the instructions further cause the context-firewall subsystem to record, in the refusal receipt or the promotion receipt, a control-point identifier and a segment digest that enables a later verifier to determine whether a blocked or promoted typed segment originated from a verified connector output.

15 . A computer-implemented method for verifiable agentic execution against a protected resource, the method comprising:

receiving an action request from an agent;

verifying an identity credential bound to an agent-held cryptographic key to obtain a verified identity credential and validating proof-of-possession freshness;

canonicalizing selected request fields and computing a request digest using a domain-separated hash;

deriving, under at least one policy, a capability scope and one or more temporal constraints for the action request;

issuing a capability token cryptographically bound to the verified identity credential, the request digest, the capability scope, and the one or more temporal constraints;

verifying a connector descriptor for a connector selected to carry out at least a portion of the action request;

deriving an invocation scope as a constrained function of the capability scope, permissions declared in the connector descriptor, and policy constraints;

executing a connector call under an ephemeral access credential restricted to the invocation scope to obtain tool output;

applying a context firewall that prevents the tool output from becoming privileged instruction or executable parameter data absent satisfaction of a verification rule at a control point;

generating cryptographically linked receipts that include at least a delegation receipt, a tool-use receipt, and one or more of a consumption receipt, a refusal receipt, a promotion receipt, or a revocation receipt;

registering the cryptographically linked receipts in an append-only transparency log; and

offline verifying, using a verification bundle comprising at least the cryptographically linked receipts and one or more proofs obtained from the append-only transparency log, whether the action request was processed in accordance with the at least one policy.

16 . The method of claim 15 , wherein offline verifying comprises loading a machine-readable verification profile that specifies required receipt types, required control points, at least one witness threshold, at least one disclosure rule, and at least one completeness rule, and outputting a PASS, HOLD, or FAIL disposition responsive thereto.

17 . The method of claim 16 , wherein the machine-readable verification profile is cryptographically signed and one or both of (i) registered in the append-only transparency log such that the machine-readable verification profile is retrievable with an inclusion proof, and (ii) anchored to an external timestamping service or immutable ledger, and wherein offline verifying further comprises validating the signature and proving inclusion, anchoring, or both, as applicable, of the machine-readable verification profile before applying the machine-readable verification profile.

18 . The method of claim 15 , further comprising correlating, in the verification bundle, receipts generated by a plurality of organizations or tenants, including at least one third-party receipt generated by an auditor, a regulator, a customer-side monitor, or an independent measurement system.

19 . The method of claim 15 , wherein verifying the connector descriptor comprises verifying a signature chain to a trust root, evaluating an attestation measurement or build fingerprint, checking descriptor revocation or validity-window information, evaluating a software bill of materials digest, and enforcing endpoint pinning or sandbox-class constraints.

20 . A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause an agentic control system to:

receive an action request;

deterministically encode at least a portion of the action request and compute a request digest;

verify an identity credential to obtain a verified identity credential and issue a capability token cryptographically bound to the verified identity credential, the request digest, a least-privilege capability scope, and one or more temporal constraints;

verify a connector descriptor and derive an invocation scope narrower than or equal to the least-privilege capability scope;

execute a connector call to obtain tool output;

enforce a context firewall that blocks direct promotion of the tool output into privileged instruction state absent satisfaction of a verification rule;

generate a plurality of cryptographically linked receipts for at least delegation, invocation, and one or more of promotion, refusal, consumption, or revocation;

register the plurality of cryptographically linked receipts in an append-only transparency log; and

output a verification bundle that enables offline reconstruction of lineage for the action request.

21 . The non-transitory computer-readable medium of claim 20 , wherein the instructions further cause the agentic control system to compute a lineage hash from a receipt digest and one or more parent digests, to suppress duplicates using an idempotency key, and to treat an unknown critical extension as a condition for HOLD or FAIL rather than silent acceptance.

22 . The non-transitory computer-readable medium of claim 20 , wherein the verification bundle includes at least one privacy-preserving proof mode selected from a Merkle-subtree proof, a cryptographic commitment, a proof of range or rule satisfaction, or an audience-bound pseudonymous subject identifier.

23 . The non-transitory computer-readable medium of claim 20 , wherein the instructions further cause the agentic control system to output machine-readable reason codes indicating whether offline reconstruction failed because of evidence missing, signature invalidity, token revocation, descriptor untrustworthiness, output-digest mismatch, context-firewall violation, witness-threshold failure, or control-point incompleteness.