Agent-Ops 0.4.0 Released: Methodology for Secure Human-AI Collaboration in IT Operations

Sergey Zhitinsky, founder of Git in Sky, has published the public normative candidate for Agent-Ops 0.4.0, an open industry methodology governing how engineers and AI agents jointly handle IT infrastructure tasks. The framework keeps humans firmly in the decision-making loop while using deterministic programs for data collection and approved changes. It addresses risks such as prompt injection through processed data, unverified model outputs, and unclear accountability when AI recommendations lead to incidents. The methodology divides work across eight explicit steps and three separate planes: data, governance, and independent verification performed by a Guardian role. Two additional companies have joined as maintainers following agreements at the IT Elements 2026 conference, turning the project into a multi-organization effort. Contributors are invited to help refine contracts, schemas, and operational scenarios through GitHub and GitVerse.

HabrTranslated from Russian

Read at source

Agent-Ops 0.4.0 introduces a structured methodology for collaboration between engineers and AI agents in IT operations and support. The project, founded by Sergey Zhitinsky of Git in Sky, has released its first public normative candidate on GitHub and GitVerse. Two additional companies have become maintainers after agreements reached at the IT Elements 2026 conference, making the effort a joint industry initiative rather than a single-company project.

The methodology responds to growing use of AI agents for log analysis, configuration drift detection, root-cause investigation, and change preparation. It highlights the gap between an agent convincingly explaining a problem and the safe execution of its recommendation. Key concerns include whether the agent used current data, confused environments, verified hypotheses, or received malicious instructions through processed inputs. Responsibility for infrastructure changes must remain with humans—service owners, managers, and engineers—because accountability cannot be shifted to a model.

Agent-Ops enforces a clear separation of roles. A deterministic collector gathers facts within approved boundaries and records provenance, timestamps, and completeness. The agent correlates facts, generates testable hypotheses, and proposes a plan. An authorized human reviews and approves or rejects the specific plan. A separate deterministic executor then applies only the approved actions after re-checking permissions and conditions. The agent has no direct path from its output to live system changes.

The process consists of eight steps: Intention, Evidence, Diagnostics, Plan, Approval, Controlled Change, Verification, and Lessons Learned. Each step maintains distinct records so that any final change can be traced back to its supporting data, decision, and verification. The principle “unknown ≠ OK” requires that unverified facts remain marked as unknown rather than assumed correct.

Three independent planes—data, governance and policies, and independent verification—must each be satisfied separately. The Guardian role performs independent checks on data freshness, rule compliance, and authorization. These checks can be automated for deterministic conditions, while the agent may assist only with semantic consistency. Technical capability, autonomy, and potential impact are treated as separate properties that cannot be collapsed into a single trust level for the AI.

Version 0.4.0 is published as a candidate for community review. It includes a white paper in Russian and English, a glossary, a standards map, and machine-readable schemas. The project invites engineers, architects, support managers, and service owners to contribute via pull requests, issues, or new operational scenarios.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in AI Security

Logical Argument Claims Full Alignment of Superintelligent AGI Is Fundamentally Impossible
Claude Account Bans Linked to IP Reputation, Device Environment and Payment Channels, But No Confirmed Formula
Local LLMs in AppSec: What Open Tools and Models Can Handle in Application Security