Open Agent Governance Protocol (OAGP)

Draft v1.0

A standardized, interoperable framework for propagating governance context, communicating enforcement decisions, and facilitating remediation across heterogeneous AI agent systems.

Published: July 2026 · Status: Community Draft · Maintainer: AuthHub

1. Abstract

The Open Agent Governance Protocol (OAGP) defines a standardized, interoperable framework for propagating governance context, communicating enforcement decisions, and facilitating remediation across heterogeneous AI agent systems. It bridges the gap between human-approved intent (Mission-Bound Authorization) and runtime execution (Governed Execution), ensuring that AI agents can understand why they were restricted and how to resolve the restriction, even in cascaded agent-to-agent workflows.

2. Terminology

Decision OwnerThe human or automated entity authorized to approve or deny a governance exception.
Governance Context Token (GCT)A cryptographically signed token propagating mission, budget, and identity constraints across agent boundaries.
Policy Enforcement Point (PEP)The runtime component that intercepts requests and enforces governance decisions.
Remediation PayloadA standardized, machine-readable response provided when a request is governed/blocked, detailing the reason and resolution path.

3. Governance Context Token (GCT) Specification

Addresses Challenge A: Cascading Agent-to-Agent Delegation

When an AI agent (Agent A) invokes another agent or tool (Agent B), Agent A MUST propagate its governance constraints. This is achieved via the X-Governance-Context HTTP header or an equivalent gRPC metadata field, containing a Base64url-encoded, signed JWT.

3.1. JWT Claims Register

ClaimTypeDescriptionRequired
issstringIssuer (the calling AI Gateway or Orchestrator)YES
substringIdentity of the calling agentYES
audstringThe intended recipient agentYES
expnumberExpiration time (MUST be short-lived, ≤ 5 mins)YES
mission_idstringUnique identifier for the approved human workflowYES
cost_centre_idstringFinancial boundary governing this executionYES
max_severitystringMaximum allowed action severityNO
attestation_refsarrayActive approved attestation IDs covering this missionNO

3.2. Security Rules

  1. The PEP at Agent B MUST validate the GCT signature using the issuer's public keys (JWKS).
  2. The PEP MUST evaluate the intersection of Agent B's inherent permissions and the GCT's constraints. The strictest constraint wins.
  3. PII (e.g., patient names, specific dollar amounts) MUST NOT be included in the GCT. Only opaque identifiers are permitted.

4. Standardized Governance Enforcement Response

Addresses Challenge B: End-User & Agent Explainability

When a PEP blocks, throttles, or redirects a request due to governance signals, it MUST return an HTTP response utilizing an extension of RFC 7807 (Problem Details for HTTP APIs). This ensures both human users and AI agents can programmatically understand and react to the block.

4.1. JSON Schema: GovernanceProblemDetails

{
  "type": "https://authhub.cloud/governance/budget-exceeded",
  "title": "Governance Signal Enforcement",
  "status": 403,
  "detail": "Request blocked: cost centre 'cc-cardiology' has exceeded 100% of Q3 budget.",
  "instance": "/api/v1/agent/clinical-coder/invoke",
  "governance_action": "suspend",
  "signal_id": "sig-uuid-001",
  "trace_id": "trace-abc-123",
  "decision_owner": "dr.sarah.chen@nhs.net",
  "remediation": {
    "type": "attestation_required",
    "message_to_user": "Budget exceeded. Click below to request an override from your budget owner.",
    "attestation_url": "https://fga.authhub.cloud/api/v1/governance/attest/att-uuid?sig=hmac&exp=1722345678",
    "auto_retry_after_seconds": null
  }
}

4.2. Agent Behavior Rules

  • If governance_action is throttle, the AI agent SHOULD implement exponential backoff based on auto_retry_after_seconds.
  • If governance_action is require_attestation, the AI agent SHOULD present the message and attestation URL to the human, then enter a "pending" state.
  • If governance_action is suspend, the agent MUST terminate the workflow and notify the user, providing the trace_id for support.

5. Attestation Request Interoperability (CloudEvents Profile)

Governance systems MUST emit attestation requests using the CloudEvents v1.0 specification with the following profile:

{
  "specversion": "1.0",
  "type": "com.authhub.governance.attestation.requested.v1",
  "source": "https://fga.authhub.cloud",
  "id": "att-uuid-001",
  "time": "2026-07-31T14:00:00Z",
  "datacontenttype": "application/json",
  "data": {
    "attestation_id": "att-uuid-001",
    "signal_id": "sig-uuid-001",
    "decision_owner": "dr.sarah.chen@nhs.net",
    "affected_scope": "cost_centre:cc-cardiology",
    "enforcement_action": "suspend",
    "reason": "Q3 AI budget exceeded (105% of allocation)",
    "action_url": "https://fga.authhub.cloud/api/v1/governance/attest/att-uuid-001?sig=hmac&exp=...",
    "expires_at": "2026-08-07T14:00:00Z"
  }
}

Note: The action_url MUST be protected by an HMAC signature and MUST require the responder to authenticate via enterprise SSO before the approval is processed, preventing forwarded-link phishing.

6. Automated Compensation & State Reconciliation

Addresses Challenge C: Handling False Positives and Rapid Signal Flips

When a governance signal is rapidly superseded or resolved (e.g., a budget breach signal is retracted 10 seconds after issuance), the system MUST support automated compensation to restore user/agent workflow without manual break-glass intervention.

6.1. Compensation Event

The governance system MUST emit a com.authhub.governance.compensation.required.v1 CloudEvent when an enforcement is reverted within a configurable short window (e.g., < 60 seconds).

6.2. Idempotent Replay Mechanism

  1. Automatically clear any local "blocked" or "pending attestation" state associated with that trace.
  2. If the original request was a synchronous API call that was dropped, the gateway MAY automatically re-queue the request for immediate re-evaluation.
  3. Log the compensation event with the original trace_id for audit purposes.

7. Security & Privacy Considerations

  1. Token Minimization: The GCT MUST NOT contain sensitive payload data. It acts as a pointer. The PEP resolves actual policy details from its local cache or state store.
  2. Anti-Replay: All attestation URLs MUST include an expiration timestamp and an HMAC signature. The PEP MUST reject any response where the current time exceeds expiry by more than 5 minutes.
  3. Audit Immutability: All enforcement decisions, GCT validations, and attestation responses MUST be logged to an immutable audit store with the trace_id as the primary correlation key.

8. Implementation Example: The "Happy Path" Flow

  1. Human Approval: User approves a mission. System generates mission_id and records attestation.
  2. Agent Invocation: Orchestrator calls Agent A, passing X-Governance-Context: <GCT_JWT>.
  3. Cascaded Call: Agent A calls Agent B, forwarding the same governance context.
  4. Signal Interruption: FinOps system sends a critical budget breach signal for the cost centre in the GCT.
  5. Enforcement: Agent B's PEP intercepts the call, evaluates the GCT against the new enforcement state, and blocks the request.
  6. Explainable Response: Agent B returns HTTP 403 with the GovernanceProblemDetails JSON (RFC 7807).
  7. Agent Remediation: Agent A receives the 403, parses the remediation block, and updates the user UI: "Paused. Click here to approve the budget override."
  8. Resolution: User clicks link, passes SSO, approves. Attestation Dispatcher updates state.
  9. Compensation/Resume: PEP cache invalidates. Agent A automatically retries. Agent B's PEP now allows it.

Contribute to OAGP

This specification is a community draft. We welcome feedback, implementation reports, and proposed extensions.

Open Agent Governance Protocol (OAGP) · Draft v1.0 · July 2026

Published by AuthHub · fga.authhub.cloud