OpenClaw's introduction in November 2025 unleashed a new class of always-on autonomous agents. They've quickly moved from weekend side projects into everyday enterprise tools — monitoring repos, following up on sales calls, drafting outreach, coordinating work across chat tools.
The autonomy that makes them so exciting is also what makes them hard to manage: when agents act on their own, you need new rules for governing them. The agent can hold credentials, execute code, access internal systems, and take actions through connected tools. Before broad deployment, teams need operational answers to four questions:
- Where does the agent run?
- What can it access?
- Which actions require human approval?
- How is the agent observed, audited, and offboarded?
At Kilo, we're working through these questions alongside our customers. This guide is what we've learned so far and describes a production operating model for autonomous agents to address security, governance, and access concerns.
Autonomy gone bad
As these systems have started to be valuable production systems, and not just toys, prototype patterns are becoming overloaded. In a prototype, one person usually knows where the agent runs, which credentials were added, what the intended workflow is, and how to turn it off. In production, that knowledge has to survive team growth, personnel changes, incident response, audits, and policy reviews.
Common failure modes include:
- Personal API keys copied into prompts or local config files
- Bots using an employee's normal account instead of a dedicated identity
- Agent instances running on unmanaged infrastructure
- No central inventory of active agents
- No clear owner for a bot after an employee changes roles or leaves
- Bots with both broad internal read access and external posting access
- Repository rules that allow bot approvals to satisfy review requirements
- No defined process for reviewing logs or unexpected behavior
The upshot is that many organizations are struggling to manage autonomous agents in production.
A framework for agent autonomy
Always-on agents like OpenClaw are exciting because they reach new levels of autonomy. But enterprise usage requires an agent management framework that renders that makes their identity clear and keeps that autonomy bounded, observable, and revocable.
Bounded autonomy
Security professionals have long understood that least privilege is a baseline for access control. In the context of an autonomous agent, we've taken to calling that bounded autonomy. Bounded autonomy is the notion that the right way to govern an agent is to govern its scope of access, not the autonomy is has within that scope.
For example, when using an agent to monitor community contributed pull requests to a public repo, the right choice is to govern what permissions the agent has to affect the repo, not whether or when it can use the gh CLI tool to inspect the repo.
Baseline requirements for bounded autonomy include:
- Scoped access to each system the bot needs
- Clear rules for which bots may communicate externally
- A review process for expanding bot permissions over time
- Repository rules for bot-authored code
Bounded autonomy also allows humans to build trust in autonomous agentic system. As agents perform well within their scope, they can demonstrate additional scope. For example, an agent that is tasked with email responses can begin by drafting responses in text to be copy/pasted into an email. Once the agent has demonstrated the ability to draft responses, it can be granted the ability to send emails.
Observable autonomy
Like a junior employee, autonomous agents require oversight, particularly in early stages. Designing autonomus agent adoption to facilitate the observability of agent actions is critical to developing a system that delivers value.
The first crucial element of observable autonomy are bot identities. In particular, bots should always have their own identites, not inherit the identity of a human. That includes the identity of the bot itself, as well as company-managed independent identities for all systems that the bot will interact with.
Revocable autonomy
Finally, it has to be the case that autonomy can be revoked. That includes the ability to onboard and offboard agents easily, so it's low cost to have them or to shut them down, and proper secrets handling so revocations have the intended effect.
A reasonable production baseline includes:
- Standard onboarding and offboarding paths through IT
- Encrypted storage and encrypted secret handling
Practical considerations
Within the broad framework of bounded, observable, and revocable autonomy, there are a number of practical questions about how and where the agent should run. Here are the conclusions we've reached so far.
Hosted agent runtimes
OpenClaw and similar autonomous agents have become popular running on individual desktops. While this is an appealing answer to get started quickly, it ultimately renders these agents hard to bound and observe. Instead, autonomous agents should be in a hosted runtime that allows simpler understanding of where they are running and how they connect to other services.
Without a hosted runtime it is impossible to fill out a basic inventory of the agent's runtime that should include clear statements about:
- Runtime owner
- Hosting environment
- Workspace persistence behavior
- Network access policy
- Allowed tools
- Default shell execution policy
- Data retention period
- Deletion procedure
- Incident response owner
If the agent runs on shared infrastructure, document how tenants, projects, or users are separated. If the agent runs in a dedicated environment, document what is dedicated and what is shared. The important thing is that the runtime model is explicit enough for security review and incident response.
Use dedicated bot identities
A production bot should have its own identity. It should not run as a human's normal account unless there is a documented reason and compensating control.
A standard work-bot identity model includes:
- A company-domain email address, such as
[name].bot@company.com - A naming convention that clearly marks the account as a bot or internal agent
- An assigned human owner
- Read-only email access by default
- No email sending unless explicitly approved for the use case and best if from a different domain
- Dedicated service accounts or seats for required systems
- Inclusion in normal onboarding and offboarding workflows
This creates a clear distinction between the human identity and the bot identity. It also makes incident response simpler: revoke the bot account, rotate its credentials, destroy its runtime, and review its logs without disrupting the human user's normal access.
Provision credentials for the bot
An extension of a dedicated identity is that identity should persist across systems with specifically-provisioned credentials to all systems. The production pattern is to provision access specifically for the bot:
- Create a dedicated account or integration for each service the bot needs.
- Scope permissions to the workflow rather than mirroring the human owner's access.
- Store credentials in 1Password or a similar secrets manager.
- Avoid pasting secrets into chat, memory files, prompts, or issue comments.
- Rotate credentials when the bot changes ownership or scope.
- Remove credentials during offboarding or runtime destruction.
Teams should be able to answer these questions without searching chat history:
- Which bots exist?
- Who owns each bot?
- Which systems can each bot access?
- Which credentials are assigned to the bot?
- Where are those credentials stored?
- How is access revoked?
If those questions cannot be answered from inventory and access-management systems, the deployment is not ready for broad use.
Separate internal data access from external communication
The simplest rule for reducing blast radius is this:
Bots can have access to internal data or the ability to communicate externally. Not both.
It prevents the most dangerous default configuration: a bot that can read sensitive internal systems and also post freely to external channels.
Examples:
- A bot that reads internal logs should not post to Discord or Telegram.
- A bot that helps with external community responses should not have access to any non-public issues, docs or code.
- A bot that can access customer data should not be able to send email without human approval.
- A bot that summarizes internal docs can respond in internal Slack, but should not be connected to personal chat channels.
Some organizations will approve exceptions. Those exceptions should be documented with the bot owner, business purpose, allowed systems, allowed channels, data classification, and approval requirements.
Require approval for high-risk actions
Prompt injection should be handled as an expected failure mode. A malicious webpage, issue comment, document, or chat message may try to make an agent ignore instructions, reveal data, or execute unsafe commands.
The practical response is to keep high-risk controls outside the agent's discretion. Actions that are hard to undo, externally visible, or access-changing should require explicit human approval.
Common approval-gated actions include:
- Shell command execution
- Sending email
- Posting to external channels
- Creating or changing production configuration
- Deleting data
- Approving or merging pull requests
- Rotating or exposing credentials
- Making purchases or changing billing settings
The exact list will vary by organization. The important part is that the list is explicit, enforced, and reviewed as workflows change.
Set repository controls for bot-authored code
Repository access deserves separate treatment because agents can generate code and open pull requests.
A common safe pattern is:
- Allow bots to create issues.
- Allow bots to open branches and pull requests.
- Allow bots to comment on failures or suggest fixes.
- Do not allow bot approvals to satisfy required review.
- Do not allow bots to merge their own work.
- Require a human reviewer for changes to production code, infrastructure, authentication, billing, or security-sensitive paths.
Repository rules should enforce this mechanically. Relying on convention is not enough once multiple teams and bots are involved.
Manage memory and persistent instructions
Agent behavior is often controlled by files and configuration, not just the current conversation. Production users need to know where durable instructions live and how those instructions are reviewed.
For OpenClaw-style agents, persistent behavior lives in files such as SOUL.md, MEMORY.md, USER.md, and AGENTS.md. Instructions that only exist in chat may disappear when the session ends, the context window fills, or compaction runs.
Operationally, this means:
- Keep important instructions in durable files or policy configuration.
- Review persistent instructions during incident analysis.
- Remove stale instructions when workflows change.
- Treat memory files as part of the bot's configuration surface.
- Avoid storing secrets in memory files.
- Document which files are loaded into context by default.
When behavior drifts, inspect the files, policies, loaded context, credentials, and tool permissions before assuming the model has learned the wrong habit. Similarly, make sure to guide the bot to document its protocol and add asks to memory when executed correctly.
Create a bot inventory
Production agent programs need an inventory. The inventory does not need to be complicated, but it should be complete enough for security, IT, finance, and incident response.
Track at least:
- Bot name
- Bot owner
- Team
- Business purpose
- Runtime location
- Connected systems
- Credential storage location
- Internal data access level
- External communication channels
- Approval-gated actions
- Creation date
- Last review date
- Offboarding status
This inventory should be reviewed on a fixed cadence. A quarterly review is a reasonable starting point for most teams.
Connect agents to organization-level controls
For organization-wide deployment, agent management should connect to existing enterprise systems.
Important controls include:
- SSO/OIDC integration with the organization's identity provider
- SCIM or equivalent provisioning for user lifecycle management
- Centralized billing and usage visibility
- Usage analytics for model and task patterns
- Admin controls for models, permissions, and session duration
- Central inventory of active agents and owners
- Audit logs for sensitive actions
- A documented revocation path
The purpose of these controls is operational consistency. Security and platform teams need to know which agents are active, who owns them, what they can access, how much they cost, and how to revoke them.
Rollout plan
A production rollout does not require every policy to be final on day one. It does require narrow scope, explicit ownership, and a review loop.
A practical 90-day rollout:
- Inventory current usage. Ask teams what agents they already use, where they run, and what credentials they have. Be aware that some people will not volunteer their bot.
- Select approved initial workflows. Start with bounded tasks such as repository triage, log summarization, internal knowledge retrieval, test failure investigation, or pull request drafting.
- Assign bot owners. Every bot should have a named human owner and team.
- Create bot identities. Use company-managed accounts and naming conventions.
- Provision scoped access. Give each bot only the systems and permissions required for its workflow.
- Move secrets into approved storage. Use a managed vault before production workflows begin.
- Define approval requirements. Document which actions are allowed, blocked, or require human confirmation.
- Configure repository and communication boundaries. Enforce review rules and limit external channels.
- Monitor usage and incidents. Track task volume, cost, failures, permissions issues, and human override frequency.
- Review after 90 days. Expand approved patterns, remove unused access, and update policy based on actual usage.
This keeps adoption moving while preventing unmanaged expansion.
Operating guidance for teams
Running agents in production requires user education. Most failures are not caused by lack of enthusiasm; they are caused by unclear operating models.
Teams should understand:
- What context the agent has access to
- Where persistent instructions live
- How to update agent memory or policy files
- Which tools require approval
- Which systems the bot can access
- Which channels the bot may use
- How to report unexpected behavior
- How to disable or offboard a bot
It comes down to this: Teams need a working knowledge of how to use AI.
This is closer to system administration than people management. The organization is not managing trust in a person; it is managing state, permissions, context, and review loops.
FAQ
What controls should exist before broad production use?
At minimum: defined runtime boundaries, company-managed bot identities, scoped credentials, encrypted secret storage, approval gates for high-risk actions, repository rules for bot-authored code, central inventory, lifecycle management, and a process for audit and incident response.
Should bots be allowed to use external communication channels?
Only when the workflow requires it, and usually not on the same bot that has internal data access. A useful default is internal data access or external communication, not both. Exceptions should be documented and approved.
How should teams handle employee offboarding?
Bot accounts should be included in standard offboarding. Destroy or disable the runtime, revoke service accounts, remove tokens, rotate shared credentials if needed, and transfer or archive any required workspace data according to retention policy.
How much autonomy should a production agent have?
Start with autonomy for reversible, low-risk work and approval gates for high-risk work. Expand autonomy only after observing the workflow, reviewing failure modes, and confirming that revocation and audit paths work.
Who should own a production bot?
Every bot should have a named human owner and a responsible team. Ownership should include access review, credential rotation, incident response, cost monitoring, and offboarding.