# Security Readiness

> Evidence-backed security guidance for agents and builders choosing smart-account, protocol, paymaster, automation, and agent-transaction stacks.

- Status: draft
- Review status: unreviewed
- Last verified: 2026-06-10

## Why it matters

Builders and agents often treat security as a generic audit checkbox. Security-sensitive crypto apps need clearer separation between contract audits, deployment verification, smart-account permissions, paymaster policy limits, agent spend controls, source provenance, and operational fallback paths before a stack can be recommended for production.

## Candidate change areas

### security agent transaction safety surface
- Status: watch
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Agent-controlled transactions require explicit authority boundaries, spend limits, replay protection, identity or validation signals, and monitoring before production use.
- Possible consequences:
  - Agent wallets should have bounded permissions, spending policies, replay-safe order IDs, expiry windows, and cancellation or recovery paths.
  - Payment rails and trust registries do not replace fulfillment, escrow, dispute handling, or incident response for agentic commerce.
  - Agents should cite whether identity, reputation, validation, payment, and wallet-permission claims come from separate protocols.

### security deployment verification surface
- Status: watch
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Production recommendations should verify chain-specific deployments, contract addresses, source repositories, release provenance, admin controls, and known advisories before claiming support.
- Possible consequences:
  - EVM compatibility should not be treated as proof that a protocol has a live, supported, production-ready deployment on a specific chain.
  - Agents should distinguish docs links, SDK repositories, audited contracts, deployment addresses, source maps, advisories, and release provenance.
  - Admin keys, upgradeability, pausing, and emergency controls should be reviewed alongside contract addresses before production use.

### security paymaster policy surface
- Status: watch
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Paymaster and gas-sponsorship flows need policy limits, billing controls, abuse monitoring, and fallback behavior before they are safe to expose to users or agents.
- Possible consequences:
  - Sponsored transactions should define who pays, which actions are eligible, how limits are enforced, and what happens when limits are exhausted.
  - Apps should implement fallback paths for actions that should proceed without sponsorship, and hard failure paths for actions that should never bypass policy.
  - Agents should not describe gasless UX as free execution without checking quotas, billing, chain support, abuse controls, and paymaster failure modes.

### security smart account permission surface
- Status: watch
- Action: assess
- Recommendation strength: actionable
- Priority: high
- Summary: Smart-account security depends on owners, validators, modules, session-key permissions, recovery paths, and upgrade or admin authority, not only the wallet SDK.
- Possible consequences:
  - Agents should ask for owner model, validator or module choices, recovery assumptions, and target chains before recommending a smart-account path.
  - Session keys and delegated permissions should include contract allowlists, method allowlists, spend caps, rate limits, and expirations.
  - Recovery and upgrade authority should be treated as production security surfaces, not onboarding details.

## Initiative intents

- **Assess smart-account security** (assess-smart-account-security) — Review account owners, validators, modules, permissions, session keys, recovery, paymasters, and fallback behavior before recommending a smart-account stack.
- **Assess agent transaction safety** (assess-agent-transaction-safety) — Check spend caps, delegated permissions, replay protection, payment authorization, identity and validation signals, and monitoring before allowing agents to transact.
- **Verify protocol deployments and sources** (verify-protocol-deployments-and-sources) — Confirm docs, contract addresses, source maps, release provenance, audits, advisories, and chain-specific deployment support before production recommendations.

## Official sources

- [OpenZeppelin Contracts documentation](https://docs.openzeppelin.com/contracts/5.x/)
- [OpenZeppelin access control documentation](https://docs.openzeppelin.com/contracts/5.x/access-control)
- [Safe documentation](https://docs.safe.global/)
- [ZeroDev gas sponsorship documentation](https://docs.zerodev.app/smart-accounts/sponsor-gas/evm)
- [ZeroDev permissions and session keys documentation](https://docs.zerodev.app/smart-accounts/permissions/intro)
- [Biconomy documentation](https://docs.biconomy.io/)
- [ERC-8004 draft specification](https://eips.ethereum.org/EIPS/eip-8004)
- [x402 documentation](https://www.x402.org/)

## What the agent receives

```json
{
  "initiative": "security-readiness",
  "name": "Security Readiness",
  "status": "draft",
  "registry_version": "2026.06.10-8752c9d",
  "supported_intents": [
    {
      "id": "assess-smart-account-security",
      "title": "Assess smart-account security",
      "related_changes": [
        "security-smart-account-permission-surface",
        "security-paymaster-policy-surface",
        "security-deployment-verification-surface"
      ]
    },
    {
      "id": "assess-agent-transaction-safety",
      "title": "Assess agent transaction safety",
      "related_changes": [
        "security-agent-transaction-safety-surface",
        "security-smart-account-permission-surface",
        "security-paymaster-policy-surface"
      ]
    },
    {
      "id": "verify-protocol-deployments-and-sources",
      "title": "Verify protocol deployments and sources",
      "related_changes": [
        "security-deployment-verification-surface"
      ]
    }
  ],
  "changes": [
    {
      "id": "security-agent-transaction-safety-surface",
      "type": "protocol_architecture",
      "status": "watch",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "ai_agents",
        "agentic_app_builders",
        "security_reviewers",
        "app_builders"
      ],
      "possible_consequences": [
        "Agent wallets should have bounded permissions, spending policies, replay-safe order IDs, expiry windows, and cancellation or recovery paths.",
        "Payment rails and trust registries do not replace fulfillment, escrow, dispute handling, or incident response for agentic commerce.",
        "Agents should cite whether identity, reputation, validation, payment, and wallet-permission claims come from separate protocols."
      ],
      "evidence_refs": [
        "official:erc-8004-eip",
        "official:x402-docs",
        "official:zerodev-permissions"
      ]
    },
    {
      "id": "security-deployment-verification-surface",
      "type": "external_reference",
      "status": "watch",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "protocol_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "possible_consequences": [
        "EVM compatibility should not be treated as proof that a protocol has a live, supported, production-ready deployment on a specific chain.",
        "Agents should distinguish docs links, SDK repositories, audited contracts, deployment addresses, source maps, advisories, and release provenance.",
        "Admin keys, upgradeability, pausing, and emergency controls should be reviewed alongside contract addresses before production use."
      ],
      "evidence_refs": [
        "official:openzeppelin-contracts-docs",
        "official:safe-docs"
      ]
    },
    {
      "id": "security-paymaster-policy-surface",
      "type": "protocol_architecture",
      "status": "watch",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "app_builders",
        "wallet_teams",
        "security_reviewers",
        "ai_agents"
      ],
      "possible_consequences": [
        "Sponsored transactions should define who pays, which actions are eligible, how limits are enforced, and what happens when limits are exhausted.",
        "Apps should implement fallback paths for actions that should proceed without sponsorship, and hard failure paths for actions that should never bypass policy.",
        "Agents should not describe gasless UX as free execution without checking quotas, billing, chain support, abuse controls, and paymaster failure modes."
      ],
      "evidence_refs": [
        "official:zerodev-sponsor-gas",
        "official:biconomy-docs"
      ]
    },
    {
      "id": "security-smart-account-permission-surface",
      "type": "protocol_architecture",
      "status": "watch",
      "priority": "high",
      "recommended_action": "assess",
      "recommendation_strength": "actionable",
      "affected_roles": [
        "wallet_teams",
        "app_builders",
        "security_reviewers",
        "ai_agents"
      ],
      "possible_consequences": [
        "Agents should ask for owner model, validator or module choices, recovery assumptions, and target chains before recommending a smart-account path.",
        "Session keys and delegated permissions should include contract allowlists, method allowlists, spend caps, rate limits, and expirations.",
        "Recovery and upgrade authority should be treated as production security surfaces, not onboarding details."
      ],
      "evidence_refs": [
        "official:safe-docs",
        "official:zerodev-permissions",
        "official:openzeppelin-access-control"
      ]
    }
  ]
}
```

---
Canonical: https://composewith.eth/initiatives/security-readiness · JSON: https://composewith.eth/initiatives/security-readiness/index.json