Skip to content
AIGP

RFC-010: AIGP Runtime Governance Protocol — 2. Core Principles

AIGP Specification › RFC-010: AIGP Runtime Governance Protocol › 2. Core Principles

← 1. Purpose · Section index · 3. Protocol Messages →

2. Core Principles

  1. Consent-Based Governance

    • Applications opt into governance by registering with the governance authority.
    • Governance is not imposed it is a contract.

  2. Pre-Invocation Check

    • Before every AI call, the application MUST check if the invocation is allowed.

  3. Post-Invocation Record

    • After every AI call, the application MUST record the invocation details.

  4. No Decision Is Never ALLOW

    • A decision exists only when the governance authority returns a 2xx response whose body is a JSON object carrying a valid decision (ALLOW, ALLOW_WITH_CONSTRAINTS, DENY, RATE_LIMITED).
    • A non-2xx, missing decision or unparseable response MUST be treated as DENY in ENFORCE and UNCHECKED in REPORT. An unreachable authority (transport error, timeout) is treated the same way.
    • In REPORT mode the application MAY proceed on UNCHECKED, but the client MUST NOT report or cache UNCHECKED as ALLOW. In ENFORCE mode the application MUST block.

  5. HMAC Authentication

    • All protocol messages are authenticated via HMAC-SHA256.

  6. Protocol-Agnostic, Policy-Specific

    • The AIGP protocol is cloud-agnostic and deployment-agnostic. The governance authority and governed applications can run on-premise, in AWS, Azure, GCP, or any combination.
    • Policies are where provider specificity lives. A policy MAY be generic (e.g., rate limit of 100 invocations/hour) or provider-specific (e.g., apply Bedrock Guardrail gr-abc123). Provider-specific policies carry a provider field; generic policies omit it.
    • The governance authority evaluates generic policies at the protocol layer and delegates provider-specific policies to the appropriate enforcement adapter.

← 1. Purpose · Section index · 3. Protocol Messages →