Trust infrastructure for AI agents that touch money.
Give an autonomous agent a wallet and you have given it authority. Zyndr lets you define that authority as an owner-signed boundary enforced on-chain, and emits a signed, reproducible receipt for every decision inside it.
session: loading
- Prevent
- The policy contract checks every intent before funds move.
- Prove
- Every decision, allowed or blocked, becomes a signed receipt.
The problem
An agent with a key has no idea what it is not allowed to do.
Models are probabilistic and their inputs are attacker-reachable. The moment an agent can sign, every piece of text it reads becomes a possible instruction to move funds. A guardrail that lives in the same process as the agent is a guardrail the agent can be talked past.
Prompt injection is an input problem
Untrusted text, page content and tool output all reach the model. Filtering helps. It is not a boundary.
Interception is bypassable
A check that sits in front of the agent stops being a check the moment execution finds another path.
Logs are not evidence
A record you write about yourself, and can also edit, is not something a third party can verify.
01 · Prevent
The boundary is a contract, not a prompt.
The owner signs the frame once: caps, allowlists, recipients. The agent proposes intents inside it. The policy contract is what decides, and it decides on-chain.
“A prompt-injected agent can't exceed its limits. The model only proposes intents (it never holds a key or signs), and every intent is checked on-chain by the policy contract before funds move; a transfer over the agent's cap or to a non-whitelisted address reverts at the contract level.”
“Even if the agent's automation key is stolen, it cannot move your funds outside the limits and allowlist you signed: a non-policy transfer is rejected at the smart-account validation layer on-chain. Proven against the real account on a mainnet-equivalent fork.”
Quoted verbatim from docs/SECURITY_CLAIMS.md, the repository's source of truth for public copy.
Decision path
on-chain authority- 01
Owner signs the frame
EIP-712. Caps, token and recipient allowlists. Changing it needs the owner key, never the agent's.
- 02
Agent proposes an intent
Structured, never raw calldata. The model holds no key and signs nothing.
- 03
Off-chain precheck
A mirror of the on-chain rule, checked early. It can reject a request, and letting one proceed is never authority to move funds.
- 04
On-chain validation
BLOCKEDThe policy contract independently re-checks and reverts if the action leaves the frame.
“Simulation is a mandatory pre-broadcast security gate. It can reject an action, but it never authorizes one. PolicyModule independently enforces the owner's boundary on-chain.”
This is easier to watch than to read. Three requests, one owner-signed boundary, and the path each of them travels.
Watch the boundary hold02 · Prove
A decision nobody can verify is not evidence.
Every decision the policy engine reaches, whether allowed, blocked, or held for confirmation, is emitted as an EIP-712 signed Action Receipt. The interesting one is the block: a record that a dangerous action was stopped, in a form a third party can check without taking your word for it.
Signed, structured, comparable
The verdict and a structured reason code are signed fields, not free text, so a block is machine-checkable and comparable across receipts.
Pinned to the state that decided
The receipt commits the policy snapshot and the evaluation block, so a decision can be reproduced against the state that produced it rather than today's.
Verification does not start from trusting us
The signed core is reproducible from the receipt and public chain data, and the policy contract is the authority either way.
Observation never gates enforcement
Receipt emission is asynchronous by design. A failed emission can never block an allowed action, nor un-block a blocked one.
Action Receipt · EIP-712
- schema_version
- 1
- chain_id
- 84532Base Sepolia
- verdict
- BLOCKED
- reason_code
- structured enumnot free text
- intent_digest
- 0x9c4f…e2a1
- policy_snapshot_ref
- 0x1d70…b8c4policy state at eval_block
- eval_block
- 42,842,803
- policy_module_address
- 0xac03…F1cc
- context_hash
- 0x7ae5…09fd
- causal_status
- CAUSAL
- attestation_key_id
- 0x3b1c…77de
Schema specimen: field names are the signed struct, values are illustrative.
signed03 · In practice
Approve the boundary once. Not every action.
The alternative to signing everything is not signing nothing. The owner defines the frame, the agent operates freely inside it, and anything that would leave it is stopped and recorded.
Define
Set per-transaction and daily caps, allowed tokens and allowed recipients. Sign once with the owner key.
Delegate
The agent gets an automation key scoped to one call shape. It can act continuously, without you.
Enforce
Each action is validated on-chain against the frame. Out-of-policy actions revert at the contract.
Evidence
Each decision leaves a signed receipt you can export, keep, and hand to a third party.
04 · Honest limits
What Zyndr does not do.
Security infrastructure that publishes only its strengths is marketing. These limits are recorded in the repository and repeated here for the same reason they exist there: an integrator has to be able to reason about the real boundary.
Your owner key is the principal
“Your owner key controls your agent's policy, so guard it like a bank login. Zyndr bounds what a tricked agent or the day-to-day automation key can do (on-chain); it does not remove the risk of losing your own master key.”
Simulation can reject, never authorize
Every action is simulated exactly as it will be sent, and the broadcast is stopped if that rehearsal reverts, the simulator is unreachable, or no result comes back. The gate can reject an action; it never authorizes one. PolicyModule independently enforces the owner's boundary on-chain, and the signed simulation hash is still a placeholder rather than a verified commitment.
The multisig retains a timelocked upgrade power
Policy-module upgrades can be proposed by the multisig through a 7-day timelock that is visible on-chain. It is a real power, disclosed rather than hidden.
This is a testnet
Everything above runs on Base Sepolia. No mainnet deployment exists, and nothing on this page should be read as one.
05 · Who this is for
Built for the teams that carry the risk.
Protocol teams
Bound what an autonomous strategy can do with treasury funds on-chain, rather than in a runbook.
Agent platforms
Ship agents that can transact without inheriting the blast radius of an unbounded key.
Wallet & security teams
A policy layer and a receipt format to integrate against, not another wallet to compete with.
Enterprise buyers
Evidence of what an autonomous system did and did not do, in a form an auditor can check.
Try the frame on a live testnet.
Connect a wallet, create an agent, set its boundary, and watch an out-of-policy action get stopped at the contract. Base Sepolia, no real funds.
session: loading