Original interpretation: The real priority for Agent credential security is not 'where to put it', but 'who can touch it and when'

Copyright Statement and Disclaimer This article is an original interpretation based on “Show HN: ClawShell, Process-Level Isolation for OpenClaw Credentials”. The copyright of the original text belongs to the original author and source. This article does not constitute an official translation and is only used for learning, research and discussion of opinions.

Original reference Show HN: ClawShell, Process-Level Isolation for OpenClaw Credentials: https://github.com/clawshell/clawshell

Beginning: The most common mistake in credential security is not that it is not encrypted, but that everyone feels at ease after encrypting it.

Sun Wei has been working in the security industry for fifteen years and has seen various credential management solutions, but the confusion brought to him by the OpenClaw era was completely new.

Last year, he was responsible for assessing a company’s Agent system security posture.

It was an ordinary Wednesday afternoon, and the sun was shining brightly in the conference room. The client’s security manager, Lao Zhou, is a middle-aged man in his forties, wearing a neat shirt and a pair of gold-rimmed glasses. He looks like a typical “security expert”. With a thick stack of documents spread out in front of him, he confidently described their credential protection measures.

“Our keys are all hosted in Vault,” Lao Zhou pointed to the architecture diagram on the projection screen, “TLS encryption during transmission, AES-256 encryption during storage, and a regular rotation policy—automatic rotation every 90 days. Credential security should be our strength.”

Sun Wei nodded with a polite smile on his face. He had seen this kind of confidence too many times. He waited for Lao Zhou to finish, and then asked a question that stunned the other party: “Can you tell me when, by whom, and in what way these keys were accessed?”

Lao Zhou was stunned for a moment, obviously not expecting this question. He adjusted his glasses, thought for a while and said, “You should be able to check the audit log… Our Vault has complete audit functions.”

“Then what was the context of the latest access?” Sun Wei asked, leaning forward slightly, “What task was the Agent performing at that time? What is the scope of permissions for this task? After the task is completed, are the credentials recycled or continue to reside in the memory?”

The conference room was quiet. Lao Zhou opened his mouth, but couldn’t answer. He turned to look at his team, hoping someone could help answer, but everyone else also looked at each other.

Sun Wei leaned back in his chair and did not continue to ask. He has seen too many scenes like this - the team puts all their attention on “where the key is placed”, but few people seriously think about “who is using the key”.

This is the popular statement I want to clearly refute: The key to credential security is not “where” but “who can touch it and when”. ** If this matter is not made clear, no matter how secure the storage layer is, there will still be a huge, continuously charged risk surface during operation.

Whenever you talk about credential security today, teams almost instinctively focus on three actions: Escrow, Encryption, and Rotation. They were all important and indeed formed the dominant security narrative for a long time. But once the system enters the Agent era, this narrative begins to seem insufficient. Because the danger no longer only comes from “someone took the key away”, but increasingly from another more hidden situation: the key is already in the system, and is used compliantly by a process that should not be using it, in a context that should not be executed.

This is why everyone feels relieved after encryption, which is a dangerous illusion.

Why is this statement so popular?

“Keep your keys safe” is popular not only because it sounds right, but also because it can easily be turned into a checklist.

You can prove:

• The key is not in the code repository
• Keys are stored in specialized systems (Vault, KMS, Secrets Manager)
• Keys have a rotation policy (automatically rotate every 90 days)
• Access is permission-controlled (IAM policy restrictions)

These actions are visible, auditable, and reportable, so they are naturally suitable for organizational communication. Management likes it because it’s clear, compliance teams like it because it’s a tick-box, and engineering teams like it because at least it doesn’t directly change the execution chain like runtime isolation does.

Sun Wei has seen too many security assessment reports, and the core content is to check these checklist items. The report will usually say: “The customer uses an industry-standard key management solution, and the transmission and storage are encrypted and protected, in line with security best practices.” But Sun Wei knew that this assessment missed the most critical question: What happened when the key was used?

The problem is, popularity doesn’t equal enough. When systems like OpenClaw have execution capabilities, the real danger is not just “whether the secret is hidden”, but whether the secret is restricted to the correct subject and action at the moment it is called.

The popular credential security narrative has an implicit assumption: As long as keys are stored securely and access controls are configured correctly, security is complete. But this assumption no longer holds true in the Agent era. Because Agent is not a traditional “request-response” program, it is a continuously running, stateful entity that may automatically perform complex actions. It may attempt to use the key at any time, in any context, and for any reason.

If the system cannot answer “who can touch it and when”, then the answer to “where” is perfect, but it is only the first half of the security story.

But what is this popular saying missing?

It’s missing the words “runtime”.

Just because a key is stored perfectly does not mean it is used perfectly. The real trouble comes when a process gets its hands on it, when a task context gets close to it, when a high-risk call tries to rely on it. At this time, the risk has little to do with the storage location and has a lot to do with the execution boundary.

In other words, static security answers at most “who has the opportunity to access the secret”, while runtime security only answers “who has the opportunity to do things with the secret”. For the Agent system, the latter is often closer to the accident ontology.

Sun Wei often finds this kind of gap during evaluation. At the storage level, keys are indeed well protected - Vault has strict access control, only specific roles can read, reads require approval, and there are complete audit logs. But at the runtime level, once the key is read into the memory, it becomes the “property” of the process, and the process can use it in any context, and the system will not ask.

what does that mean? This means that the most vulnerable moment of the system is not when the secret is lying quietly, but when the secret begins to be “reasonably called”. Because the more reasonable it seems, the harder it is for the team to notice something is wrong in the moment.

Sun Wei told a real case. A certain company’s Agent system has very standardized key storage, but there is a problem during runtime: the Agent main process will read all possible keys when it starts and load them into memory. Agent has a plug-in mechanism that allows new functionality to be loaded dynamically. A certain plug-in was designed to read emails, but during development, the developer directly used the database key in memory to store the email digest for convenience - this should not have happened, but there is technically no stopping mechanism.

As a result, a plugin that was supposed to only have access to email actually had full access to the database. This permission is never explicitly granted, it is “inherited” - from the main Agent process, and from the key cache of the main process. Access control at the storage level is completely broken because the key is already in memory and can be used by anyone.

This is the cost of missing runtime isolation.

The question is not “whether the key is encrypted”, but “whether the system has divided the usage rights into enough details”

The point I want to refute most is that many teams have put a lot of effort into credential security, but the real default premise is still very crude. The key is securely escrowd, but once it enters the task process, it is like a long-term passport; as long as an execution chain has it, it can cross the fine-grained boundaries where multiple contexts should exist.

what does that mean? This means that the most vulnerable moment of the system is not when the secret is lying quietly, but when the secret begins to be “reasonably called”. Because the more reasonable it seems, the harder it is for the team to notice something is wrong in the moment.

So I want to give a more pointed statement: **Many OpenClaw credential incidents are not failures in secret custody, but failures in splitting usage rights. **

What does splitting of usage rights mean? It means:

• The existence (being stored) of a key does not equal the availability (being used) of the key
• Just because a process can access the key does not mean that all actions in the process should be able to use the key.
• Task A has the right to use the key, which does not mean that task B also has the right to use the same key.
• Having the right to use it under normal circumstances does not mean that you still have the right to use it under abnormal circumstances.

Sun Wei’s ideal credential security model is as follows:

• Keys are stored with the highest level of security (encryption, access control, auditing)
• When the key is read, there is a clear context and time limit (who read it, why it was read, how long it is valid after being read)
• There is an independent authorization check when the key is used (even if the process holds the key, it still needs to verify permissions each time it is used)
• After the key is used, it will expire or be recycled immediately (it will not reside in memory for a long time)

This model separates each link of “storage-read-use-recycling”, and each link has independent control and audit. Instead of like now, once read, it is equivalent to unlimited authorization.

A judgment framework closer to reality

If you want to judge whether an Agent credential system is mature enough, Sun Wei will not just ask whether it is encrypted, but will ask four things.

**First, whether the credentials are gradually narrowed at the session level, task level, and action level. ** If not, but high permissions are resident for a long time, then sooner or later the system will increase the risk during operation.

Gradual narrowing means that the key’s usage rights should change as the context changes. The Agent may only have the most basic permissions when it is started. When a specific task is assigned to the Agent, the system will temporarily grant the specific permissions required for the task, and the permissions will be revoked immediately after the task is completed. The action level goes one step further: even within a task, different actions may have different permissions. Read operations may not require a key, write operations may require a specific key, and high-risk operations may require additional confirmations.

**Second, does obtaining the credentials mean that high-risk actions can be performed by default? ** If the two are almost connected together, it means that the system still confuses “identity” and “execution power”.

Ideally, holding the key is only one of the necessary conditions for execution, not a sufficient condition. The system should ask: Who are you (authentication)? What do you want to do (intent recognition)? Is this allowed by the current context (environment check)? Is this action within your authority (authorization check)? Execution is only allowed if all checks pass.

**Third, is there any instant circuit breaker capability under abnormal context? ** Once the task target drifts, the parameters cross the boundary, or the context is suspicious, should the system continue to let the process try, or stop it first?

Sun Wei has seen too many systems that continue to execute even when “it doesn’t look right” because “the process has permissions anyway”. A truly safe system should tend to stop when something goes wrong, rather than tend to continue. Circuit breaker is not a failure, but a protection mechanism.

**Fourth, can the audit explain “why this use is allowed?” ** If the audit can only tell you that it is used, but not why it can be used, it is just accounting, not governance.

A complete audit should include: key identification used, task context when used, basis for authorization decisions, specific actions performed, results of execution, and exception flags (if any). Such audits make post-mortem analysis possible and provide a basis for anomaly detection.

Under what circumstances does the old statement still partially hold?

Of course, I’m not saying that storage security isn’t important. For simple scripts, low-execution automation, or very small-scale internal tools, getting the keys in the right place is still a high priority. Without this layer, there would be nothing to talk about later.

Sun Wei gave an example: a scheduled task that runs once a day, only performs data backup, does not involve complex decisions, and does not interact with other systems. In this scenario, key storage security may be sufficient because the runtime risk is inherently low.

But once the system enters the era of Agent execution, especially with tool invocation, environment access, cross-task context and automatic operation capabilities, it will become increasingly dangerous to continue to understand credential security mainly as a “storage problem”. Because at this time the real expensive risk has shifted from “loss” to “misuse”.

Misuse is harder to prevent than loss because it often occurs during “normal” business processes, with no obvious signs of attack or abnormal behavior patterns. The system read the key “normally” and performed the operation “normally”, but this “normally” should not happen under the specific context.

Conclusion: If the system cannot restrict who can use secrets under what circumstances, then “well-kept” is just a comfort word.

Sun Wei usually writes this paragraph at the end of the evaluation report:

“Credential security assessment cannot only focus on the storage level. Although storage security is the foundation, in the Agent era, the real risks often occur at runtime. It is recommended that customers establish a runtime isolation mechanism to ensure that the use of keys is restricted to the correct context and permissions.”

This statement is rarely taken seriously. Because runtime isolation is much more complex than storage encryption, it requires redesign of execution links, requires additional permission checks, and requires more sophisticated auditing. In the short term, it looks like “extra work” rather than a “necessary investment”.

But Sun Wei knew that this investment would have to be paid sooner or later. Either pay proactively and establish a runtime isolation mechanism; or pay passively and bear losses after an accident occurs.

I increasingly feel that the problem with many security discussions is not that the conclusions are wrong, but that they are concluded too early. It is certainly true to say “the key must be encrypted”, but to only say this is equivalent to only saying the first half of the sentence in a system like OpenClaw.

The second half of the sentence should be: Once the secret enters the runtime, it must immediately lose most of its freedom. It should be shorter-lived, more local, more difficult to be reused laterally, and more difficult to be easily taken away by irrelevant actions. Otherwise, all you have done is move a still-dangerous bullet from the desk drawer to the safe; but once someone opens the box, it will still be fired.

So, if I were to make only one judgment today, I would choose this: **The real priority for agent credential security is not “where to put it”, but “who can touch it and when”. ** If this problem is not addressed first, all other reassurances may just be compliance versions of self-comfort.

Sun Wei has recently begun to pay attention to solutions like ClawShell, which attempt to isolate credentials at the process level, making the use of keys an action that requires explicit application and authorization, rather than a default capability. This solution is not mature enough, but it is in the right direction.

Because the ultimate goal of credential security is not to make keys difficult to steal, but to make keys difficult to misuse. The difference between the two is the generation difference in safety thinking.

References and Acknowledgments

• Original text: Show HN: ClawShell, Process-Level Isolation for OpenClaw Credentials: https://github.com/clawshell/clawshell