Measure risk, transparency,
and accountability
GovOps is an open, vendor-neutral architecture for authorization governance. Govern capabilities centrally, authorize locally next to the resource, and join the two with a stable capability_id that travels from the catalog to the kernel.
Govern → Authorize → Execute → Observe → Detect → Respond
Why GovOps
Risk measures posture. Transparency reveals process. Accountability validates execution.
Manage risk proactively
A finite, enumerable catalog of capabilities carries risk tier and business impact, so remediation queues can be ranked by likely failure against real consequence rather than treated as an undifferentiated checklist.
Gain full transparency
Authorization decisions, application telemetry, and kernel observability all carry the same capability_id. Runtime activity can be read in business terms, not only technical ones.
Drive accountability
Every capability has an accountable owner and the policy versions that governed it. When something goes wrong, there is a name to call and a record of what the rules were at the time.
A new era of governance
Authority no longer flows through people
Traditional governance was built for a world where humans were the primary actors. Today authority flows through workloads, agents, service accounts, pipelines, and distributed microservices, executing high-impact actions at machine speed.
Manual reviews and periodic audits cannot keep pace. GovOps replaces them with declarative policy, explicit trust definitions, governed schemas, and continuous compliance checks that produce evidence as a by-product of running the system.
Governance artifacts stay centralized. Authorization decisions stay local, close to the application, database, device, or agent they protect.
What does it mean to govern?- Workloads
- AI agents
- Service accounts
- Pipelines
- Microservices
GovOps control planes
Four layers, one join key
Effective authorization governance depends on governance, identity, visibility, and event handling. Each answers a different question, and capability_id is what connects the answers.
Governance plane
The shared artifacts used to control authorization: the capability catalog, policy, schema, federation, and compliance mappings.
Identity plane
Identifiers and trusted evidence about the humans, workloads, organizations, devices, and agents taking part in a decision.
Visibility plane
Evidence about what actually happened: decision logs, application telemetry, and kernel observability joined by capability_id.
Event plane
What the enterprise does when a condition needs action: revoke, quarantine, re-authorize, notify the owner, open an incident.
- 1
Define and classify
Register every governed capability with a stable capability_id, an accountable owner, a risk tier, and a business impact.
- 2
Authorize locally, govern centrally
Policy Decision Points evaluate next to the resource. Policy, schema, and federation stay centrally versioned, reviewed, and audited.
- 3
Observe, detect, respond
Runtime evidence returns along the same capability_id, so a kernel-level event connects back to an owner, a policy, and a control.
The outcome
Governance that is
Continuous
Always-on assurance instead of periodic review.
Provable
Evidence produced by the running system, not assembled at audit time.
Operational
Integrated into daily workflows and real-time systems.
Aligned
Matched to the velocity and complexity of modern infrastructure.
GovOps brings the speed, automation, and rigor of modern Ops disciplines into governance, so organizations can defend themselves in the operational plane where threats actually occur.
How does it work?
Shared services between business governance and distributed enforcement
Capability catalog
A machine-readable inventory of what applications, APIs, workloads, and agents can actually do — with owner, risk tier, and business impact attached.
Policy and schema management
Centralized administration of the rules and of the entities, attributes, and claims those rules reference. Enforcement stays distributed.
Federation management
Which issuers, credentials, algorithms, and claims the enterprise is willing to trust — an explicit governance decision, not an implicit one.
Continuous compliance
Capabilities map once to a canonical control layer, then project through OSCAL and Trestle into NIST, ISO 27001, SOC 2, or an internal framework.
Working group deliverables
Everything is public, in the open, and editable
GovOps is developed as an OWASP working group proposal. Every document below lives in the repository as Markdown; the site renders it directly.
Authorization Capability Catalog
The catalog model, the Authorization Capability Profile over Gemara, and the export path to OSCAL and Trestle — with four worked persona use cases.
Read it →Draft for sub-group commentGovernance metrics
What counts as a GovOps metric, the admissions rule that a metric must report a change rather than a level, and the first published entry.
Read it →DraftArchitecture
The GovOps loop, the Governance and Runtime planes, the nine GovOps services, and the runtime authorization context that joins a decision to what executed.
Read it →Start governing at machine speed
Your infrastructure already operates in real time. Your governance should too. Read the architecture, then bring a capability from your own estate to the working group.