Keys and tokens
- Service keys are server-side secrets. Keep them in an environment variable or secret store. Give each app its own key with the smallest scopes, models and caps it needs, and revoke on any doubt.
- Never put a key in a web page, a mobile app, a repository or a log.
- Browsers call Artemii with the signed-in person's Mayfair ID token, not with a key. Token calls are limited by that person's plan.
- Keys are stored hashed. Nobody can show you a lost key: revoke it and create a new one.
- Access tokens live in memory and
sessionStorageonly. Anything that can run script on your page can read them, so keep your Content Security Policy strict.
Model output
- Treat model output as untrusted text. Escape it before putting it in HTML. Do not build queries or commands from it.
- Models read untrusted content (emails, web pages, documents) and can be talked into asking for actions. Ask the person before anything that sends, deletes, pays or changes data.
- Validate tool arguments yourself, exactly as you would user input.
System prompts
Artemii's system prompt is not a security boundary for your own data. Do not put secrets in system messages.
What the gateway stores
- API calls are stateless and not stored. Request text is not logged by the gateway. Usage numbers (counts only) are.
- Service key secrets are stored as a SHA-256 hash with a visible prefix. They never appear in logs, errors or the audit trail.
- Creating, editing and revoking keys is written to an audit log (who, when, which fields; never the secret).
People stay in control
People can switch an app off for themselves, administrators can switch it off for an organisation, and both can see what an app did in the activity log. Read Privacy and control for the user's side.
Reporting a problem
Found a vulnerability? Email hello@mayfairmail.com with "Security" in the subject and the x-request-id if you have one. Please do not test against other people's accounts.