Your AI Agent Should Never See a Password

Somewhere right now, a business is wiring up its first AI agent, and the integration step looks like this: paste the CRM API key into the system prompt, or drop it in an environment variable the agent can read, and tell the model to be careful with it. The agent works. The demo lands. And the company has just granted its most credulous employee ever full access to the system of record.

Credulous is the precise word. An agent reads instructions wherever it finds them: in your prompt, in a webpage it was asked to summarize, in a customer email it was asked to triage. The industry term is prompt injection, but the plain description is worse: anyone who can get text in front of your agent can attempt to give it orders. If the agent is holding a key when that happens, the attacker is not trying to trick a model anymore. They are negotiating with something that has your password and no judgement.

The transcript problem is quieter but just as real. Agent frameworks log conversations, by design, for debugging and review. Every log that contains a working credential is a copy of that credential, sitting in whatever retention policy your logging stack happens to have. Secrets do not belong in conversations, and an agent's entire working life is a conversation.

The agent does not need the key

Here is the observation that fixes the whole class of problem: an agent never needs to know a credential to use a system. It needs the request made on its behalf. Those are different things, and the gap between them is where the architecture goes.

The pattern is a gateway. The agent does not call your CRM, your accounting platform, or your e-commerce store directly. It calls a small proxy service and says, in effect, "GET this resource" or "update that record". The gateway holds the credentials, injects them server-side into the outbound request, and returns the result. The agent sees the data it asked for. It never sees the token that fetched it.

Run that pattern through the failure cases. Prompt injection succeeds and the agent is persuaded to reveal its secrets: it has none to reveal. The full conversation log leaks: there is nothing in it but requests and responses. The model provider has an incident, a framework caches context somewhere unexpected, a transcript ends up in a bug report: still nothing. The credential lives in one place, owned by infrastructure, rotated without touching a single prompt.

Isolation per client, ceilings per operation

For anyone running agents across multiple clients or business units, the gateway is also where isolation gets enforced. Each client gets its own gateway with its own credentials and its own allowlist of domains it may reach. An agent working for client A cannot call client B's systems, not because it was instructed not to, but because the only path it has physically refuses the request. One compromised or confused session is contained by construction.

The same boundary carries permission ceilings. Reads, writes, and destructive operations are different tiers, and the gateway enforces a maximum tier per client regardless of what any individual request claims it is allowed to do. An agent whose job is research holds read-only access at the network level. The delete verb is not discouraged. It is absent.

If that sounds familiar, it is the same principle we apply to dealer portals: enforce isolation at the layer that cannot be argued with. In a portal, that layer is the database. For agents, it is the network path. In both cases the rule survives contact with a clever user, because the rule is not written in instructions. It is written in what is reachable.

Prompts are policy suggestions

This is the part the current tooling culture gets backwards. A system prompt that says "never share credentials, never call external services, never act destructively" reads like a security policy and functions like a sticky note. Models follow instructions probabilistically. Security boundaries that hold ninety-nine times out of a hundred are not boundaries; they are odds.

The honest division of labour: prompts shape behaviour, infrastructure constrains it. Tell the agent what good work looks like in the prompt. Decide what the agent can reach, see, and break in the gateway, where the decision is code, reviewed and version-controlled, enforced identically on the model's best day and its strangest one.

The honest costs

A gateway is a service you now run: deployment, monitoring, an allowlist to maintain, one more hop of latency on every call. Off-the-shelf integrations that expect a raw key will not fit it without adaptation, and the first week of any new integration includes a conversation about which domains and verbs to open.

For a single agent doing low-stakes work against one system with a scoped, revocable token, this can be more machinery than the risk justifies. The calculus changes the moment an agent touches a system of record, handles more than one client's data, or operates unattended. That is the same threshold where every other piece of production infrastructure stops being optional, and agents do not get an exemption because they are new.

We run our own operations this way

This architecture is not a recommendation we make from shore. Every client engagement at Neckles IO runs behind its own gateway with separately scoped credentials injected server-side; the AI agents that do delivery work on our platform have never held a secret, and our own operations follow a zero-PII standard on top of it. The pattern survives daily production use, which is the only endorsement that matters.

If you are evaluating anyone's agentic offering, including ours, the test is one question: if every conversation your agents have ever had leaked tomorrow, what credentials leak with them? The only acceptable answer is none, and the only way to make that answer true is to build it so the agent never saw one.