  
**Over the last \~3 years, builders have created more than 100M policies on Turnkey.** These are allow or deny policies that gate onchain transactions and are enforced inside the same secure enclaves where signing occurs. They protect transactions with hardened rules, ensuring unauthorized ones are rejected before a signature can be produced.

Nearly all policy activity comes down to five repeatable patterns: embedded wallet defaults, transaction firewalls using contract, function, and destination allowlists, cross-chain agent permission matrices, platform RBAC, and explicit export and portability grants.

But as use cases become more advanced, these policies are also becoming more granular. Builders are moving from broad signing permissions toward controls scoped to specific chains, contracts, functions, destinations, transaction values, roles, and action types.

Our data suggests that wallet security is moving from broad access controls toward transaction-level permissions designed for specific users, applications, and autonomous agents.

**For teams building wallets or agents today, what kinds of policies would be most useful for what you're building?**

[See more information on Turnkey's policy engine and how it's helping builder's secure transactions here](https://www.turnkey.com/blog/100m-policies--turnkey-protecting-transactions).

Over 100 million policies created on Turnkey. For teams building wallets or agents today, what kinds of policies would be most useful for what you're building?