ChatOps self-improvement loops are redefining agent identity risk

At a glance

What this is: This is an analysis of an autonomous AI agent that accepts voice commands through ChatOps and can modify its own capabilities, with the key finding that the improvement loop is the real product.

Why it matters: IAM, PAM, and NHI teams need to treat self-modifying agent workflows as a governance boundary issue, because the controls that manage static service identities do not fully cover runtime self-improvement.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read WorkOS's analysis of OpenClaw's self-improving ChatOps loop

Context

ChatOps self-improvement loops create a new governance problem because the actor is not just executing work, it is rewriting the workflow that governs its own work. In practice, that means the identity boundary is no longer limited to access tokens or API permissions. The programme has to account for an AI agent that can accept human intent, translate it into actions, and then extend its own capability set without a separate engineering cycle.

OpenClaw is described as running on dedicated hardware with private networking, Discord input, transcription, and code changes driven from voice messages. The useful signal for identity practitioners is not the hardware itself, but the control assumption it breaks: self-improving agents can move from request handling to capability creation in a single conversational loop. That is a materially different governance pattern from conventional automation, even when the starting point looks familiar.

Key questions

Q: How should security teams govern AI agents that can modify their own workflows?

A: Security teams should separate task execution from self-modification, so the agent can complete approved work without gaining unchecked authority over code, skills, or deployments. The governing principle is that a conversational request is not the same as a permission to rewrite the control plane. If the agent can change its own operating model, that change must be separately approved and logged.

Q: Why do self-improving AI agents create more risk than ordinary automation?

A: Self-improving agents can change the capabilities they rely on while they are still operating, which makes the security boundary dynamic instead of fixed. Ordinary automation follows a predefined path, but a self-modifying agent can extend that path by creating new tools or updating its own behaviour. That breaks assumptions in access reviews and change control.

Q: What breaks when an agent can create new skills from user feedback?

A: The main break is that governance records stop matching operational reality. A skill added during a work session may change what the agent can reach, how it behaves, and what future prompts can trigger. That means the identity programme is no longer reviewing a stable object, which makes recertification and entitlement tracking incomplete.

Q: What should teams do before allowing voice-driven ChatOps for AI agents?

A: Teams should require approval for commands that can change code, workflows, or deployment state, and they should log the full path from voice input to final action. Voice convenience should not lower the bar for privileged changes. If a spoken instruction can alter the agent's own capabilities, it belongs in a controlled change process.

Technical breakdown

Voice-to-action ChatOps and delegated execution

The core mechanism is a conversational pipeline: the user records a voice message, transcription converts speech to text, the agent interprets the prompt, and then it performs downstream actions such as filing tickets, editing code, or creating new capabilities. This is more than a chat interface. It is delegated execution with an identity boundary attached to the agent, not the human. The important distinction is that the human supplies intent, while the system decides how to operationalise that intent across tools and repositories. That creates a runtime authorisation problem, because the request itself becomes the trigger for action rather than a separately reviewed work item.

Practical implication: treat voice-driven agent commands as privileged execution requests and constrain the tool set, scopes, and repositories the agent can touch.

Self-improvement loops and recursive capability change

A self-improvement loop exists when the agent uses its own execution path to modify the very workflow it runs under. In the article, the agent can adjust a cron-based skill, build a search tool, and deploy changes after feedback. That means capability is not fixed at provisioning time. The agent can expand, refine, or reshape the working environment mid-flight. For IAM and governance teams, this introduces recursive access change: the identity is not only consuming permissions, it is participating in the creation of future permissions through code, skills, or integrations.

Practical implication: separate the permissions needed to execute tasks from the permissions needed to alter the agent's own operating model.

Autonomous execution timing and approval gates

This article describes an agent that acts when prompted, not on a predetermined schedule and not only inside a human approval loop. That is the key autonomy signal. Once the agent can decide when to process input, when to stage work, and when to change its own features, the governance model must account for runtime timing, not just entitlement assignment. Standard access review assumes a stable state long enough to observe and certify. A self-improving agent can change state between review points, which makes the approval cadence itself part of the control surface.

Practical implication: map which agent actions still require human approval before the agent can modify code, workflows, or downstream access.

Threat narrative

Attacker objective: The objective is to gain or abuse delegated agent execution so the system can perform and expand actions beyond the user's original intent.

1. Entry: a human sends a voice instruction through Discord, and the agent accepts the prompt as an execution trigger.
2. Escalation: the agent transcribes the message, interprets the request, and uses existing tool access to file tickets, edit code, or create new skills.
3. Impact: the agent changes its own behaviour and capabilities, compounding privilege and making future actions more powerful without a fresh engineering cycle.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Self-improvement loops turn agent identity into a moving target: The governance question is no longer whether the agent has access, but whether it can re-shape the access path while it is in use. That changes the identity problem from static permission assignment to runtime capability drift. For practitioners, the implication is that provisioning records alone cannot describe the security posture of a self-modifying agent.

Least privilege was designed for known tasks, not self-expanding behaviour: That assumption fails when the actor can decide to create new tools, add skills, or change its own execution path mid-session. The issue is not merely excess permission, but that the permission boundary was defined before the agent's intent existed. The implication is that identity governance has to reckon with intent that only becomes legible during execution.

ChatOps makes the delegation chain a control plane: A phone message becomes a command, the command becomes code or workflow changes, and the workflow changes alter what the agent can do next. This collapses the distance between user input and system reconfiguration. Practitioners should treat conversational interfaces as governance surfaces, not just usability features.

Autonomous self-upgrade exposes a named failure mode: runtime governance gap: The article shows that the system can alter itself faster than a normal review cycle can capture. That is a runtime governance gap, because the state being reviewed is not the state that existed when the decision was made. The implication is that access review, change control, and recertification all need to be rethought for agents that can modify themselves between checkpoints.

AI agent governance cannot borrow human lifecycle assumptions without distortion: A human moves through joiner, mover, and leaver stages at a pace that allows records, approvals, and offboarding to catch up. A self-improving agent can create, refine, and redeploy capabilities inside a single work loop. That makes the lifecycle problem continuous, not episodic, and practitioners should govern the agent as an active control participant rather than a passive account.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
• For a broader control model, see OWASP Agentic AI Top 10 for the agentic risks that emerge once tools, memory, and delegation intersect.

What this signals

Runtime governance gap: self-improving agents force identity teams to move beyond periodic review and toward continuous state validation. A system that can change its own skills between checkpoints will always outrun governance built around static entitlements, so the programme needs controls that observe change as it happens.

As agent workflows become conversational, practitioners should expect more delegated changes to originate from low-friction channels such as mobile voice and chat. That means the approval model has to follow the transaction, not the interface, and logging must preserve the full delegation chain from prompt to action.

With only 52% of companies able to track and audit what their AI agents access, the blind spot is already large enough to distort incident response and compliance evidence. The practical answer is to pair identity controls with runtime observability and to anchor agent governance in frameworks such as the NIST AI Risk Management Framework when autonomy starts to affect decisions.

For practitioners

• Separate execution rights from self-modification rights Give the agent only the tool access needed to complete user tasks, and place code editing, skill creation, and deployment behind explicit approval paths. The control failure in this pattern is not ordinary over-permissioning, but the ability to alter the operating model itself.
• Classify conversational commands as privileged requests Route voice-driven ChatOps inputs through the same review logic used for high-impact changes, especially when the agent can stage tickets, edit repos, or trigger deployments. Discord or phone-based prompts should not bypass the approval model just because they feel informal.
• Audit for recursive delegation paths Map where the agent can be both worker and author of its own next-step tooling, including new skills, scripts, and workflow integrations. The important control question is whether the agent can expand what it is allowed to do without a separate governance event.
• Bound the repositories and systems the agent can touch Restrict the agent to pre-approved repositories, environments, and data sources, and log every change to its skill set or prompt logic. This reduces the blast radius when a self-improvement loop goes wrong.
• Review agent lifecycle state continuously Treat the agent's permissions, skills, and deployment targets as live state that can drift between review cycles. Access recertification should verify not just current entitlements, but whether the agent has changed the shape of those entitlements since the last check.

Key takeaways

• Self-improving AI agents change their own control surface, which means access governance cannot stop at initial provisioning.
• The evidence gap is already material, with 48% of organisations unable to fully track and audit AI agent data access.
• Practitioners should separate routine execution from self-modification and treat conversational commands as privileged change requests.

Key terms

• Self-improvement loop: A self-improvement loop is a workflow in which an AI agent uses user feedback to change its own behaviour, tools, or capabilities. In identity terms, the actor is not only consuming access, it is helping create the next state of its own access environment, which complicates review and accountability.
• ChatOps: ChatOps is an operational pattern where chat or messaging becomes the interface for triggering work, changes, or approvals. For autonomous or semi-autonomous agents, it shifts the governance boundary into the conversation channel, making message provenance, intent, and logging part of the security model.
• Runtime governance gap: A runtime governance gap appears when the system state being governed changes faster than the review or approval process can capture it. For autonomous agents, this often means a capability, permission, or workflow can be altered inside the same session that created it, leaving governance behind the action.
• Self-modification rights: Self-modification rights are the permissions that allow an agent to alter its own code, skills, prompts, deployment, or workflow configuration. They are distinct from normal execution rights because they determine whether the identity can rewrite the rules that govern future actions.

Deepen your knowledge

AI agent lifecycle governance and runtime access control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for self-improving agents, this is a practical starting point.

This post draws on content published by WorkOS: OpenClaw and the best thing about using it. Read the original.