PERMISSIONS AND ACCESS CONTROL

CORE RULES Never put secrets in the model's context. Whatever the model sees can be repeated in output, written to logs, leaked by a prompt injection, or sent to a third party that hosts the model. Instead, let the harness hold the secret and inject it into the outgoing request at the last moment, so the model only says "call this tool" and never sees the key. Never write secrets into logs or traces, so scrub or redact them. Store secrets in a proper secret manager or protected environment, not in code files or documents. Never commit secrets into version control, which is the system that stores the history of code changes, because history can be copied and shared. Use scoped, short-lived credentials where possible, so a leak has limited value. Rotate keys, meaning replace them regularly, and prepare an incident response plan for exposure: automatically revoke the exposed key, issue a new one, check logs for misuse, and notify the owners. Treat anything the agent can read as potentially visible to an attacker, since a hijacked agent can read whatever it can read.