An agent that works on your real systems needs real access keys. Where are they stored, who can read them, what happens when an employee leaves or a log leaks? The questions to ask before you sign.
Most AI agent projects follow a predictable arc. A team builds a proof of concept that reads from a CRM, drafts replies, updates a ticketing tool, or queries an internal database. It works. Everyone is enthusiastic. Then someone asks the question that should have been asked on day one: where do the credentials live?
The demo usually runs on a developer laptop with keys pasted into a local environment file. That is fine for a demo. It becomes a liability the moment the agent touches a real system with real customer data. An agent that can read your mailbox, update your ERP, or call a paid model API holds a set of keys that are, in effect, a set of privileges. Treating them casually is like leaving the office master key under the doormat and hoping nobody checks.
What makes agents different from ordinary applications
A classic web application usually has one credential per service, tightly scoped, and a small number of people who manage it. An AI agent often needs several at once: a model provider key, a database connection, a CRM token, maybe an email or calendar integration. Some agents act on behalf of individual users, which means per-user tokens. Some run on schedules, which means long-lived credentials. Some call other agents or tools, which multiplies the surface.
Add to this the fact that agents are frequently built quickly, by people focused on prompt quality and output reliability rather than infrastructure hygiene. The result is a project where the hardest engineering question — how does the model decide what to do — gets all the attention, and the dullest one — who can read the production key — gets none.
The questions to ask before you sign
You do not need to be a security specialist to run a serious review. You need to ask the right questions and insist on clear answers.
- Where are the secrets stored, exactly? "In the code" and "in a config file on the server" are not acceptable answers for production. Look for a dedicated secrets manager, a managed vault, or at minimum an encrypted store with strict access control.
- Who can read them? Ask for the list of humans and systems with read access. If the answer is "the whole dev team," ask why. Access should be minimal and reviewable.
- Are they scoped? A key that can read and write everything in your CRM is a bigger risk than one that can only read contacts. Ask whether the agent's credentials are limited to what the agent actually needs.
- What happens when an employee leaves? Offboarding is where secret hygiene quietly fails. There should be a documented process for rotating every credential a departing person could have seen.
- Are secrets ever logged? Agents generate verbose logs, and verbose logs are where keys leak. Ask how logs are scrubbed and whether prompts, tool calls, and errors are checked for embedded credentials.
- Can you rotate without redeploying? If changing a key requires a code change and a release, rotation will not happen often enough.
- Who owns this after launch? A named person, not a team, should be accountable for credential lifecycle.
Practical patterns that work
The good news is that this is a solved problem in general software engineering; AI projects simply need to inherit the discipline.
Store secrets in a managed secrets service rather than in environment files committed to a repository. Inject them at runtime, never at build time. Give each agent its own identity and its own credentials, so that revoking one does not break everything and auditing one is possible. Prefer short-lived tokens issued by your identity provider over static API keys where the integration allows it. Log the fact that a credential was used, not the credential itself, and put a filter in front of your logging pipeline that catches key-shaped strings. Keep a rotation calendar and actually follow it.
For model provider keys specifically, set spending limits and usage alerts. A leaked key is not only a data risk; it is a bill. Many providers let you restrict a key to a project or an environment, which is worth the five minutes it takes.
Governance is a business decision
It is tempting to file all of this under "technical detail." It is not. The decision to give an autonomous agent write access to a customer system is a business decision about risk tolerance, and it belongs in the same conversation as the budget and the timeline. A short written policy — which systems agents may access, under what conditions, with what logging, reviewed by whom — prevents most of the problems before they exist. It also makes procurement and security reviews dramatically faster, because you can hand over a document instead of improvising answers.
If you are evaluating a proposal for an AI agent project, whether from an internal team or an external partner, ask where the keys will live and who will be able to read them. A confident, specific answer is a good sign. A vague one is worth pausing on.
Let's talk about your project
If you are planning an AI agent that will connect to real business systems, I am happy to walk through the access and secrets design with you before anything is built. It is a short conversation that saves a great deal of trouble later. You can reach me at contact@hamzabelgacem.com.