Sekuire
Back to blog
Announcement

Introducing Open Agent Governance Specification

OAGS is an open, local-first standard for AI agent governance, covering deterministic identity, runtime policy enforcement, audit trails, and cryptographic verification. Sekuire keeps these primitives open while adding managed fleet coordination.

February 20, 2026•5 min read•By Joel Fickson Ngozo
Introducing OAGS: an open specification for AI agent identity, policy, enforcement, audit, and verification

AI agents are moving from prototypes to production systems, but governance standards have not kept pace.

Teams are increasingly shipping agents that can call tools, access files, reach external APIs, and trigger business workflows. Yet for many organizations, governance remains fragmented:

•identity and version changes are hard to verify

•policy controls are documented but inconsistently enforced

•audit trails are incomplete or hard to trust

•third-party verification is expensive and brittle

OAGS (Open Agent Governance Specification) was created to solve this gap with an open, implementation-agnostic governance model for autonomous AI agents.

Why OAGS exists

Most organizations do not need another framework. They need a standard way to answer practical questions in production:

•What is this agent, exactly?

•What constraints was it supposed to run under?

•Were those constraints enforced at runtime?

•Can we verify behavior independently?

OAGS defines common governance primitives so teams can answer those questions consistently, across runtimes and languages.

What OAGS is

OAGS is a local-first specification for governed AI agents. It defines interoperable building blocks for:

#Deterministic identity

#Declarative policy

#Runtime enforcement

#Structured audit evidence

#Cryptographic verification

The specification is designed so different implementations can produce compatible artifacts for governance, review, and verification.

Core primitives in detail

1) Deterministic identity

OAGS standardizes content-addressable identity so an agent can be identified reproducibly from canonical inputs.

At a high level, an implementation derives identity from normalized agent inputs (for example model + prompt + tools), then computes a deterministic hash. This gives teams a reproducible way to derive the same identity from the same canonical agent inputs.

Benefits:

•the same inputs produce the same identity

•small changes produce a new identity

•reviewers can reproduce identity results independently

2) Declarative policy

OAGS defines a portable policy model for runtime constraints, typically represented in sekuire.yml.

Policy domains include:

•tools (allow/deny controls)

•network (domains, TLS requirements)

•filesystem (allowed/blocked paths)

•models (model usage controls)

•APIs/services

•rate limits

This creates a single policy contract that can be reviewed, versioned, and validated before execution.

3) Runtime enforcement

OAGS is explicitly runtime-focused. Controls are intended to be evaluated while actions happen, not merely declared in docs.

A conforming runtime evaluates actions against policy and emits structured decisions such as:

•allow

•deny

•warn

This makes governance measurable and testable in actual execution paths.

4) Structured audit evidence

OAGS defines structured event patterns for recording governed actions and policy decisions.

The goal is to produce evidence that is:

•consistent across implementations

•machine-readable

•suitable for validation and review

This helps security, platform, and compliance stakeholders reason about what happened and why.

5) Cryptographic verification

OAGS supports cryptographic workflows (including signing and verification) to strengthen trust in reported governance artifacts.

With signed evidence, external reviewers can verify claims rather than depending on opaque assertions.

Design principles

OAGS is built around practical engineering constraints:

•Local-first: core primitives work without requiring hosted services

•Implementation-agnostic: works across languages and runtimes

•Deterministic: reproducible outputs from canonical inputs

•Runtime-enforceable: governance is evaluated where actions occur

•Verifiable: claims can be independently checked

•Incremental: teams can adopt in stages via conformance levels

Conformance levels

OAGS supports staged adoption through three conformance levels.

Level 1: Identity + Policy

Includes foundational governance artifacts:

•deterministic identity

•manifest + configuration shape

•policy declaration

•tool definition contracts

Level 1 is the fastest path to standardized governance metadata.

Level 2: Runtime Enforcement

Adds runtime policy decision behavior:

•action-level policy evaluation

•standardized enforcement outcomes

•consistent decision semantics during execution

Level 2 is where policy stops being purely declarative and becomes operational.

Level 3: Verifiable Audit Trail

Adds verifiable evidence capabilities:

•signed audit artifacts

•local verification support

•stronger third-party trust posture

Level 3 is targeted for environments that require high-confidence attestation and external verification.

How this works in practice

A typical implementation lifecycle looks like this:

#Define agent manifest and policy in sekuire.yml

#Normalize prompt/tool inputs and compute deterministic identity

#Execute agent runtime with policy checks at action boundaries

#Emit structured decision and audit records

#Run local verification and conformance checks

This lifecycle is intentionally compatible with local development and CI pipelines.

Example governance flow

Imagine an agent that attempts to call an external service and write to a local path:

#Runtime evaluates outbound domain against network policy

#Runtime evaluates file path against filesystem policy

#Enforcement emits decision events (allow/deny/warn)

#Audit artifacts capture decision metadata

#Verification tooling checks identity + policy + evidence consistency

This produces a clear governance chain for debugging, security review, and compliance workflows.

What teams can do in week one

If you are adopting OAGS for the first time, a practical first week plan is:

#Implement Level 1 for one production-adjacent agent

#Add Level 2 enforcement for high-risk actions (tooling/network)

#Add conformance checks to CI using shared vectors

#Define policy review checkpoints for governance changes

#Plan Level 3 for systems requiring signed evidence

This approach provides immediate governance gains without a full platform migration.

What is available now

The OAGS project includes open specification assets available today:

•canonical spec documentation

•quickstart path and examples

•profile schemas

•shared test vectors

•conformance harness documentation

Current implementation availability:

•TypeScript SDK: available

•CLI tooling: available

•Python SDK: coming soon

•Rust SDK: coming soon

Start here (direct links)

•Canonical specification (oags-v0.1.md): https://github.com/sekuire/oags/blob/main/specs/oags-v0.1.md

Closing

OAGS is designed to make AI agent governance portable, testable, and verifiable.

If your team is deploying agents in real workflows, OAGS gives you an open foundation to standardize identity, policy, runtime controls, and evidence without locking governance to one runtime.

Start with the quickstart, run conformance checks, and adopt level by level.