---
title: Proxy-Execution Agents
url: https://www.emergentmind.com/topics/proxy-execution-agents-peas
type: topic
---

# Proxy-Execution Agents

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 [2602.00213][2601.04583][2511.03985][2512.15892].

## 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 [2602.00213].
- 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) [2601.04583].
- 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 [2601.17744].
- 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) [2512.15892].
- 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 [2511.03985][2512.03560].

## 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 [2602.00213]. Faramesh interposes an authorization boundary and hashes all normalized actions for deterministic, replayable audit [2601.17744]. 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) [1403.0429].

## 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 [2602.00213].
- 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 [2512.15892].
- 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 [2601.04583].

## 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) [2602.00213]. 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 [2601.17744].
- 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 [2601.04583].
- 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 [1403.0429].

## 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 [2512.03560].
- 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 [2511.03985].

## 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 [2601.04583].
- 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 [2601.17744][2602.00213].
- 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 [1403.0429].

## 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 [2601.04583].
- Task Reliability: Sub-step translation accuracy, context utilization, execution stability (variance across models) [2512.03560].
- Economic Robustness: Execution quality (realized/optimal price), slippage bound satisfaction [2601.04583].
- Telemetry: Latency, token usage, success/failure rates, Service Level Agreement (SLA) adherence [2602.00213].
- Proof Verification Overhead: Baseline is 1.0×–1.2× for TEE Proxy, up to 3× for Web Proofs on sensitive API calls [2512.15892].

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 [2602.00213][2511.03985].

---

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 [2602.00213][2601.04583][2511.03985][2601.17744][2512.15892][2512.03560][1403.0429].

Source: https://www.emergentmind.com/topics/proxy-execution-agents-peas