GovOps Working Group

The GovOps Working Group will develop a new scalable operational architecture for governing authorization risk across modern software systems, infrastructure, and endpoints. GovOps elevates “capability” as the primary unit of governance for measuring, managing, and reducing authorization risk. The group’s initial work will define a standard catalog of capabilities, new metrics to measure the direction of travel, and an architecture overview with implementation and governance guidance. By exposing capabilities, governors can deploy new tools to help prioritize mitigating the authorization risks with the biggest impacts, hold the right parties accountable, and foster organizational risk transparency. This work supports OWASP’s mission by advancing software security in an area that is becoming increasingly urgent: authorization governance. As AI agents and autonomous workloads expand, organizations need open, vendor-neutral methods to make access decisions visible, measurable, and accountable. GovOps will help OWASP provide leadership in securing the next generation of application, API, and agentic systems.

Proposal

The GovOps Working Group will develop an open, vendor-neutral framework for making authorization governance operational, measurable, and capability-oriented. GovOps addresses a critical gap in modern software security: organizations increasingly depend on applications, APIs, cloud services, workloads, and AI agents that exercise powerful capabilities, but they often lack a consistent way to govern those capabilities as operational risk. The purpose of the working group is to define the architecture, catalog format, and metrics needed to make authorization risk visible, measurable, accountable, and continuously governable. The GovOps Linkedin Group has 133 members.

GovOps has two defining characteristics. First, it makes governance more operational. Governance should provide security, engineering, audit, and business leaders with an operating model for understanding how risk is changing. The “Ops” in GovOps means governance should be connected to runtime systems, development workflows, policy enforcement, monitoring, and evidence collection. Second, GovOps makes governance capability-oriented. A capability is the concrete action that a principal, workload, service, or agent can perform on a resource, such as export:customer-data, approve:payment, deploy:production-service, invoke:agent-tool, or modify:tenant-policy. Capabilities provide a practical unit for measuring authorization risk because they connect software behavior to business impact.

The working group will treat metrics as a first-order deliverable. The DevOps movement was shaped by metrics that allowed organizations to measure software delivery performance, compare operating models, and understand whether engineering systems were improving. GovOps needs an equivalent measurement vocabulary for authorization governance. Static inventories are necessary but not sufficient. Governors need to understand not only what exists, but what is moving: which capabilities are growing in exposure, which high-risk capabilities are being exercised more frequently, where policy coverage is improving or degrading, how quickly risky access is detected, and whether accountability is keeping pace with changes in software, infrastructure, and agent behavior. The goal is to define a practical, vendor-neutral metric vocabulary that helps organizations move from episodic governance reviews to evidence-based operational governance.

The working group will produce three initial deliverables.

The first deliverable is the ACC.yaml, which stands for “Authorization Capability Catalog.” ACC.yaml will define a machine-readable format for inventorying capabilities across applications, APIs, services, workloads, and AI agents. It will include fields for capability identifier, action, resource, and possible other metadata useful for building dashboards to better understand risk, for example, the capability business unit, business function, risk tier, geographic location, data sensitivity, third-party exposure, and accountable owner. The catalog will be designed to support both human-readable governance and machine-readable integration with development, security, audit, and GRC workflows.

The second deliverable is a GovOps metric definition document. This document will define the initial set of GovOps metrics, including their purpose, data requirements, formulas or calculation guidance, suggested segmentation, examples, limitations, and governance interpretation. Metrics will be designed to help organizations answer operational questions such as: Which capabilities create the most risk? Which capabilities are expanding fastest? Which teams own the most critical capabilities? Which capabilities lack clear accountability? Which high-risk capabilities are exposed to third parties or autonomous actors? Which policies control each capability? Which controls are missing, stale, or unenforced? How quickly does the organization detect and respond to capability risk?

The third deliverable is a set of GovOps architecture documents. These document will describe how a capability catalog connects to real enterprise systems, including software delivery pipelines, API gateways, identity providers, policy decision points, policy enforcement points, service meshes, SIEM platforms, ITDR systems, asset inventories, GRC systems, and agent orchestration platforms. The architecture will be PDP-neutral. GovOps is not intended to require any particular policy engine, policy language, authorization graph, identity provider, or enforcement model. Organizations should be able to implement GovOps using their existing authorization infrastructure while gaining a consistent governance layer above it.

The working group will proceed in three phases. In Phase 1 the group will publish a draft ACC.yaml schema and collect feedback from application security teams, identity practitioners, authorization vendors, auditors, GRC professionals, cloud security teams, and AI governance practitioners. In Phase 2, the group will publish the metric definition document and example calculations. In Phase 3, the group will publish architecture documents that define core terminology and produce an initial GovOps reference model centered on capabilities, policies, controls, metrics, and accountability.

GovOps will also define clear boundaries. The working group is not intended to standardize a new policy decision point, policy language, enforcement protocol, identity system, or formal verification method. Formal verification, policy analysis, and mathematically analyzable authorization systems are highly complementary to GovOps, but they are not required for GovOps adoption. The purpose of GovOps is to create an operational governance layer that can work across many enforcement technologies and policy models.

This work directly supports OWASP’s mission to improve software security. Authorization failures remain one of the most persistent and damaging classes of application and API security risk. The rise of cloud-native systems, non-human identities, autonomous workloads, and AI agents increases the urgency of this problem because powerful capabilities can now be exercised at machine speed and across complex software supply chains. GovOps gives OWASP an opportunity to lead in a practical and emerging area of software security: making authorization risk measurable, governable, and accountable.

The intended impact of the GovOps Working Group is to help organizations move from static access inventories and periodic reviews toward continuous, evidence-based authorization governance. By defining ACC.yaml, a PDP-neutral architecture, and GovOps-specific moving metrics, the working group will give developers, security teams, auditors, and enterprise governors a shared language and practical operating model for governing what software, services, workloads, and agents are actually capable of doing.