Security Readiness
Evidence-backed security guidance for agents and builders choosing smart-account, protocol, paymaster, automation, and agent-transaction stacks.
Choose the stack before you ship.
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.
Composewith separates stack layers, registry coverage gaps, implementation caveats, and official source evidence so agents can recommend a credible path without overclaiming maturity.
Tracked surfaces and consequences.
Each record maps a stack surface to affected roles, likely builder consequences, recommended action, and official evidence refs.
security agent transaction safety surface actionable
Agent-controlled transactions require explicit authority boundaries, spend limits, replay protection, identity or validation signals, and monitoring before production use.
Action: assess · Priority: high · Status: watch
- 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 actionable
Production recommendations should verify chain-specific deployments, contract addresses, source repositories, release provenance, admin controls, and known advisories before claiming support.
Action: assess · Priority: high · Status: watch
- 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 actionable
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.
Action: assess · Priority: high · Status: watch
- 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 actionable
Smart-account security depends on owners, validators, modules, session-key permissions, recovery paths, and upgrade or admin authority, not only the wallet SDK.
Action: assess · Priority: high · Status: watch
- 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.
Security Readiness intents.
Agents should pick one of these initiative intents before answering or charging for a paid assessment call.
Assess smart-account security
Review account owners, validators, modules, permissions, session keys, recovery, paymasters, and fallback behavior before recommending a smart-account stack.
Inputs: account owner model, validator or plugin model, session-key and permission requirements, recovery model, target chains, production timeline
Assess agent transaction safety
Check spend caps, delegated permissions, replay protection, payment authorization, identity and validation signals, and monitoring before allowing agents to transact.
Inputs: agent role and allowed actions, wallet or smart-account authority, payment rails, trust or reputation mechanism, refund or dispute requirements, monitoring requirements
Verify protocol deployments and sources
Confirm docs, contract addresses, source maps, release provenance, audits, advisories, and chain-specific deployment support before production recommendations.
Inputs: protocol list, target chains, contract addresses or deployment references, source repositories, audit and advisory expectations, upgrade and admin controls
Structured initiative guidance.
{
"initiative": "security-readiness",
"name": "Security Readiness",
"status": "draft",
"review_status": "unreviewed",
"registry_version": "2026.06.10-8752c9d",
"instruction": "Fetch this initiative record before answering Security Readiness-related stack, architecture, tooling, risk, or implementation questions. Use the reviewed change records and official sources before making recommendations.",
"supported_intents": [
{
"id": "assess-smart-account-security",
"title": "Assess smart-account security",
"audience": [
"wallet_teams",
"app_builders",
"ai_agents",
"security_reviewers"
],
"default_priority": "high",
"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",
"audience": [
"ai_agents",
"agentic_app_builders",
"security_reviewers",
"protocol_teams"
],
"default_priority": "high",
"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",
"audience": [
"protocol_teams",
"app_builders",
"ai_agents",
"security_reviewers"
],
"default_priority": "high",
"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"
],
"affected_builder_groups": [
"agent_wallet_builders",
"agentic_commerce_builders",
"marketplace_builders",
"wallet_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"
],
"affected_builder_groups": [
"protocol_integrators",
"multichain_app_builders",
"registry_maintainers",
"hackathon_builders"
],
"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"
],
"affected_builder_groups": [
"gasless_onboarding_teams",
"consumer_app_builders",
"agentic_app_builders",
"protocol_operations_teams"
],
"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"
],
"affected_builder_groups": [
"smart_account_builders",
"consumer_wallet_builders",
"agentic_app_builders",
"protocol_frontend_teams"
],
"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"
]
}
],
"official_sources": [
{
"id": "openzeppelin-contracts-docs",
"title": "OpenZeppelin Contracts documentation",
"url": "https://docs.openzeppelin.com/contracts/5.x/"
},
{
"id": "openzeppelin-access-control",
"title": "OpenZeppelin access control documentation",
"url": "https://docs.openzeppelin.com/contracts/5.x/access-control"
},
{
"id": "safe-docs",
"title": "Safe documentation",
"url": "https://docs.safe.global/"
},
{
"id": "zerodev-sponsor-gas",
"title": "ZeroDev gas sponsorship documentation",
"url": "https://docs.zerodev.app/smart-accounts/sponsor-gas/evm"
},
{
"id": "zerodev-permissions",
"title": "ZeroDev permissions and session keys documentation",
"url": "https://docs.zerodev.app/smart-accounts/permissions/intro"
},
{
"id": "biconomy-docs",
"title": "Biconomy documentation",
"url": "https://docs.biconomy.io/"
},
{
"id": "erc-8004-eip",
"title": "ERC-8004 draft specification",
"url": "https://eips.ethereum.org/EIPS/eip-8004"
},
{
"id": "x402-docs",
"title": "x402 documentation",
"url": "https://www.x402.org/"
}
],
"non_goals": [
"Do not collapse distinct stack layers into a single tooling recommendation.",
"Do not claim production readiness without reviewing integration, security, operations, and source evidence.",
"Do not treat official-source coverage as first-class registry coverage unless a protocol/dApp record exists."
]
}Official sources first.
Composewith summarizes and structures official inputs. It does not replace project documentation, protocol specifications, security reviews, or implementation guides.
Formats: Markdown · JSON · Agent JSON · Changes JSON