API keys and agents: how approval before retrieval works

Extella — Wed, 28 Oct 2026 08:12:32 +0000

In May 2026, an administrative key for LiteLLM's internal agent platform appeared in a public repository. The team deleted the file but did not revoke the key. An attacker used it in October, extracted other credentials and gained access to the release pipeline. The sequence is documented in LiteLLM's investigation.

Revoking the exposed key would have stopped that credential from working. Removing the file did not. GitHub's guidance puts revocation or rotation before cleaning up repository history.

Preventing the next copy from leaking is a separate problem. In a project built with an AI agent, a key can enter the model's context through a chat message or a file-reading tool. Excluding .env from Git does not stop a program with file access from reading it.

The agent can write code using a key name. The running program still needs a way to authenticate its API requests.

In Extella, where agents can build and run programs, we use KV vault to separate those steps. The agent works with the name of a saved key. A person enters its value in a desktop window and approves each new request to retrieve it. This adds a decision before the program receives the secret, with consequences for both security and unattended work.

Saving the value outside the chat

The application starts the save flow with POST /api/desktop/kv/save, supplying a suggested key name, an application name and a reason.

Extella Desktop opens a separate input window. The user enters the secret there. Desktop encrypts the value on the device before sending the record to KV storage, which stores values under names such as openai_api_key.

The encryption key is derived from a PIN-secret held in Desktop on the user's device. That PIN-secret is not stored with the KV record. The application receives the saved name and a status, without the secret value. During this save flow, the plaintext does not pass through the model or the OS server.

The program can now contain a reference to openai_api_key. Copying that source file copies the name. This depends on the program keeping the value out of source files, logs and generated output when it later retrieves it.

Asking for access

The program authenticates to the OS API and calls POST /api/desktop/kv/request with the key name, an application name and a reason. The credentials used to authenticate this request need protection too; moving one API key into a vault does not remove every credential from the application.

Desktop displays the request and offers Allow or Deny. The user is approving the release of the value to the requesting program, not just revealing it on screen. A new retrieval requires a new approval. Another program knowing the key name is not enough for it to retrieve the value through this API.

The application name and reason come from the request. They help the user understand what is being asked, but do not verify the identity or behaviour of the code. A convincing explanation in a prompt is not proof that the program will use the key as described.

While waiting, the program polls GET /api/desktop/kv/requests/{id}. If the user declines or the request expires, the program should stop and report that outcome. It should not keep opening new requests until the user accepts one.

What happens after Allow

Desktop decrypts the value on the device. The plaintext then passes through Extella OS server memory to the requesting program.

The first poll after approval receives the value. The server removes its pending copy, and later polls report delivered. An approved value that the program never retrieves expires after 60 seconds. A request that receives no answer expires after 180 seconds.

These are delivery time limits. They do not make the underlying API key expire, and they cannot stop a recipient from keeping its own copy.

Stage	Where the usable secret is
User saves the key	Desktop handles the plaintext and encrypts it before storage.
Key is stored	KV contains ciphertext; the PIN-secret stays in Desktop.
Program requests access	Knowing the name does not grant retrieval; the request waits for the user's decision.
User approves	Desktop decrypts the value; OS server memory and the receiving process handle the plaintext.
Delivery completes	The server removes its pending copy. The receiving process may still hold the value.

The program uses the key to call the external API and returns the result of its task. It must keep the secret out of that result. If it prints the key or includes it in a response to the agent, the model can see it despite the earlier approval step.

What this changes, and what it leaves exposed

The design separates access to project files from access to the stored secret. An agent can read the project and work with a key name without finding the value in .env. A copy of the KV record contains ciphertext rather than a ready-to-use API credential.

That distinction does not establish that the whole system is safe from compromise. Desktop must protect its PIN-secret and handle approval. The OS server handles plaintext during delivery. The receiving program can expose it through memory, logs, files or its output. Those components remain part of the system that has to be trusted.

Approval also does not change the permissions granted by the external service. If a key has administrator rights, Allow hands the program a credential with those rights. A program that reads one table should have a credential limited to that task. OWASP's secrets-management guidance covers access restrictions, expiration and revocation alongside storage.

Once someone has copied a plaintext key, denying later vault requests cannot revoke it. The issuing service must invalidate it. If an attacker still controls the runtime, replacement keys may be stolen too; the operator needs to remove that access before restoring secrets to the environment.

The cost of requiring a person

Each new retrieval depends on an open Desktop session and a person answering the request. That fits a session where someone is present to review what the program is doing. It does not fit a job that must obtain fresh access at 3 a.m. with nobody available.

Keeping a plaintext key in a long-running process may avoid another retrieval, but then the process continues to hold the credential. The approval window does not give the user control over every subsequent API call made with that copy.

An application hosted elsewhere also needs code changes to use this retrieval flow. It can avoid storing the external API key in that host's environment settings, but the host can still capture the key once the running application receives it. The integration does not make a compromised host trustworthy.

For an implementation review, follow the value through one complete request: entry, encrypted storage, approval, delivery and use. Use a fake secret in a disposable configuration to check whether it appears in tool output or logs. Test refusal and timeout handling as well. Such checks cover the paths exercised; they do not amount to a security audit of the vault.