OpenClaw got me thinking: how do we secure agency?

I’ve been spending a lot of time looking at OpenClaw lately. At first, I was mostly interested in a fairly practical question: How do I run something like this safely? That question quickly turned into a much bigger one, because OpenClaw is not really the interesting part. The interesting part is what OpenClaw represents.

We are moving from AI systems that answer questions to AI systems that can act. They can read our email, access our files, browse websites, interact with applications, use APIs, write code, and communicate with other systems. Eventually they will routinely purchase things, modify infrastructure, negotiate with other agents, and execute business processes without a human approving every individual step. That changes the security problem completely.

This article grew out of a more practical question I was working through: how would I deploy OpenClaw safely today? I wrote up that architecture separately in How I Would Deploy OpenClaw Safely.

We Have Spent Years Securing Information

Most enterprise AI security conversations today revolve around information. What data can employees put into AI? Where does that data go? Is it retained? Can the model train on it? How do we prevent sensitive information from leaking? Those are important questions, but agents add something much more consequential: authority.

Once an AI system can take action, we are no longer just protecting information. We are protecting what the system is allowed to do, and I think that will become one of the defining security challenges of the next decade.

Synthesis

The Model Cannot Be the Security Boundary

The obvious security strategy is to make the model better at recognizing malicious instructions, and we should absolutely do that. But I would not bet an enterprise security architecture on the assumption that models will eventually become impossible to manipulate.

A sufficiently complex system will make mistakes. An agent will misunderstand something. An attacker will discover a new prompt injection technique. Bad information will enter memory. A tool will behave unexpectedly. A model will hallucinate. Something will eventually go wrong, so I keep coming back to one principle:

Assume the agent will eventually be manipulated, confused, compromised, poisoned, or simply wrong. Make that survivable.

That is how mature security already works. We do not expect perfect users, perfect applications, or perfect endpoints. We build controls around failure, and agents need the same approach.

Proposal

AI Should Request Authority

This is probably the most important design principle I see emerging. An agent should not permanently possess broad authority. It should request temporary authority based on what it is currently trying to accomplish. Suppose an agent wants to send an email. Instead of already holding unrestricted Gmail access, it requests permission:

Send one email to this recipient for this task.

A separate security layer evaluates that request. Who started the task? What is the agent trying to accomplish? Where did the information driving the action originate? Is this recipient allowed? Does policy permit this? Does a human need to approve it? If the action is acceptable, the agent gets the minimum capability required to perform it, and then that capability expires.

The model never owns the underlying authority. It borrows it, and I suspect that separation becomes foundational to agent security. It creates a powerful distinction:

The agent can reason freely without being able to act freely.

Every Task May Need an Identity

Agents are also going to create an identity problem. Consider:

Human → Executive Agent → Research Agent → Travel Agent → Purchasing Agent

The purchasing agent spends $3,000. Who authorized the purchase? Where did the authority originate? Was purchasing even part of the original task? Did one agent accidentally grant another agent more authority than it had itself? Traditional IAM was not designed around these kinds of delegation chains.

I think future agent systems will need to track something like task identity. A task should carry:

• original human principal
• agent identity
• purpose
• capabilities
• restrictions
• spending limits
• expiration
• delegation depth

Authority follows the task, and privileges should only move in one direction: down. If an agent has permission to spend $1,000, any sub-agent it creates should be limited to $1,000 or less. A delegated identity should never magically become more powerful than the identity that delegated to it. That sounds obvious, but once thousands of autonomous agents are delegating work to each other, it becomes critical.

Memory Will Become an Attack Surface

I also think we are underestimating what persistent agent memory means for security. Imagine an attacker sends malicious content to an agent. The agent processes it, and a summary gets stored in memory. Months later, the original malicious message is gone, but the resulting information remains. Now the agent retrieves that memory as something it already "knows." The distinction between untrusted external content and internal knowledge has disappeared. That is potentially a new form of persistence.

So memory itself needs security metadata. Every memory should have provenance. Where did it come from? Who created it? How trustworthy was the source? When was it created? Has it been independently verified? Can it influence actions? A statement like:

John may approve invoices.

might be fine as searchable information. It should not automatically become authorization, and that distinction is going to matter.

Context Needs Provenance

Prompt injection exists partly because models have difficulty distinguishing content from instructions. Security systems can compensate for that. Instead of simply passing an email into the context window, attach security metadata:

SOURCE:
External email

TRUST:
Untrusted

CAN PROVIDE INFORMATION:
Yes

CAN CHANGE OBJECTIVE:
No

CAN AUTHORIZE ACTIONS:
No

Now even if the model misinterprets the email, an external policy layer understands the origin of the requested action. This starts looking a lot like taint tracking in traditional application security, except now we are tracking the provenance of information moving through a reasoning system. I think this could become extremely important.

MCP and Agents Create a New Supply Chain

Agent ecosystems will also create a completely new software supply chain. Today we worry about:

• packages
• SaaS integrations
• container images
• browser extensions
• APIs

Agent environments add:

• MCP servers
• skills
• tools
• prompts
• memory databases
• sub-agents
• connectors
• browser automations
• third-party agents

Eventually, organizations will need to know exactly what an agent is made of. I could imagine something analogous to a Software Bill of Materials: an Agent Bill of Materials, or ABOM. It might document:

• model
• runtime
• tools
• MCP servers
• policies
• memory stores
• container
• connectors
• software versions
• cryptographic hashes

When an agent performs a sensitive action, security teams should be able to reconstruct the system that made the decision. That is going to matter for both incident response and compliance.

Agents Will Need Zero Trust Too

As agents begin interacting with other agents, the architecture starts looking very familiar. We will have:

Agent → Agent → Agent → API

At that point, every agent needs an identity, every request needs authentication, every delegation needs authorization, and every communication path needs a trust decision. A compromised agent should not automatically be trusted because it is "inside." That is essentially Zero Trust for artificial workers. The same principles still apply: Never trust. Always verify. Minimize privilege. Assume breach. We are just applying them to a new kind of workload.

I Think Agent Detection and Response Is Coming

Eventually, security teams will also need behavioral monitoring specifically designed for agents. Today we have EDR, Endpoint Detection and Response. I think we are going to end up with something resembling Agent Detection and Response.

The security team will want to know: Why did this agent suddenly read 30 times more documents? Why is it querying HR records? Why did it contact a domain it has never used before? Why did it spawn 50 sub-agents? Why did it begin modifying its own configuration? Why did its API usage suddenly spike?

And eventually I expect a very familiar security control: ISOLATE AGENT. Disable its network, revoke its capabilities, freeze its memory writes, stop its jobs, preserve evidence. If agents are going to become autonomous digital workers, they are eventually going to require monitoring very similar to other privileged workloads.

Proposal

Human Approval Is Only a Temporary Solution

Right now, one of our primary safeguards is human approval. That makes sense, but I don’t think it scales. Imagine having ten agents generating hundreds of actions every day. Eventually:

Approve
Approve
Approve
Approve
Approve

becomes meaningless. The better long-term model is policy. Instead of approving every airfare transaction, I approve:

My travel agent can purchase domestic airfare under $1,500 through approved vendors until Friday.

The agent operates autonomously within that envelope, and anything outside the policy requires escalation. That preserves autonomy without giving the system unlimited authority.

Proposal

The Long-Term Product Is Not Another Agent

This is where my thinking ultimately landed. If I were building something today with a five-year horizon, I would not build another agent framework. I would build the security layer every agent framework needs. Think Okta + Vault + CrowdStrike + Cloudflare + Kubernetes RBAC for autonomous agents: an agent security control plane. It would handle:

• agent identity
• task identity
• delegation
• capability authorization
• credential brokering
• network controls
• DLP
• memory provenance
• MCP security
• agent-to-agent trust
• sandboxing
• behavioral monitoring
• audit
• circuit breakers
• incident response

And the agent underneath becomes interchangeable: OpenClaw, IronClaw, OpenAI, Anthropic, Google, Microsoft, some internal agent built six months from now, something we have not heard of yet. The security architecture should survive all of them.

Synthesis

The Real Problem Is Securing Agency

That is ultimately what OpenClaw has me thinking about. It is not really an OpenClaw problem. It is an agency problem. We are starting to give software discretion and authority, and increasingly we are allowing it to act without a human explicitly controlling every step.

I do not think the answer is trying to create an AI system that never makes a bad decision. That feels unrealistic. The better goal is to ensure that a bad decision cannot automatically become a catastrophic action. The long-term rule I keep coming back to is:

No autonomous action should happen without an identity, an attributable delegation chain, a scoped capability, a valid policy decision, an acceptable level of risk, and an auditable record.

OpenClaw happens to be one of the technologies forcing us to think about that question today. Five years from now, the name of the agent may be completely different, but the underlying security problem will still be there. We are not just figuring out how to secure agents. We are figuring out how to secure agency.