The Runtime Protocol
for AI Governance

1.Abstract

The Artificial Intelligence Runtime Governance Protocol (AIRGP) defines a wire-level protocol for runtime AI governance. AIRGP specifies how governance signals — including policies, guardrail verdicts, telemetry data, audit records, cost accounting events, and provenance attestations — flow between AI runtimes, control planes, policy engines, and audit ledgers.

AIRGP addresses a critical gap in the current AI governance landscape: while organizational frameworks (NIST AI RMF, ISO/IEC 42001) and regulations (EU AI Act) establish what governance outcomes are required, no existing standard defines how governance decisions are communicated, enforced, and recorded at the wire level during AI system execution.

The protocol specifies a JSON-based message format transported over HTTPS (REQUIRED) with optional gRPC support. All messages use the media type application/airgp+json. The protocol defines seven policy primitive types, a tamper-evident audit ledger using SHA-256 hash chains, Ed25519 message signatures, and three conformance levels (Basic, Enterprise, Sovereign).

2.Introduction & Motivation

2.1 The Runtime Governance Gap

Organizations deploying AI systems today face a fragmented landscape of vendor-specific governance implementations. A toxicity verdict from one vendor's guardrail system cannot be understood by another vendor's audit system. The result is governance silos: each AI deployment carries its own bespoke governance implementation, none of which interoperate, and none of which produce audit trails in a common format that regulators can inspect.

2.3 Design Principles

AIRGP is designed according to seven principles:

3.Relation to Prior Work

AIRGP is a consolidator protocol. It provides a unified wire format that allows existing approaches to interoperate.

4.Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHOULD, RECOMMENDED, and OPTIONAL are interpreted per BCP 14 [RFC 2119] [RFC 8174].

5.Conformance Levels

6.Architecture

AIRGP defines a four-layer architecture. Each layer has defined responsibilities, interfaces, and interoperability requirements.

+---------------------------------------------------------------------+
|                        Application Code                              |
+---------------------------------------------------------------------+
        |                                          ^
        | AI call (e.g., LLM inference)            | Governed response
        v                                          |
+---------------------------------------------------------------------+
|                  RUNTIME ADAPTER  (Layer 1)                          |
|  Intercepts AI calls · Attaches governance context · Enforces verdicts
+---------------------------------------------------------------------+
        |                ^                    |                ^
        | policy_eval    | verdict            | audit_record   | ack
        v                |                    v                |
+-------------------------------+   +-----------------------------+
|    CONTROL PLANE  (Layer 2)   |   |   AUDIT LEDGER  (Layer 4)   |
|  Routes signals               |   |  Hash-chained records       |
|  Distributes policies         |   |  Merkle tree anchoring      |
|  Fail-closed enforcement      |   |  Query interface            |
+-------------------------------+   +-----------------------------+
        |                ^
        | eval_request   | eval_result
        v                |
+-------------------------------+
|   POLICY ENGINE  (Layer 3)    |
|  Evaluates primitives         |
|  Produces verdicts            |
|  Manages policy lifecycle     |
+-------------------------------+

Layer 1 — Runtime Adapter

Interception point for all AI operations. Constructs governance context, sends policy evaluation requests to the Control Plane, and enforces verdicts (allow / deny / modify / escalate). On escalation timeout, MUST deny (fail-closed).

Layer 2 — Control Plane

Central hub. Routes signals between all layers. Distributes policy updates within 30 seconds. MUST return deny if no Policy Engine is reachable.

Layer 3 — Policy Engine

Evaluates Policy Primitives and returns verdicts. Stateless evaluation model — each request includes full governance context. Supports hot policy reload without service interruption.

Layer 4 — Audit Ledger

Append-only, hash-chained record store. Supports Merkle tree anchoring at Enterprise/Sovereign. Minimum retention: 365 days. Query interface at /.well-known/airgp/audit.

7.Wire Protocol

7.1 Transport

AIRGP uses HTTPS as the REQUIRED transport. gRPC is OPTIONAL. All endpoints MUST use TLS 1.2 or later. The service discovery endpoint is /.well-known/airgp.

7.2 Wire Message Envelope

{
  "airgp_version": "1.0",
  "message_id": "uuid-v7",
  "timestamp": "2026-05-01T12:00:00.000000000Z",
  "source": { "component": "runtime_adapter", "instance_id": "ra-prod-001" },
  "destination": { "component": "control_plane",  "instance_id": "cp-prod-001" },
  "signal_type": "policy_evaluation",
  "payload": { ... },
  "signature": "base64url-Ed25519-over-canonical-JSON",
  "prev_hash": "sha256:a1b2c3d4..."
}

The prev_hash for the first message in a chain MUST be sha256:0000...0000 (64 zeroes). This creates a tamper-evident hash chain per component.

7.3 Communication Patterns

Synchronous Request/Response — used for policy evaluation. Runtime Adapter blocks until verdict received. Default timeout: 5 seconds. On timeout: fail-closed (deny).

Asynchronous Fire-and-Forget — used for telemetry, cost events, and audit records. At-least-once delivery via persistent queues or write-ahead logs.

7.4 Error Codes

8.Policy Primitives

AIRGP v1.0 defines seven policy primitive types. All primitives share a common envelope and are evaluated by Policy Engines to produce verdicts.

{
  "primitive_type": "guardrail",
  "primitive_id": "grd-001",
  "config": {
    "guardrail_type": "toxicity",
    "direction": "output",
    "threshold": 0.7,
    "action_on_trigger": "deny",
    "categories": ["hate_speech", "harassment", "violence"]
  }
}

{
  "primitive_type": "routing_rule",
  "config": {
    "primary": { "provider": "anthropic", "model": "claude-sonnet-4-20250514" },
    "fallback_chain": [{ "provider": "openai", "model": "gpt-4o",
                         "condition": "primary_unavailable" }],
    "require_model_attestation": true
  }
}

{
  "primitive_type": "cost_cap",
  "config": {
    "cap_type": "tenant",
    "budget_amount": 10000.00,
    "budget_currency": "USD",
    "budget_period": "monthly",
    "soft_limit_percentage": 80,
    "action_on_soft_limit": "escalate",
    "action_on_hard_limit": "deny"
  }
}

{
  "primitive_type": "data_boundary",
  "config": {
    "boundary_type": "geographic",
    "allowed_regions": ["eu-west-1", "eu-central-1"],
    "denied_regions": ["us-*", "cn-*"],
    "pii_handling": "mask",
    "pii_categories": ["email", "phone", "national_id"],
    "cross_border_policy": "deny"
  }
}

{
  "primitive_type": "provenance_requirement",
  "config": {
    "require_model_attestation": true,
    "require_fine_tuning_history": true,
    "attestation_max_age_days": 90,
    "trusted_attestation_issuers": ["anthropic.com", "openai.com"]
  }
}

{
  "primitive_type": "rate_limit",
  "config": {
    "limit_scope": "user",
    "limits": [
      { "metric": "requests", "value": 100,    "window": "minute" },
      { "metric": "tokens",   "value": 100000, "window": "minute" }
    ],
    "action_on_limit": "deny",
    "burst_allowance_percentage": 20
  }
}

{
  "primitive_type": "compliance_mapping",
  "config": {
    "regulation": "eu_ai_act",
    "regulation_version": "2024/1689",
    "article": "14",
    "requirement_summary": "High-risk AI systems shall allow human oversight",
    "technical_controls": [{
      "control_type": "escalation",
      "trigger": "high_risk_classification",
      "action": "escalate",
      "escalation_target": "human_reviewer",
      "timeout_action": "deny"
    }],
    "evidence_requirements": ["escalation_count", "human_review_response_time"]
  }
}

9.Observability Signals

9.1 Required Telemetry Shape

Every Runtime Adapter MUST emit telemetry signals for each AI operation:

{
  "operation_id": "op-uuid-v7",
  "operation_type": "inference",
  "provider": "anthropic",
  "model": "claude-sonnet-4-20250514",
  "latency_ms": 1234,
  "input_tokens": 150,
  "output_tokens": 500,
  "verdict": "allow",
  "verdict_latency_ms": 12,
  "policies_evaluated": ["grd-001", "cc-001"],
  "tenant_id": "tenant-001",
  "application_id": "app-001",
  "status": "success"
}

9.2 OpenTelemetry Semantic Conventions

At Enterprise/Sovereign levels, implementations MUST export using OTel with AIRGP-specific span attributes:

Required spans per operation: airgp.governance (root) → airgp.policy_evaluation + airgp.ai_operation + airgp.audit_record.

10.Audit Ledger Format

The Audit Ledger is tamper-evident through three mechanisms: SHA-256 hash chaining, Ed25519 signatures, and Merkle tree anchoring.

{
  "record_id": "ar-uuid-v7",
  "record_type": "governance_decision",
  "timestamp": "2026-05-01T12:00:01.234567890Z",
  "operation_id": "op-uuid-v7",
  "sequence_number": 42,
  "governance_context": {
    "user_id": "pseudonymized-hash",
    "tenant_id": "tenant-001",
    "provider": "anthropic",
    "model": "claude-sonnet-4-20250514",
    "input_hash": "sha256:...",
    "output_hash": "sha256:..."
  },
  "aggregate_verdict": "allow",
  "prev_hash": "sha256:a1b2c3d4...",
  "record_hash": "sha256:e5f6a7b8...",
  "signature": "base64url-ed25519-signature"
}

To verify the audit chain, a verifier MUST: recompute record_hash, check it matches prev_hash of the next record, verify the Ed25519 signature, and confirm sequence numbers are contiguous. Any failure triggers an integrity alert.

At Enterprise/Sovereign, a Merkle tree is computed over batches of 1000 records (default, configurable) and its root published to an RFC 3161 TSA, public blockchain, or regulatory endpoint.

11.Identity & Attestation

Every AIRGP component MUST have a workload identity (component_type, instance_id). Implementations SHOULD use platform-native mechanisms (Kubernetes ServiceAccount, SPIFFE/SPIRE, cloud IAM).

11.4 Model Provenance Attestation

{
  "attestation_id": "att-uuid-v7",
  "attestation_type": "model_provenance",
  "subject": {
    "provider": "anthropic",
    "model": "claude-sonnet-4-20250514",
    "model_hash": "sha256:..."
  },
  "claims": {
    "training_data_cutoff": "2025-04-01",
    "safety_evaluations": [{
      "evaluation_name": "Responsible Scaling Policy",
      "result": "passed"
    }],
    "prohibited_use_cases": ["weapons_development", "surveillance"]
  },
  "issuer": { "issuer_id": "anthropic.com" },
  "issued_at": "2026-03-15T00:00:00Z",
  "expires_at": "2026-09-15T00:00:00Z",
  "signature": "base64url-ed25519"
}

11.5 Key Rotation

Components MUST support key rotation without service interruption. Old key remains active for 24 hours (configurable overlap). Every rotation is recorded as a system_event audit record. At Enterprise/Sovereign, root CA keys MUST be stored in an HSM.

12.Security Considerations

13.Privacy Considerations

AIRGP is a machine-to-machine protocol. Governance signals MUST NOT contain raw PII. The governance_context.user_id field MUST contain a pseudonymized identifier.

At Sovereign conformance, audit records MUST comply with applicable data protection regulations (GDPR, LGPD). Right-to-erasure requests MUST be supported with hash chain repair (verifiable "compaction" event). Telemetry MUST follow data minimization: no raw AI inputs or outputs — content hashes only.

AIRGP supports the right to explanation (GDPR Art. 22(3), EU AI Act Art. 86): the reason field in every verdict provides a machine-readable explanation. The full evaluation context in the audit record enables post-hoc regulatory inspection.

14.IANA Considerations

This specification requests the following registrations with IANA:

15.References

Normative

Informative