Security
How Thirdfy protects users and enforces policy. Intent-based security, delegation modes, and best practices for Execute Intents.
Overview
Thirdfy is the governance layer between AI agents and user capital. Security is enforced at the Execute Intent layer — validation before execution, programmable mandates, and verifiable audit trails. We protect both humans and agents: when users delegate to agents, and when agents hire other agents. Same policy engine, same validation.
Where Thirdfy Fits
Intent-Based Security
We verify what actions are allowed, not just who holds keys. Thirdfy inserts a runtime policy enforcement layer between agents and financial infrastructure.
- Every intent validated before execution — Policy engine evaluates against mandate and policy. Compliant = authorized. Not compliant = rejected.
- Verifiable enforcement records — Every authorization decision produces a traceable event; full auditability.
- Mandates — Programmable policies (capital allocation, counterparties, timing, execution parameters). See Policy & Mandates.
Signing Moments
What does the user sign? Depends on execution mode:
| Mode | User signs | Format |
|---|---|---|
| Non-custodial (ERC-7710) | Delegation grant (scope, expiry) | EIP-712 typed message |
| Execution (per intent) | On-chain transaction | Signed tx (user's wallet or custody platform) |
For non-custodial flows: users sign an EIP-712 delegation message to authorize an agent within scope and time limits. At execution time, the user's wallet (or their custody platform) signs the actual on-chain transaction. Thirdfy never holds signing keys.
Where do custody platforms get inserted? Thirdfy sits above your custody layer. We validate intents; your custody platform holds keys and executes. Policy checks and approvals happen at Thirdfy (validation) and at your custody layer (your rules). See Enterprise Use Cases → Custody Platforms.
Custody Boundary
Does Thirdfy ever custody assets? No. Thirdfy never holds user funds in a pool or shared account.
Where do funds sit? In user-owned wallets. For x402 custodial flows, funds sit in a provider server wallet — a per-user wallet that the user owns. Thirdfy does not hold the funds; ownership remains with the user. For non-custodial flows, funds stay in the user's own wallet or their custody platform.
Who can unilaterally move funds? Only the key holder — the user (via their wallet) or the user's custody provider. Thirdfy cannot move funds. We validate intents; the key holder executes.
Delegation Modes
Users delegate to agents before execution. Two execution modes:
| Mode | Description |
|---|---|
| x402 custodial | Thirdfy-managed. Credits and execution flow through Thirdfy infrastructure. |
| Non-custodial (ERC-7710) | User holds keys. Delegation is scoped and time-limited via supported wallets. Status: active, expired, revoked. |
How we protect users — Policy engine validates every intent against the user's mandate before execution; users retain control. See Execute Intents for delegation details.
Revocation
Users can revoke delegation at any time. Revocation stops future authorizations — no new intents reach the user. Pending executions (tx not yet signed) are cancelled. Transactions already broadcast complete; revocation does not affect them. Every revocation is recorded for audit.
Smart Contract Security
For smart contract audits, monitoring, and addresses, see:
- Audits — Audit reports for core protocol and integrated systems
- Contracts — Contract addresses, Hexagate monitoring, developer resources
Best Practices
- Scope delegation — Use time-limited, action-scoped mandates.
- Review allowlists — Ensure agent actions match your risk tolerance.
- Monitor activity — Check execution history and delegation status.
Security Contact
For security issues or responsible disclosure: security@thirdfy.com or via Discord.