From ClawKeeper to AgentKeeper: What We Learned About Securing AI Agents

We put ClawKeeper out there, and the response was immediate. People were clearly trying to figure out how to safely run AI agents with this much access to real machines.

ClawKeeper was intentionally simple. You could run a single command, get a security assessment of your environment, fix common issues, and start monitoring the deployment. There was no complicated setup and no security platform to learn before you could understand whether you had a problem.

ClawKeeper picked up users quickly, and the adoption gave us useful feedback about what people were actually worried about when they started putting agents into their environments.

More importantly, it showed us that agent security was not going to be limited to OpenClaw. OpenClaw was one manifestation of a much bigger shift.

As we watched ClawKeeper users deploy agents and the broader ecosystem develop, we started seeing the same problem in other environments.

Agents were showing up in developer workflows, terminals, repositories, and cloud environments. They were getting access to MCP servers, APIs, credentials, files, and other systems.

Securing the machine underneath the agent was still important, but it was only part of the problem. The bigger issue became agent behavior. That led to AgentKeeper.

ClawKeeper gave us a front-row seat to how quickly agents were being adopted and where security gaps were appearing. The more we saw, the clearer it became that the security boundary needed to move closer to the agent itself.

With ClawKeeper, we were asking questions about the environment:

With AgentKeeper, we are interested in the runtime activity of the agent:

One of the things that makes agent security difficult is that permissions alone do not tell you very much.

An agent might legitimately have access to a repository, a shell, an MCP server, and a set of credentials. None of those permissions necessarily tell you whether a particular action is appropriate.

An agent may have access to a production credential but have no reason to use it during a particular development workflow. It may be allowed to read files in a repository but have no legitimate reason to access a local credentials file. It may be able to invoke an MCP tool, but the arguments could turn a routine operation into something much more concerning.

You need the context around the action to make a useful security decision. Instead of treating an agent action as an isolated event, AgentKeeper can evaluate available context across the agent, user, environment, repository, tool, and action.

That gives security teams something much closer to the information they need to make a decision.

Since making the move from ClawKeeper to AgentKeeper, we have continued to see strong adoption. We have gone from a product built specifically around securing OpenClaw to a platform used by hundreds of users across the broader AI agent ecosystem.

The original ClawKeeper thesis was that people needed help securing autonomous agents. The adoption we saw after launching it validated that thesis.

The growth of AgentKeeper is validating something broader. Organizations are putting increasingly capable agents into environments where they have access to things that matter, changing the security model once again.

There is a tendency to approach AI agent security the same way we have approached other software security problems. We scan the environment, identify vulnerabilities, lock down permissions, and move on.

These controls still have value, but agents introduce a behavioral component that is difficult to capture with static analysis. Consider scenarios that would not necessarily show up in a vulnerability scan:

You need visibility into runtime activity to understand what actually happened. We built AgentKeeper around runtime behavior and policy, including pre-execution enforcement where supported integrations expose that control point, rather than treating agent security as another configuration checklist.

The answer to the security problems created by agents is not to tell developers they cannot use them.

Agents are already becoming part of the development workflow. They are writing code, debugging systems, working with repositories, interacting with infrastructure, and connecting to services that contain sensitive information.

Security teams need a way to support that adoption without relying on blind trust. They need to understand what agents are doing across the organization so they can establish policy around specific behaviors.

When something does happen, enough runtime context can help reconstruct what the agent did and why.

ClawKeeper was built around the specific problem of running OpenClaw securely. It took off because people were already looking for an answer, but the problem was bigger than one agent framework. As agents moved into more developer workflows and started interacting with more systems, the security boundary moved with them.

The answer requires understanding the agent's execution context. You need visibility into its runtime behavior. Where the agent integration supports it, you also need the ability to enforce policy on the actions that matter.

ClawKeeper helped secure the environment where the agent ran. AgentKeeper is focused on securing what the agent actually does.

The adoption we have seen through both products has reinforced that people want to use these systems. The security model needs to catch up with how these agents actually operate.