7 Controls for OpenClaw Agents in Production

By Karl Lehnert, Director, DevProStudio

Getting an autonomous agent to call a business tool is the easy demo. The production problem starts one minute later: the agent has a plausible reason to send an email, update a record or trigger a workflow, but its reasoning is wrong.

That risk is becoming more immediate as the Model Context Protocol (MCP) moves from developer convenience to infrastructure. Recent reporting describes MCP gateways crystallising as a control layer. For Australian SMEs, that is the useful shift: stop treating agent safety as a better system prompt and start treating it as systems engineering.

OpenClaw-style agents can watch for work, reason across context and operate tools. They are valuable precisely because they can act. These seven controls preserve that value without giving a probabilistic system the keys to everything.

1. Give every agent a named identity

Do not run an agent through a shared administrator account. Give the runtime its own service identity and make each delegated user or workflow visible in the audit trail.

An identity should answer three questions: which agent acted, on whose behalf, and under which policy version? If an incident cannot be tied back to those facts, investigation becomes guesswork.

The MCP authorisation specification provides a protocol-level basis for protected MCP servers. It does not remove the need to design identities and permissions in the business systems behind them.

2. Default to no tools, then allow narrowly

A production agent should begin with no authority. Add only the tools required for its defined job. Within each tool, narrow the accessible records, fields and actions.

Separate reading from writing. An agent that prepares a draft from a CRM does not automatically need permission to change the CRM. A stock-checking agent does not need access to payroll. This sounds obvious, yet broad integration accounts are a common shortcut because they make the first demo faster.

Our operator view is blunt: MCP is a protocol boundary, not a trust boundary. A tool appearing in an MCP catalogue does not make its inputs safe, its output reliable or its permissions appropriate.

3. Put approvals around consequences

Human approval should follow impact, not novelty. Reading a public product catalogue may be automatic. Sending a quote, changing a bank detail, deleting a file, publishing content or disclosing personal information should cross an explicit approval boundary.

Make the approval useful. Show the proposed action, destination, important source data and reason. A button labelled “approve” beside a vague agent summary is ceremony, not control.

Where possible, make actions reversible. Draft before send. Queue before publish. Soft-delete before permanent removal. Limit transaction values and recipient domains. These constraints reduce the blast radius when the model, the source data or the tool behaves unexpectedly.

4. Validate every tool contract

Treat agent-generated arguments as untrusted input. Validate types, allowed values, record identifiers, destination domains and maximum lengths before a tool executes. Reject unknown fields rather than quietly accepting them.

The same caution applies on the return path. Tool output can contain malicious or simply irrelevant instructions. The OWASP Top 10 for LLM applications is a practical starting point for threats such as prompt injection and insecure output handling.

Tool descriptions also need version control. A small wording change can alter when an agent selects a tool. Test contracts and selection behaviour as you would test an API.

5. Keep an audit trail that helps

Logging every token is expensive and can create a new privacy problem. Logging nothing makes support impossible. Capture the operational events that let a person reconstruct a decision: agent and user identity, tool selected, policy decision, approval, material inputs, result, timestamp, model/version and correlation ID.

Redact secrets and minimise personal information. Define retention periods instead of keeping traces forever. The aim is accountable operations, not surveillance.

The NIST AI Risk Management Framework is useful here because it frames AI risk as an ongoing govern-map-measure-manage cycle. A launch checklist alone cannot manage a changing agent, model and toolchain.

6. Test the ugly paths

Happy-path tests prove the integration works. Production tests should prove it fails safely.

Try missing records, conflicting instructions, expired credentials, tool timeouts, duplicate events, oversized attachments, malicious text in a document and a human rejecting an approval. Confirm retries cannot create duplicate invoices or messages. Confirm the agent stops when authority is unclear.

This is also where AI-assisted delivery controls matter. Coding agents can help build test fixtures and exercise edge cases, but a responsible owner still decides which business consequences are unacceptable.

7. Budget for the whole operating loop

Token price is only one line. Estimate model usage, MCP or API calls, hosting, secrets management, logs, evaluation runs, human approvals, support and incident rework. Then compare the cost per correctly completed workflow, not the cost per prompt.

A practical pilot budget has three bands: normal volume, a retry-heavy month and a hard ceiling. Add alerts before the ceiling. Cache stable context, avoid returning huge tool payloads and use a smaller model for classification when testing shows it is adequate.

This approach also makes build-versus-buy decisions clearer. A subscription may win for a standard task. A controlled OpenClaw-style agent becomes attractive when the workflow crosses several systems, needs business-specific rules or requires an audit trail the packaged tool cannot provide.

A common implementation pattern

Consider a service business that receives emailed job requests. This is a pattern, not a claimed DevProStudio client result.

The agent reads a dedicated inbox, extracts job details, checks the customer record and drafts a work item. It cannot email the customer or schedule staff directly. Validation rejects unknown customer IDs and dates outside an allowed window. A coordinator reviews the source email, extracted fields and proposed action, then approves creation. Each step shares a correlation ID.

The design is deliberately less magical than the demo. It is also supportable. Once error rates and edge cases are understood, low-risk steps can be automated selectively.

Australian privacy is part of the architecture

The Australian Privacy Principles cover how regulated organisations handle personal information. The OAIC also publishes guidance for commercially available AI products.

Before connecting an agent, document the business purpose, data classes, storage locations, overseas disclosures, access controls and retention. Minimise what reaches the model and each tool. Do not assume a vendor security page transfers accountability away from the business deploying the workflow.

For sensitive actions, maintain a non-AI route and an incident process. Know how to revoke credentials, stop schedules, preserve relevant evidence and notify the right owner.

Frequently asked questions

What is an OpenClaw-style agent?

It is an autonomous agent runtime that can receive work, reason over context and use connected tools on a schedule or in response to events. In production, its value depends on constrained permissions, observable actions and clear human ownership.

Is MCP secure by default?

MCP standardises how models and tools communicate, but it is not a complete security boundary. Each deployment still needs authentication, authorisation, input validation, safe output handling, network controls and lifecycle ownership.

Which agent actions should require approval?

Require approval when an action is irreversible, financially material, externally visible, privacy-sensitive or capable of changing access. Low-risk reads and reversible drafts can often run automatically after testing.

How should an SME start with autonomous agents?

Choose one bounded workflow with a named owner and measurable completion criteria. Map its data and actions, grant minimum access, add approvals and logs, test failure paths, then expand only after real operating evidence supports it.

Build the controls before widening access

The production advantage is not maximum autonomy. It is dependable autonomy: the agent handles routine work while the surrounding system controls identity, permissions, consequences and evidence.

DevProStudio designs practical custom-agent and OpenClaw-style operating patterns for Australian businesses. If you have a workflow that crosses inboxes, documents, APIs or internal systems, talk with DevProStudio about making it bounded and production-ready.