Passwords & Secrets

How you store & access logins, keys & tokens

How your team stores and accesses credentials is a readiness question and a security question at the same time, because any AI that needs to connect to services needs access to secrets, and how you manage those secrets determines how safely you can do that.

Credentials, API keys, tokens, and login details are the keys that unlock your other systems. Without them, an AI tool cannot connect to services, read from databases, or take actions on your behalf. With them, the tool has real reach. That reach needs to be granted deliberately, with the right level of access and with a clear record of what was given to what.

Many teams do not have a systematic way of managing credentials. Passwords live in inboxes, API keys are shared in chat messages, and access is added informally as someone needs it. That approach works well enough for daily operations but becomes a serious risk when you start connecting external tools. The moment a credential is shared with an AI integration, you need to know what it can access, who authorized it, and how to revoke it if something goes wrong.

The goal is not to restrict AI access but to make it auditable. A secrets manager, role-based access, and the habit of creating service-specific credentials with the minimum permissions needed turns credential management from a liability into a controlled process.

Make it visibleIf your team does not use a dedicated password and secrets manager, start there: adopt one tool where all credentials live, then do a sweep for any API keys or passwords stored outside it and move or rotate them. That single change makes every future AI integration safer.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

Least-privilege credentials

An AI tool connecting to a service should use a credential that can do exactly what it needs and nothing more. A read-only key for a read-only task; a scoped token for a specific endpoint.

Revocation and rotation

A credential you cannot easily revoke is a risk you cannot close. Knowing where every credential is and having a way to rotate or invalidate it is a basic safety requirement.

Secrets in the wrong places

API keys shared in chat messages, emailed to contractors, or pasted into shared documents are effectively public. Cleaning up where secrets live is a prerequisite to safe AI integration.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

Where does your team currently store passwords and API keys, and does everyone use the same system?
If you needed to revoke an API key that had been shared with an external tool, how quickly and confidently could you do that?
Are there credentials in your team that have broader access than the person or tool using them actually needs?
Do you know which external tools or integrations currently have valid credentials to your systems?
What would happen if a credential was accidentally exposed in a chat message or commit today?

Readiness traps

Sharing a credential with an AI tool that has admin-level access is far riskier than it first appears. If that integration is later compromised, the blast radius is the full scope of those permissions. Always use the minimum access level needed.
Credentials stored in places outside a dedicated secrets manager, such as chat threads, shared documents, or unencrypted notes files, are at higher risk of accidental exposure. A single audit of where secrets actually live often surfaces problems that no one intended.
Giving an AI tool a personal login rather than a dedicated service credential creates an audit trail problem: actions taken by the tool appear to come from a person, making it hard to know what the tool did and what the person did.