Proxy-Execution Agents

• Proxy-Execution Agents (PEAs) are autonomous software actors that execute delegated tasks within strict, verifiable, and cryptographically controlled boundaries.
• They integrate components like secure enclaves, notarized receipts, and policy engines to ensure task authenticity and auditability across diverse systems.
• Their architectures, seen in systems like TessPay and Faramesh, combine explicit mandates, isolated execution, and audit trails, making them vital for reliable multi-agent operations.

A Proxy-Execution Agent (PEA) is an autonomous system component or software actor that executes user-delegated tasks or external tool interactions within a formally constrained, controllable, and evidentiated boundary. The unifying property of a PEA is that it does not act directly in the principal’s name by default; rather, it stands as a proxy, running only within narrowly-scoped, verifiable mandates, often producing strong cryptographic evidence or proofs of its actions for subsequent validation or audit. PEAs underpin a contemporary shift in agent system design, from implicit trust to verifiable execution, with applications spanning blockchain-based agents, ML engineering workflows, agentic commerce, and enterprise automation (Goenka et al., 30 Jan 2026, Alqithami, 8 Jan 2026, Yuan et al., 6 Nov 2025, Grigor et al., 17 Dec 2025).

1. Formal Characteristics and Definitions

PEAs generalize the notion of a controlled delegator for action execution, distinguished by explicit, machine-enforceable boundaries:

• In the agentic commerce context (e.g., TessPay), a PEA is an autonomous actor registered under a unique agent identifier, holding no direct key custody, operating under a cryptographically scoped mandate (e.g., an Agent-JWT tied to a user-signed intent), and executing within a Trusted Execution Environment (TEE) or a notarized glass-box like TLSNotary. PEAs emit verifiable receipts before any access to escrowed funds; payment occurs only if the Proof of Task Execution (PoTE) passes predicate checks (Goenka et al., 30 Jan 2026).
• On blockchains, a PEA realizes delegated, scoped execution: an agent receives narrowly-bounded authority (session key, policy module) from a principal. It plans and evaluates intents, consults a policy engine, and then emits on-chain transactions only if all policy constraints are met, with all actions accompanied by signed approvals (Policy Decision Records) (Alqithami, 8 Jan 2026).
• In system architectures like Faramesh, PEAs are governed by a policy-enforcing control plane that canonicalizes and normalizes all agent intents, mandates passage through a non-bypassable Action Authorization Boundary (AAB), and produces signed decision artifacts for every executed action. Action provenance is captured in an append-only ledger keyed by canonical hashes (Fatmi, 25 Jan 2026).
• In compositional verification frameworks (e.g., VET), PEAs proxy all agent-external computations through an isolated proof generator (TEE, succinct cryptographic proof, or notarized TLS transcript), with the agent’s configuration and its proof/verification stack formalized in an Agent Identity Document (AID) (Grigor et al., 17 Dec 2025).
• In multi-agent or ML engineering settings (ArchPilot, RP-ReAct), proxies mediate execution or scoring of candidate solutions or tool-invocations, decoupling orchestration and evaluation (Yuan et al., 6 Nov 2025, Molinari et al., 3 Dec 2025).

2. Typical Architectures and Workflow Protocols

PEA-based architectures share several structural invariants, often decomposed into orthogonal planes or agents:

Component	Purpose	Mechanism
Delegation & Mandate	Define user-scoped authority, policy, or budget	User-signed mandates, Transaction Intent Schemas, Agent-JWTs
Registration & Anchoring	Assign agent identity and scoping	Canonical registry (on-/off-chain), AID
Execution	Enact task or run tool call securely	TEE, TLSNotary, controlled containers, protocol interpreter (Petri net model), sandbox
Evidence Generation	Emit cryptographic or protocol receipts	TEE attestations, TLS receipts, Merkle anchors, SNARK/STARK, Web Proofs
Verification & Settlement	Authenticate proofs; authorize further steps	Predicate checks, smart contract predicates, PERMIT/DEFER/DENY protocol, audit trails
Auditability	Provide tamper-evident trail for post hoc dispute	Merkle-tree-anchored logs, hash-chained ledgers, session transcripts in AID

Workflows generally encompass: (1) intent capture and delegation; (2) agent anchoring or discovery; (3) mandate-constrained execution in a secure/provable context; (4) cryptographically authenticated proof construction; (5) validation and, if appropriate, release of resources or value; and (6) audit and dispute capabilities. For example, TessPay operationalizes escrow via a two-plane model: (I) Control/Verification handles mandate registration and PoTE validation, (II) Payment/Settlement manages escrowed funds via chain-agnostic adapters, releasing only upon valid proof (Goenka et al., 30 Jan 2026). Faramesh interposes an authorization boundary and hashes all normalized actions for deterministic, replayable audit (Fatmi, 25 Jan 2026). On open systems, protocols can be transmitted and installed as extended Petri nets, statically analyzed for resource and privacy safety before enabling operational semantics (token game) (Silva et al., 2014).

3. Cryptographic and Verifiable Execution Foundations

A defining property of PEAs is cryptographically verifiable execution:

• In TessPay, PoTEs aggregate TLSNotary receipts, TEE attestations, JWT integrity hashes, and telemetry logs into a tuple. Verification is strictly predicate-based: conjunctive checks on TLS, TEE, JWT hash equality, and MerkleRoot equivalence govern fund release (Goenka et al., 30 Jan 2026).
• VET formalizes the agent’s compositional authentication scheme. Each step in the agent’s trace is accompanied by a proof (π)—originating from a TEE, a SNARK/STARK over a deterministic relation, or a TLSNotary artifact. The Agent Identity Document (AID) pinpoints the exact implementation and verifies code signatures. Web Proofs (Notarized TLS Transcripts) dominate for LLM or confidential API calls, while TEE Proxies are used for public tools. Overhead is measured at 1–3× over unprotected calls for strong privacy (Grigor et al., 17 Dec 2025).
• On blockchains, signed Policy Decision Records (PDRs) affirm that Transaction Intent Schemas (TIS) have been properly vetted prior to transaction signing. This guards against signature replay and illicit use of delegated keys (Alqithami, 8 Jan 2026).

4. Policy, Safety, and Threat Mitigation

A core rationale for PEAs is robust enforcement of both operational constraints and adversarial resistance. Examined frameworks address various attack vectors:

• TessPay’s tiered security model allows for rapid, bulk settlements with lower proof requirements (A-JWT, batch), or slower, high-assurance settlements using full PoTEs (TEE, TLSNotary, multi-witness) (Goenka et al., 30 Jan 2026). Threats considered include phantom deposits (oracle manipulation), payout without verification, key exfiltration, and cross-rail queue replay.
• Faramesh’s non-bypassable AAB mandates that every side-effecting action passes deterministic, fail-closed policy evaluation (executes only if PERMIT), with full provenance logging. Even in the event of orchestration compromise, executors cannot run any action lacking a valid, signed decision artifact (Fatmi, 25 Jan 2026).
• Blockchain agent systems highlight session-key compromise, policy bypass, nonce attacks, MEV ordering exploits, and collusion among verifiers as major risks. Layered defense via policy modules, intent schema, audit trail, and recovery features (e.g., key revocation, module kill-switch) are surveyed, with current gaps including the lack of fully standardized TIS/PDRs and limited fine-grained recovery (Alqithami, 8 Jan 2026).
• In Petri-net-driven open MAS (multi-agent systems), PEAs statically analyze protocol extensions for syntax, loop safety, and privacy via Action Templates, aborting or rejecting unsafe extensions (Silva et al., 2014).

5. Generalization to Multi-Agent, ML, and Enterprise Contexts

The PEA paradigm extends beyond value transfer and policy enforcement into ML and automation domains:

• In RP-ReAct, PEAs are ReAct-based executors: given sub-questions from a strategic planner, PEAs translate and invoke tools, handling low-level syntax and external storage of large responses to maintain context stability. They return aggregate observations, implementing context-bounding and response externalization for reliability and efficiency. Empirical results indicate a sub-step accuracy of 87–92%, reduced context growth by ~45%, and increased final task success by 12% on ToolQA tasks (Molinari et al., 3 Dec 2025).
• In ArchPilot, Proxy-Execution Agents act as adaptive evaluators for machine learning model search. Candidate architectures undergo proxy-based evaluation (single-epoch training, rapid robustness metrics) mediated by a proxy registry and an updatable weighted aggregator. The orchestration agent combines this rapid proxy signal with slower ground-truth (full training) metrics, switching modes as budget allows. The MCTS-style search is restarted as soon as the proxy-weights shift significantly, maintaining fidelity and efficiency (Yuan et al., 6 Nov 2025).

6. Standards, Interoperability, and Open Challenges

PEAs drive the need for standardized representation and attestation formats:

• Transaction Intent Schema (TIS) and Policy Decision Records (PDR) are proposed as machine-portable, verifiable interfaces for cross-system interoperability. However, real-world adoption is hampered by format fragmentation, underdeveloped cross-chain policy synchronization, and weak support for automated recovery and kill-switch mechanisms (Alqithami, 8 Jan 2026).
• Append-only audit trails, canonical action normalization (e.g., in Faramesh via Canon(I) → Â), and public commitment anchoring ensure replayability, non-repudiation, and post hoc verification across agent ecosystems (Fatmi, 25 Jan 2026, Goenka et al., 30 Jan 2026).
• In open multi-agent systems, protocol transmission via extended Petri nets supports dynamic, runtime protocol extension but requires NP-hard static analysis and trustworthy guarantee-handling subnets, motivating further improvements in automated protocol vetting (Silva et al., 2014).

7. Evaluation Metrics and Tiered Service Models

Performance and reliability are measured by empirically instantiated metrics:

• Safety/Security: Prompt Injection Resistance (fraction of adversarial manipulations rejected), MEV Vulnerability (economic slippage), and recovery from partial-failures (Alqithami, 8 Jan 2026).
• Task Reliability: Sub-step translation accuracy, context utilization, execution stability (variance across models) (Molinari et al., 3 Dec 2025).
• Economic Robustness: Execution quality (realized/optimal price), slippage bound satisfaction (Alqithami, 8 Jan 2026).
• Telemetry: Latency, token usage, success/failure rates, Service Level Agreement (SLA) adherence (Goenka et al., 30 Jan 2026).
• Proof Verification Overhead: Baseline is 1.0×–1.2× for TEE Proxy, up to 3× for Web Proofs on sensitive API calls (Grigor et al., 17 Dec 2025).

Tiered service strategies in PEAs allow agents and deployers to balance cost, latency, and security—for example, TessPay’s three levels (A-JWT only, full PoTE, multi-witness), or switching between proxy and ground-truth evaluation in proxy-based ML search engines (Goenka et al., 30 Jan 2026, Yuan et al., 6 Nov 2025).

---

Proxy-Execution Agents thus function as cryptographically-controlled, evidence-generating boundaries for agentic action—enabling high-assurance autonomy in environments ranging from value-bearing ledgers and agentic commerce to enterprise automation and ML workflow optimization. Their design intertwines fine-grained authority, rigorous execution provenance, and compositional proof frameworks, with research priorities centered on standards adoption, adversarial robustness, and efficient, scalable verification (Goenka et al., 30 Jan 2026, Alqithami, 8 Jan 2026, Yuan et al., 6 Nov 2025, Fatmi, 25 Jan 2026, Grigor et al., 17 Dec 2025, Molinari et al., 3 Dec 2025, Silva et al., 2014).