How do you give an AI agent database or API access without leaking credentials?
Keep the credential out of the model's context. The agent should run a tool that already holds the secret, rather than being told the secret and asked to use it. That means environment variables or a secret store the process reads, scoped credentials with the narrowest rights the job needs, and separate keys per task so one mistake does not expose everything.
What is true regardless of what you pick
- Anything in the model's context can be repeated in its output, quoted into a log, or included in a message to another service. A pasted key is a disclosed key.
- A credential in an environment variable is readable by the process but never enters the conversation unless something prints it.
- Scoped, short-lived credentials limit damage without preventing work: a read-only database role, a token limited to one repository, a test-mode payment key.
- Agents run shell commands, so a credential the container can reach is a credential the agent can use, whether or not it can read the value.
- Isolation per task matters more than key strength. One key shared across every agent means any single mistake is a full compromise.
Your options, and where each one stops
| Approach | Good for | Breaks when |
|---|---|---|
| Paste the key into the chatGive the agent the secret directly in its prompt or a config file it reads. | Nothing that touches a real system. It is worth naming because it is what people do first. | Immediately. The value is now in the context, in the provider's logs, and in whatever the agent writes next. |
| Environment variables in the agent's processThe credential is set in the environment the agent runs in, and tools read it from there. | Most local work. Simple, universally supported, and keeps the value out of the conversation. | Every agent on the machine shares one environment, so scoping per task means running separate processes anyway. |
| A secret manager the tool callsThe credential lives in a vault and is fetched at use time by the tool rather than held by the agent. | Teams, rotation, audit trails, and anywhere the same secret is used by more than one system. | It is heavy for one person on one machine, and the agent still ends up with a usable session once the secret is fetched. |
| A tool or MCP server that owns the credentialThe agent calls an operation such as query or deploy, and the credential sits inside the tool where the model never sees it. | Giving an agent real capability with a bounded surface. The agent gets verbs rather than keys. | The available operations do not cover the job, at which point people hand over the raw credential and undo the whole arrangement. |
| A separate container per task, credentials insideEach agent runs in its own sandbox holding only the credentials that task needs. | Running several agents with different access, and keeping a mistake contained to one task. | There is setup to do, and it does not remove the need to scope the credentials themselves. |
What to actually do
Two rules do most of the work. The credential never enters the model's context, and each task gets only the access it needs.
In practice that means tools holding secrets rather than agents holding secrets, plus per-task isolation so the scope of any single mistake is small.
intentic is built around that arrangement. A capability installs a real tool and its credential inside your sandbox, the agent operates the tool, and the value never leaves your machine or reaches the platform. The platform stores your identity and your sandbox's address, and nothing else.
The rule that matters: context is disclosure
Treat everything the model can see as published. It can be echoed into output, written into a file, quoted in a commit message, or sent to another service the agent is allowed to call. None of that requires the model to be malicious, only unlucky.
This is why the fix is structural rather than behavioural. Asking an agent not to print a secret is a request; keeping the secret out of its context is a guarantee.
Scope beats secrecy
A read-only database role that leaks is an incident. A write-capable production role that leaks is a catastrophe. Most of the safety available here comes from deciding what the credential can do, before deciding how well it is hidden.
The practical version is unglamorous and effective: a separate credential per task, the narrowest permission that lets the work happen, and a short life so an old leak stops mattering.
- Read-only wherever the job does not require writes.
- One credential per task rather than one shared across every agent.
- Test or staging systems by default, with production access as a deliberate exception.
- Rotation that someone actually performs, which usually means short-lived tokens rather than a calendar reminder.
What isolation buys you
Running each agent in its own container changes the question from whether an agent will make a mistake to how far the mistake reaches. An agent with a staging database credential and no network access to production cannot cause a production incident, whatever it does.
This is also what makes running several agents at once tolerable. Without isolation, every agent shares one environment and one set of keys, so the blast radius of any single task is the whole machine.
Related questions
Is it safe to give an AI agent access to a database?
It is safe in proportion to what the credential can do. A read-only role on a staging copy is low risk and often enough to be useful. A write-capable production role is a serious risk regardless of which agent or model is used, and should be a deliberate exception rather than the default.
Does the AI model see my API key?
Only if it ends up in the context. A key in an environment variable or held inside a tool is used by the process without being shown to the model. A key pasted into the prompt or printed by a command the agent ran is in the context, and should be treated as disclosed.
Are environment variables good enough for agent credentials?
For one person on one machine, usually yes, because they keep the value out of the conversation. They stop being enough when several agents share the machine, since they all see the same environment, or when the credential needs rotation and an audit trail.
Do MCP servers keep credentials away from the model?
Yes, that is one of the reasons to use them. The server holds the credential and exposes operations, so the agent calls something like a query rather than receiving a connection string. The protection is only as good as the operations exposed: a tool that returns the raw secret gives the model the secret.
What happens if an agent leaks a secret?
Treat it as a live disclosure and rotate immediately, because the value may exist in provider logs, in files the agent wrote, and in the session history. This is the argument for short-lived, narrowly scoped credentials: rotation is routine and the exposure window is small.
Read next
Written against the state of the field in 2026-08. This area moves fast. Spot something out of date or wrong? Open an issue and it is fixed in the next build.