How to give AI agents access to your systems without sharing passwords

To do real work, an AI agent has to reach your systems: the online store, the accounting software, the CRM. Those systems want an API key or a password. The quick way is to paste the key into the agent's instructions. It is also the way keys leak.

This guide explains why secrets don't belong in front of a model, and how a credential broker lets an AI use a credential without ever seeing it.

Why a key in a prompt is a leaked key

A language model treats everything in its context as text it may repeat. A key in a prompt can end up:

• in the model's answer, when a user or a document asks for it;
• in logs and conversation history, on your servers or a vendor's;
• in the hands of an attacker, through prompt injection: instructions hidden in an email, web page or file the agent reads.

Telling the model "never reveal this key" doesn't help. Instructions to a model are not a security control. The only safe secret is one the model never receives.

Use without seeing

The fix is to separate using a credential from seeing it. In OrgKeep, vaults have an access level called Use. A member with Use access, human or AI, can make a request with a credential but can't read its value.

Here is what happens when an AI employee calls a system:

1. The AI decides to fetch new orders and calls the store tool with a reference to the vault entry, not the key.
2. The credential broker on the server checks that this AI employee has Use access to that entry.
3. The broker inserts the key into the outgoing request and sends it.
4. The response comes back to the AI. The key never does.

Because the AI never holds the secret, it can't repeat it, log it or be tricked into sending it somewhere else.

Give every AI employee its own key

Shared credentials make it impossible to tell who did what. For each AI employee, create a separate API key in the outside system with only the permissions its job needs.

• Least privilege. A store manager AI needs to read orders and update stock, not delete products or change payment settings.
• Revocable on its own. If something looks wrong, revoke one key without disturbing anyone else.
• Readable logs. The outside system's own logs show exactly what that AI did.

Keep permissions on the server

The broker is one part of a wider rule: the server decides what any member may do. An AI can ask to do anything; the tool layer checks permissions before acting, with the same check it runs for people. Access follows project membership, so an AI employee added to one project can use that project's credentials and nothing else.

Add two more guardrails and most of the risk is covered:

• Human-only steps. Payments, contracts and production deploys always stop for a person, whatever the AI's settings say.
• One audit log. Every action is recorded under the member who took it, so you can trace any change back to a human or an AI.

A checklist

• No API keys or passwords in prompts, instructions or skill files.
• Credentials stored in a vault, with Use access for AI employees.
• A separate, narrowly scoped key per AI employee.
• Permission checks in the server, not in the model's instructions.
• Human approval for payments, contracts and deploys.
• Every action logged under its own identity.

Read the glossary for short definitions of these terms, or book a demo to see the vault working.