Loading…
Execution Protocol
One message in. One verifiable outcome out.
Every action is enforced before execution and proven after.
Enforcement before commit. Cryptographic receipts. Independently verifiable.
Every terminal outcome emits a signed receipt. The audit trail survives the failure.
Open specification · CC BY 4.0
curl https://executionprotocol.dev/api/sandbox/execute \
-H "Content-Type: application/json" \
-H "EP-Mode: sandbox" \
-d '{
"archetype": "PAYMENT_TRANSFER",
"constraints": {
"recipient": "vendor/acme_corp",
"amount_usd": "9200.00",
"max_total_usd": "1000.00"
}
}'curl https://executionprotocol.dev/api/sandbox/execute \
-H "Content-Type: application/json" \
-H "EP-Mode: sandbox" \
-d '{
"archetype": "PAYMENT_TRANSFER",
"constraints": {
"recipient": "vendor/acme_corp",
"amount_usd": "9200.00",
"max_total_usd": "1000.00"
}
}'The gap
Agent execution layer
Natural language converted to a structured message
Pre-commit policy evaluated at the Authorization Boundary
Once-only execution; commit and authorization separated
Hash-chained, KMS-signed, verifiable offline
Capabilities
One structured intent in, one terminal outcome out. No multi-turn handshake, no session state, no orchestration framework wrapped around the request.
Natural language is converted to a structured message before policy evaluation. The LLM never reaches the authorization path.
Incomplete inputs receive a machine-readable completion response, not an error. The agent fixes and resubmits as a fresh interaction. No rejection path, no error-code maze.
Pre-commit policy evaluated against the structured request. Hard-deny list, scoped delegation bounds, approval-chain routing.
Execute, refuse, block — every terminal state ends with a hash-chained, KMS-signed receipt that any third party can verify offline against the public key.
PANs and CVVs are refused at the input boundary. Only tokenised payment-intent IDs from PSP-controlled flows cross. Whether this reduces a merchant’s PCI scope depends on the full payment architecture and the merchant’s QSA assessment.
Every outcome leaves a record
The protocol committed the action. The receipt records the committed state, the full pipeline audit chain, and the signed proof of commitment.
The input did not satisfy the schema. The receipt records which fields were missing and the candidate values to complete them. The agent resubmits a corrected message in a fresh interaction — the protocol prohibits rejection.
A boundary or delegation rule fired before commit. The receipt is still signed and audit-chained — the proof that the gateway blocked, not lost the request.
Where it fits
Discovery and message-passing are solved problems. What happens between intent and outcome — authorization, policy, proof — is not.
This compares native protocol primitives, not what you can layer on top. A REST API can be wrapped in middleware that signs responses or enforces policy — that doesn’t make signing or policy a REST primitive. The question is what the protocol itself contracts for.
| Capability | Execution | A2A | MCP | ACP | REST |
|---|---|---|---|---|---|
| Pre-commit policy primitive | |||||
| Signed-receipt primitive | |||||
| Scoped-delegation primitive | |||||
| Hash-chain audit primitive | |||||
| Tool-discovery primitive | |||||
| Multi-agent-communication primitive | |||||
| Stateless-request constraint |
Architectural position
Models generate intentions. Execution Protocol turns intentions into actions, with proof.
Open specification, protected implementation. The message format, receipt schema, and verification rules are public. The gateway and policy engine that run them are built on filed patents covering deterministic agent authorization.
Why it matters
For CTOs
For CISOs and security teams
Read the spec. Run the sandbox. Ship safer agents in production.