> Source: [/docs/accounts/automations](https://tempo.xyz/developers/docs/accounts/automations.md) > Section: [Accounts](https://tempo.xyz/developers/docs/accounts.md). Create accounts, set up signing methods, policies, access keys, key rotation, and fees, and follow guides for users, automations, agents, and teams. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. # Automations Lets a backend or an agent pay from an account without holding the account's key. ## Overview An automation is code that sends stablecoins without a person approving each payment. Examples include payouts, payroll, card funding, and AI agents. Give that code its own [access key](https://tempo.xyz/developers/docs/accounts/access-keys) instead of the account's key. The account's signers authorize the key once. Tempo rejects any payment over its [spending limit](https://tempo.xyz/developers/docs/accounts/access-keys/spending-limits), outside its [scopes](https://tempo.xyz/developers/docs/accounts/access-keys/scopes), or after its [expiry](https://tempo.xyz/developers/docs/accounts/access-keys/expiry). Access keys are part of the protocol, so you don't add session-key modules or wallet contracts. Access keys are live on mainnet and testnet with a single-key account. None of these setups needs a configurable account. ## Access Keys and Account Keys * **Account Key on the Server:** A breach lets the attacker move the whole balance. * **Access Key on the Server:** A breach lets the attacker pay only within that key's limit, recipients, and expiry. The account can [revoke](https://tempo.xyz/developers/docs/accounts/access-keys/revocation) the key. Keep the account's key with the user, their wallet provider, or your own approvers for a business account. Any key that signs Ethereum transactions can send stablecoins on Tempo. A backend that already signs with a KMS key or a provider's server wallet can keep that key. Authorize it as an access key to add the limits. The key pays fees in a stablecoin, or a [fee payer](https://tempo.xyz/developers/docs/accounts/fees/fee-sponsorship) covers them. The service never holds a gas token. ## Sign With a KMS Key AWS KMS and Google Cloud KMS keys work as access keys. The private key never leaves the KMS. An access key signs the 32-byte digest of each [Tempo Transaction](https://tempo.xyz/developers/docs/guide/tempo-transaction). Both KMSs sign digests with secp256k1 and P-256 keys. Wrap the KMS signing call as a Viem account, as in [Keep the key in your KMS](https://tempo.xyz/developers/docs/accounts/automations/pay-out-from-a-backend#keep-the-key-in-your-kms). ## Sign With Server Wallets Privy server wallets and Turnkey both sign Tempo Transactions and raw hashes. | Provider | How it signs on Tempo | | --- | --- | | [Privy](https://docs.privy.io/wallets/using-wallets/tempo/send-a-transaction) server wallets | Sends Tempo Transactions through its wallet API, or signs raw hashes with `raw_sign` | | [Turnkey](https://docs.turnkey.com/features/networks/overview) | Signs Tempo Transactions with `sign_transaction`, which its policies can inspect, or raw hashes with `sign_raw_payload` | Either can act as an access key. Wrap its raw-hash signing as a Viem account, as in [Pay from a user's embedded wallet](https://tempo.xyz/developers/docs/accounts/automations/pay-from-an-embedded-wallet#wrap-the-providers-signing-as-an-account). ## Rotate and Revoke Backend Keys To rotate, authorize a new key, switch the service to it, then [revoke](https://tempo.xyz/developers/docs/accounts/access-keys/revocation) the old one. A key can't be extended past its expiry, so [renew it](https://tempo.xyz/developers/docs/accounts/access-keys/expiry#renew-an-expiring-key) before then. Save each key's address with the service that holds it, so you can revoke one key without stopping the others. ## Guidelines ### One Key per Service A breach of one service then exposes only that key's limit, recipients, and expiry. Authorize a separate access key for each service or agent. Generate it where it runs or in your KMS, so only the key's address leaves it. ### Set All Three Bounds A key with a limit, scopes, and an expiry can pay only for the job it does. Set a daily limit per stablecoin sized to the job. Add scopes that list the only recipients or contracts it pays, and an expiry. ## Related [Pay Out From a Backend](https://tempo.xyz/developers/docs/accounts/automations/pay-out-from-a-backend): Use for paying approved payees up to a daily limit, with a key in your KMS. [Pay From a User's Embedded Wallet](https://tempo.xyz/developers/docs/accounts/automations/pay-from-an-embedded-wallet): Use for card programs and subscriptions that pay from a user's Privy or Turnkey wallet. [Give an Agent a Wallet](https://tempo.xyz/developers/docs/accounts/automations/give-an-agent-a-wallet): Use for giving an AI agent a budget, an expiry, and only the calls it needs. [Access Keys](https://tempo.xyz/developers/docs/accounts/access-keys): Covers the keys an account authorizes with limits, scopes, and expiry.