---
title: "How to give an AI agent database and API access safely"
description: "Keep the credential out of the model's context and scope it to the task. Environment variables, secret managers, tools that hold the key, and what each one actually protects."
url: "https://intentic.dev/guides/give-an-ai-agent-database-and-api-access-safely/"
---

[Guides](https://intentic.dev/guides/)

# How do you give an AI agent database or API access without leaking credentials?

The short answer

Keep the credential out of the model's context. The agent should run a tool that already holds the secret, not be told the secret and asked to use it. That means a secret store the process reads, credentials scoped to the narrowest rights the job needs, and separate keys per task.

[Get started free](https://app.intentic.dev)[See the product](https://intentic.dev/features/)

## 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 chat** Give 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 process** The 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 calls** The 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 credential** The 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 inside** Each 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. A capability installs a real tool and its credential inside your sandbox, the agent operates the tool, and the value never leaves that sandbox. Run it on your own machine and the platform stores your identity and your sandbox's address, nothing else; run the starter box we host and the sandbox itself sits on infrastructure we rent.

## 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

A container per agent changes the question from whether an agent will make a mistake to how far it reaches. An agent with a staging credential and no route 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?](#safe-to-give-agent-db-access)

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. A write-capable production role is a serious risk whatever the model, and should be a deliberate exception.

### [Does the AI model see my API key?](#does-the-model-see-my-key)

Only if it reaches 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 a prompt, or printed by a command the agent ran, should be treated as disclosed.

### [Are environment variables good enough for agent credentials?](#env-vars-enough)

For one person on one machine, usually yes: they keep the value out of the conversation. They stop being enough when several agents share the machine and all see the same environment, or when the credential needs rotation and an audit trail.

### [Do MCP servers keep credentials away from the model?](#mcp-server-credentials)

Yes, that is one reason to use them. The server holds the credential and exposes operations, so the agent calls 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?](#agent-leaks-secret)

Treat it as a live disclosure and rotate immediately: the value may sit in provider logs, in files the agent wrote, and in session history. This is the argument for short-lived, narrowly scoped credentials.

## Read next

[Connect agents to your systems](https://intentic.dev/features/empower/)[Capabilities, in the docs](https://intentic.dev/docs/capabilities/)[Access and permissions](https://intentic.dev/docs/access/)

Written against the state of the field in 2026-08. This area moves fast. Spot something out of date or wrong? [Open an issue](https://github.com/intentic/intentic/issues) and it is fixed in the next build.

[Next guide How do you review code an AI agent wrote before it lands? →](https://intentic.dev/guides/review-ai-generated-code-changes/)

[Get started free](https://app.intentic.dev)[All guides](https://intentic.dev/guides/)