Agents need access, not secrets

For three years we taught machines to talk. This year we asked them to work. The difference sounds small and it changes the security of everything we own.

A chatbot that answers questions can only embarrass you. An agent that books, builds, deploys and pays can cost you. To do any of that it needs the same thing a human employee needs on day one: access. Access means credentials. API keys, signing keys, tokens, passwords. The moment we let an agent act, we also have to decide where it gets the keys to act with.

Right now most of us decide badly, and we decide in a hurry. The key gets pasted into the chat so the agent can finish the job. It gets saved in a plain text file in the project folder because that is where the agent looks. It gets exported as an environment variable that every program in the session can read. Each of these feels like a one time shortcut. Each of them puts a secret somewhere it was never meant to live: a conversation history, a log file, a context window that may be stored, synced, summarised or shared. A key that has been read by a model has to be treated as a key that has been read by everyone who can ever read that record.

We have seen this pattern before. In the early web, passwords were stored the way they were typed, because it was easy and nothing had gone wrong yet. The fix was never to ask users to be more careful. The fix was to change the design so that carelessness could not leak the secret. Nobody stores a plain password today because the system makes it unnatural.

Agents need the same correction, and it starts with one question: does the agent ever need to see the secret, or does it only need the secret to be used on its behalf?

For almost every task, the answer is the second one. Signing a release does not require the agent to know the signing key. Calling a paid service does not require the agent to read the token. It requires a trusted party on the machine that holds the key, checks that the request is allowed, applies the key at the moment of use, and returns only the result. The agent gets the outcome. The secret never enters its memory, so it can never be repeated, summarised into a log, or leaked by a prompt that was written to trick it.

This is an old idea with a new urgency. Security people call it least privilege. Hardware people call it a secure enclave. What is new is who is asking. The requester is no longer a person who can be trained, and no longer a program with fixed behaviour. It is a system that reads untrusted text all day and sometimes follows instructions hidden inside it. Giving that kind of requester a raw secret is the one design choice we cannot defend.

There are four habits worth adopting now, before the incidents arrive.

First, treat every key that has appeared in a prompt as compromised, and rotate it. Second, keep secrets in an encrypted store on your own machine, and nowhere inside the project the agent can read. Third, let the agent request an action, never a value. Fourth, keep a visible record of what was used, when, and for which task, so that you can answer the question every owner eventually asks: what did the agent do with my access?

The tools for this are arriving. At Silent Key Technologies we build around the same belief, and our latest product, NOAI, is a small local vault made for exactly this moment: it holds your keys encrypted on your own computer and lets your agents use them without ever being handed them. We did not build it because agents are dangerous. We built it because they are useful, and useful things deserve a safe way to be trusted.

The next decade of software will be written by teams of people and agents together. The teams that do well will not be the ones that trusted their agents the most. They will be the ones that designed their systems so that trust was never required to hold a secret.

Also published on LinkedIn on 5 October 2026: Agents need access, not secrets