Secret Handling Requirements

When integrating AI Chat, you must protect the following secrets and credentials to prevent leakage or misuse.

Secrets That Need Protection

Secret	What It Is	Where It Should Be	Where It Must NOT Be
SecretKeyId	Application-level secret for TGV1-HMAC-SHA256 signing	Your application server	Client code, device firmware, frontend pages, logs, screenshots, tickets
AccessKeyId	Application-level access identifier, paired with SecretKeyId	Your application server	Client code, device firmware
token	Short-lived connection credential for TiRtcWhipConnect	Device side (temporary)	Do not log full values or cache long-term

What You Must Not Do

• Embed SecretKeyId in device firmware, client code, or sample projects.
• Log the full token or send it in chat messages, emails, or support tickets.
• Let the device call /v1/token/aichat directly—devices must never hold AK/SK.
• Store secrets in config files and commit them to the repository.

Recommended Practices

Log Identifiers Only, Never Secrets

When troubleshooting, logs should typically contain only:

• device_id
• session_id
• Connection state and error codes

Do not log SecretKeyId, full token, or full peer_id.

Mask Sensitive Fields During Troubleshooting

If peer_id must be shared, keep only enough to locate the issue. Never paste the full token.

Split Access by Responsibility

• Application server: Holds AppId, AccessKeyId, and SecretKeyId for signing and credential requests.
• Device: Temporarily holds only peer_id and token; releases them after use. Must never hold AK/SK.

What to Do If a Secret Is Leaked

1. Stop using the leaked secret immediately and stop sharing it in chats or tickets.
2. Confirm the leak scope: code repositories, logs, chat history, screenshots.
3. Request new AccessKeyId / SecretKeyId through your platform configuration process and replace.
4. Clean up all historical leaked copies.

Related Documentation

• Glossary
• Server Integration
• Privacy Boundaries and Data Compliance