Managing API Keys

You should consider all secret API keys as account credentials. Consequently, they belong only in your server environment. Exposing a secret key can put your business and other Augno users at risk. The guidance below will help you avoid leaks and limit damage if something goes wrong.

Reducing the risk of key compromise

• Store keys in a proper secret store. New secret keys are shown once in the Dashboard. Copy each key into a key management system (KMS) or secrets manager that encrypts and controls access. Never leave keys in source code, config files, or unsecured local storage.

• Tighten who can manage keys. Decide who is allowed to create, change, or view API keys, and enforce that. Review those permissions and access logs on a schedule so you catch overprivileged or unused access.

• Avoid unsafe channels. Never send secret keys over email, chat, or support tickets. Augno will never ask you for your secret key.

• Keep keys out of version control. Attackers routinely search public repos for API keys. Do not commit secret keys. Even in private repos, code can end up on laptops or in tools where a breach could expose them.

• Reserve secret keys for the server. Secret keys should only live in backend or server-side code. Do not ship them in client apps, mobile binaries, or frontend bundles. Use the API from your own servers instead.

• Rotate keys on a schedule. Have a process for rotating Augno API keys and practice it. You'll know where keys are used and be ready to replace one quickly if it's compromised.

• Use logs to spot misuse. Check request logs regularly. Confirm sandbox keys are used for testing and production keys only in production.

• Document and train. Keep internal docs and runbooks for key handling up to date, and train your team on them.

Use the minimum permissions needed

In the Dashboard you can create keys with scoped roles instead of full admin privileges. Prefer that over sharing a single high-privilege key.

Scoped permissions contain the blast radius of a leak. For example, a key that can only read certain resources limits what an attacker can do if that key is stolen. Create separate keys per use case and give each one the least privilege it needs. Details are in API Keys.

When a key may be compromised

If you know or suspect a secret key has been exposed (e.g. committed to a repo or sent by mistake), revoke it in the Dashboard right away, issue a new key, and update every place that used the old one. If you see odd activity but aren't sure, revoke and rotate anyway while you investigate. It's safer to assume compromise.

When Augno finds an exposed secret key we take immediate action (such as revoking it) and notify you. We cannot guarantee that we will catch every exposure, so following these practices and securing your integration remains your responsibility.