Security model
TempoKey security boundaries: on-chain permissions, browser and API key storage, revocation, backups and incident response.
What the protocol protects
Tempo enforces the registered access key's permissions at transaction execution. Budgets, supported call scopes, expiry and revocation are independent of the agent's own software. An agent key does not grant unrestricted owner-key access.
The owner is responsible for choosing appropriate permissions and protecting the wallet used to authorize them. A valid payment sent to the wrong allowed address is still a valid on-chain payment.
Where keys are stored
| Mode | Key handling |
|---|---|
| Browser dashboard | Agent keys are kept in localStorage. They are not encrypted by an application password. |
| Direct SDK | The delegated private key is available to your process. Store it in an appropriate secret store. |
| Hosted API | The delegated key is encrypted at rest with AES-256-GCM and decrypted for execution using the service secret and Bearer credential. |
Browser script injection, malicious extensions or access to an unlocked device can expose locally stored keys. Server-side encryption at rest does not prevent a compromised running service from accessing keys during legitimate execution. Never put agent secrets in public frontend environment variables or logs.
Operate with limited authority
- Use separate keys for separate jobs, with explicit budgets and expiry.
- Restrict recipients where the workflow allows it.
- Review DEX permissions separately from payment recipients.
- Record transaction hashes and reconcile outcomes before retries.
- Treat agent names and public owner listings as public metadata.
- Keep recovery access to the owner wallet; deleting local data is not a revocation mechanism.
If a key or token is exposed
Revoke the affected agent key on-chain from the owner wallet, wait for confirmation and review recent transactions. Replace the application's key and credentials. Rotating a Bearer token alone does not disable a leaked P256 key that can still be used directly.
For a self-hosted API, preserve KEY_SECRET with the encrypted agent store and take consistent SQLite backups. Losing the service secret makes existing stored keys unusable. Restoring an older idempotency database requires transaction reconciliation before resuming execution.
Membership and audit status
The tTK pilot is a separate testnet system. Its contracts are source-verified and have automated tests. No independent audit or guarantee of service availability is claimed. Hosted quota enforcement is an operator-provided service, while token ownership and withdrawal rules are on-chain.