how to secure AI agent credentials
An agent that can sign in can also expose credentials through its tools, logs or model context. Secure credential management starts with controlling the account, the access and the place a secret becomes readable.
1. choose the account and the access
Check the approved credential store first. Reuse the correct service account instead of creating duplicate identities or asking the person to paste a password. If the authorized task needs a new account, create its Decoy record and email address, then complete the separate signup at the service.
Request the accounts, inboxes and capabilities needed by the task. Existing accounts, accounts this connection creates and Personal Alias inboxes have distinct access rules. Verify the effective grant after approval; a scope string alone does not describe its resource boundary.
2. keep credentials in the right place
Keep the service URL, login identity and credentials associated with the same account. A login password belongs in its password field. In the app, an API key belongs in a distinct named Hidden field, separate from the password. The default MCP tools and created-only HTTP flow do not provide a same-account custom-field write or read-back procedure. Follow the storage guide for supported handling. User preferences and project context belong in memories, not secret values.
Follow the supported storage procedure for the connection. Encrypt vault values in the trusted runtime before sending them to Decoy. A plaintext HTTP request to an encryption service moves the trust boundary to that service; HTTPS alone is not end-to-end encryption.
3. control who can read the secret
Decoy stores encrypted vault values and delivers approved material to the trusted agent runtime. Decoy cannot read those values; the agent and its provider can. Protect the connection token and private key in secure runtime storage.
Exclude secrets from prompts, chat replies, ordinary logs, traces, screenshots and memory. Use only the authorized tool or service destination. For passkey sign-in, the phone signs the challenge and the agent receives an assertion instead of the private key.
Encrypted vault storage and incoming email are different boundaries. Read the email guide before making an end-to-end encryption claim about mail.
4. verify what actually worked
Inspect the real grant, then complete the agreed operation. A new account is confirmed by an independent read of the saved record. Reading a received test message confirms inbox access. A credential write receipt confirms acceptance, not decrypted read-back or owner-app visibility.
For a saved credential, use an independent authorized fetch and decryption when the documented path supports it. Preserve unrelated account fields during edits. Report the verified result and any incomplete part without exposing the secret.
5. manage access after setup
Reuse the connection while its token and grants are valid. Request missing access on that connection instead of re-pairing or requesting a whole vault to work around a failed operation. Review recorded activity and revoke access that is no longer needed.
Revocation stops future access through Decoy. It cannot erase an already delivered password or close a separate service session. Rotate an exposed reusable credential at its provider and revoke service sessions as needed.
put the workflow to work
Use the Decoy setup prompt for your agent, approve the requested access in the iPhone app and verify the effective grant. The access guide defines grants; the recipes and storage guide define the operations and what their responses prove.
A connect-only request is complete with a verified reusable connection and the intended access. If the person also asked for a task, confirm its actual result. Keep the confirmation brief; the agent retains the evidence and handles routine authorized work in the background.
use the documented workflow
common questions
should I paste an API key or password into an agent chat?
Use the approved credential store and a supported retrieval path instead. Pasting secrets into chat can expose them to conversation history and downstream logs.
does encrypted storage keep secrets away from the agent provider?
No. Storage encryption protects stored values. When the agent runtime decrypts an approved value, the agent and its provider can read it. Their handling of model context and logs remains part of the security boundary.
what should I verify after saving a credential?
Separate write acceptance, independent decrypted read-back and visibility in the owner’s app. Claim only the results you actually checked through supported paths.