RFC-010: Autonomous Intelligence Governance Protocol (AIGP) — 15. Agentic Governance Extension

AIGP Specification › RFC-010: Autonomous Intelligence Governance Protocol (AIGP) › 15. Agentic Governance Extension

← 14. Summary · Section index · 16. Post-Hoc Evaluation Loop (RFC-032) →

15. Agentic Governance Extension

This section extends AIGP to govern autonomous AI agents operating in multi-step execution loops, delegation chains, and inter-agent communication patterns. The extension introduces new identity primitives, governance artifacts, and protocol messages that layer on top of the existing AIGP infrastructure without modifying the behavior of non-agentic applications.

15.1 Design Principles

Default-Deny Agency — Agents have zero capabilities until explicitly granted via a Scope Envelope
Governance at the Wall, Not the Brain — Policy enforcement is deterministic and independent of agent reasoning; the agent cannot reason its way past governance
Scope Narrowing Only — Delegation can only reduce scope, never expand it
Protocol Continuity — New messages use the same HMAC authentication, same transport, same versioning scheme
Incremental Adoption — Applications can adopt agentic governance features incrementally; non-agentic apps are unaffected

15.2 Protocol Version Strategy

Existing messages retain "protocol_version": "2.0"
New agentic messages use "protocol_version": "2.0"
The Governance Authority detects version and routes accordingly
Applications declaring "agent_capable": true in REGISTER unlock agentic endpoints
All agentic endpoints live under /api/v1/agent/

15.3 Agent Identity Model

Each agent within a governed application receives a distinct cryptographic identity, separate from the application identity (app_id). This enables per-agent governance, delegation tracking, and independent key rotation.

15.3.1 Identity Structure

{
  "agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "agent_type": "EXECUTOR",
  "key_id": "kid-a1b2c3d4",
  "public_key": "-----BEGIN PUBLIC KEY-----\n...",
  "parent_agent_id": null,
  "delegation_depth": 0,
  "registered_at": "2026-06-01T00:00:00Z",
  "scope_envelope_id": "scope-env-001"
}

15.3.2 Identity Fields

Field	Type	Required	Description
`agent_id`	string	YES	Unique identifier for the agent within the governance authority
`app_id`	string	YES	Parent application identifier (links to existing AIGP registration)
`agent_type`	enum	YES	One of: `ORCHESTRATOR`, `EXECUTOR`, `ANALYST`, `DELEGATOR`
`key_id`	string	YES	Key version identifier for rotation support
`public_key`	string	YES	PEM-encoded public key for proof-of-possession
`parent_agent_id`	string	NO	Identifier of the agent that spawned this agent (null for root agents)
`delegation_depth`	integer	YES	Current depth in the delegation chain (0 for root agents)
`registered_at`	ISO 8601	YES	Timestamp of agent registration
`scope_envelope_id`	string	YES	Reference to the agent’s active Scope Envelope

15.3.3 Agent Types

Type	Description	Typical Autonomy
`ORCHESTRATOR`	Coordinates other agents, does not directly invoke tools	ACT_WITH_APPROVAL
`EXECUTOR`	Performs actions via tools	ACT_WITH_APPROVAL
`ANALYST`	Read-only reasoning, no side effects	ACT_AUTONOMOUS
`DELEGATOR`	Spawns and manages sub-agents	ACT_WITH_APPROVAL

15.4 Extended REGISTER Message

Applications declaring agent capabilities include an agent_capable flag and an agents array in their REGISTER message. This extends the existing REGISTER message (Section 3.1) without modifying its base schema.

{
  "protocol_version": "2.0",
  "message_type": "REGISTER",
  "app_id": "APP_PRJ",
  "mode": "ENFORCE",
  "agent_capable": true,
  "agents": [
    {
      "agent_id": "agent-gandalf-spell-executor-001",
      "agent_type": "EXECUTOR",
      "public_key": "-----BEGIN PUBLIC KEY-----\n...",
      "declared_tools": ["iam_create_user", "iam_add_to_group", "iam_remove_user"],
      "declared_models": ["us.anthropic.claude-opus-4-7"],
      "max_delegation_depth": 2
    }
  ],
  "use_cases": [
    {
      "id": "gandalf_magic",
      "model_id": "us.anthropic.claude-opus-4-7",
      "description": "Gandalf spell composition"
    }
  ]
}

15.4.1 Agent Registration Fields

Field	Type	Required	Description
`agent_capable`	boolean	YES	Signals the application supports agentic governance
`agents`	array	YES	List of agent declarations
`agents[].agent_id`	string	YES	Unique agent identifier
`agents[].agent_type`	enum	YES	Agent type classification
`agents[].public_key`	string	YES	PEM-encoded public key for proof-of-possession
`agents[].declared_tools`	array[string]	YES	Tools the agent intends to use
`agents[].declared_models`	array[string]	YES	Models the agent intends to invoke
`agents[].max_delegation_depth`	integer	YES	Maximum delegation chain depth this agent may create

If an application does not include agent_capable: true in its REGISTER message, the Governance Authority treats it as a non-agentic application and applies only base protocol governance (Sections 3–14).

15.5 Scope Envelope

The Scope Envelope is the central governance artifact for agents. It defines the complete boundary of what an agent may do. Any capability not explicitly listed in the envelope is denied (default-deny).

15.5.1 Schema

{
  "scope_envelope_id": "scope-env-001",
  "agent_id": "agent-gandalf-spell-executor-001",
  "version": 1,
  "issued_at": "2026-06-01T00:00:00Z",
  "expires_at": "2026-06-01T01:00:00Z",
  "permissions": {
    "tools": {
      "mode": "allowlist",
      "allowed": ["iam_create_user", "iam_add_to_group"],
      "denied": []
    },
    "models": {
      "mode": "allowlist",
      "allowed": ["us.anthropic.claude-opus-4-7"]
    },
    "data_sources": {
      "mode": "allowlist",
      "allowed": ["kb-prod-001", "kb-policies-002"]
    },
    "agents": {
      "may_delegate_to": ["agent-validator-001"],
      "may_receive_from": ["agent-orchestrator-001"]
    }
  },
  "budgets": {
    "max_actions": 50,
    "max_tokens": 100000,
    "max_cost_usd": 5.00,
    "max_ttl_seconds": 3600
  },
  "autonomy_level": "ACT_WITH_APPROVAL",
  "approval_gates": [
    {
      "action_pattern": "iam_remove_*",
      "requires": "HUMAN_APPROVAL",
      "timeout_seconds": 300,
      "timeout_action": "DENY"
    }
  ],
  "memory_scope": {
    "may_write": true,
    "max_retention_seconds": 86400,
    "allowed_classifications": ["LOW", "MEDIUM"],
    "isolation": "AGENT_PRIVATE"
  }
}

15.5.2 Scope Envelope Fields

Field	Type	Required	Description
`scope_envelope_id`	string	YES	Unique identifier for this envelope
`agent_id`	string	YES	Agent this envelope is assigned to
`version`	integer	YES	Monotonically increasing version number
`issued_at`	ISO 8601	YES	When the envelope was issued
`expires_at`	ISO 8601	YES	When the envelope expires (mandatory TTL)
`permissions.tools`	object	YES	Tool access control (mode, allowed, denied)
`permissions.models`	object	YES	Model access control
`permissions.data_sources`	object	YES	Knowledge base and data source access
`permissions.agents`	object	YES	Inter-agent communication permissions
`budgets.max_actions`	integer	YES	Maximum autonomous actions in this session
`budgets.max_tokens`	integer	YES	Maximum token consumption
`budgets.max_cost_usd`	number	YES	Maximum cost in USD
`budgets.max_ttl_seconds`	integer	YES	Maximum time-to-live in seconds
`autonomy_level`	enum	YES	One of: `OBSERVE`, `SUGGEST`, `ACT_WITH_APPROVAL`, `ACT_AUTONOMOUS`
`approval_gates`	array	NO	Actions requiring explicit approval
`memory_scope`	object	YES	Memory governance boundaries

15.5.3 Autonomy Levels

Level	Behavior	Use Case
`OBSERVE`	Agent may reason but not act; all actions logged only	Shadow mode, new agent onboarding
`SUGGEST`	Agent proposes actions; human must approve each one	High-risk environments
`ACT_WITH_APPROVAL`	Agent acts on pre-approved plan; escalates for unplanned actions	Standard production
`ACT_AUTONOMOUS`	Agent acts freely within scope envelope; escalates only at budget limits	Low-risk, read-only tasks

15.5.4 Scope Narrowing Rule

When Agent A delegates to Agent B, the Governance Authority computes:

B.scope = A.scope ∩ delegation_request.scope

The intersection ensures B can never exceed A’s permissions. The Governance Authority rejects any delegation where the requested scope is not a strict subset of the delegator’s scope.

15.6 TOOL_REQUEST Message

Sent before every tool invocation by an agent. This is the governance “wall” between agent reasoning and action execution. The Governance Authority evaluates the request against the agent’s Scope Envelope and returns a decision.

15.6.1 Request

POST /api/v1/agent/tool-request
Headers:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}
  Content-Type: application/json

Body:
{
  "protocol_version": "2.0",
  "message_type": "TOOL_REQUEST",
  "agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "request_id": "treq-1714500000001",
  "scope_envelope_id": "scope-env-001",
  "tool_id": "iam_create_user",
  "tool_version": "1.2.0",
  "tool_manifest_hash": "sha256:a1b2c3...",
  "input_parameters_hash": "sha256:d4e5f6...",
  "execution_context": {
    "delegation_chain": ["agent-orchestrator-001", "agent-gandalf-spell-executor-001"],
    "step_number": 3,
    "plan_id": "plan-abc123"
  }
}

15.6.2 TOOL_REQUEST Fields

Field	Type	Required	Description
`protocol_version`	string	YES	Must be `"1.1"` for agentic messages
`message_type`	string	YES	Must be `"TOOL_REQUEST"`
`agent_id`	string	YES	Requesting agent’s identity
`app_id`	string	YES	Parent application identity
`request_id`	string	YES	Unique request identifier for correlation
`scope_envelope_id`	string	YES	Reference to the agent’s active scope envelope
`tool_id`	string	YES	Identifier of the tool to invoke
`tool_version`	string	YES	Version of the tool
`tool_manifest_hash`	string	YES	SHA-256 hash of the tool’s manifest entry for integrity verification
`input_parameters_hash`	string	YES	SHA-256 hash of the tool’s input parameters (parameters not sent in cleartext)
`execution_context`	object	NO	Contextual information about the current execution
`execution_context.delegation_chain`	array[string]	NO	Ordered list of agent IDs in the delegation chain
`execution_context.step_number`	integer	NO	Current step within an approved execution plan
`execution_context.plan_id`	string	NO	Reference to the approved execution plan

15.6.3 Response

{
  "decision": "ALLOW",
  "request_id": "treq-1714500000001",
  "constraints": {
    "timeout_ms": 5000,
    "output_max_bytes": 10240
  },
  "budget_remaining": {
    "actions": 47,
    "tokens": 95000,
    "cost_usd": 4.85
  }
}

15.6.4 TOOL_REQUEST Response Fields

Field	Type	Required	Description
`decision`	enum	YES	One of: `ALLOW`, `ALLOW_WITH_CONSTRAINTS`, `DENY`
`request_id`	string	YES	Echoed request identifier for correlation
`constraints`	object	NO	Applied constraints when decision is `ALLOW_WITH_CONSTRAINTS`
`constraints.timeout_ms`	integer	NO	Maximum execution time for the tool
`constraints.output_max_bytes`	integer	NO	Maximum output size
`budget_remaining`	object	YES	Current autonomy budget status
`budget_remaining.actions`	integer	YES	Remaining actions in budget
`budget_remaining.tokens`	integer	YES	Remaining tokens in budget
`budget_remaining.cost_usd`	number	YES	Remaining cost budget in USD
`reason`	string	NO	Human-readable reason (present when decision is `DENY`)

15.6.5 Decision Values

Decision	Meaning
`ALLOW`	Proceed with tool invocation
`ALLOW_WITH_CONSTRAINTS`	Proceed but apply constraints (timeout, output limits, parameter filtering)
`DENY`	Do not invoke — policy violation, budget exhausted, or scope exceeded

15.6.6 Governance Evaluation

The Governance Authority evaluates a TOOL_REQUEST by checking, in order:

Circuit Breaker — Is the agent’s circuit breaker OPEN? If yes, return DENY with CIRCUIT_OPEN reason.
Scope Envelope — Is tool_id in the agent’s permissions.tools.allowed list? If not, DENY.
Tool Manifest — Does tool_manifest_hash match the registered manifest entry? If not, DENY with supply chain violation.
Autonomy Budget — Does the agent have remaining actions/tokens/cost? If exhausted, DENY.
Approval Gates — Does tool_id match an approval_gates[].action_pattern? If yes, require approval.
Delegation Chain — Is the delegation depth within limits? Validate chain integrity.

If all checks pass, the Governance Authority returns ALLOW (or ALLOW_WITH_CONSTRAINTS if policy requires constraints) and decrements the autonomy budget.

15.6.7 Fail-Closed Behavior

If the Governance Authority is unreachable in ENFORCE mode, the agent MUST block the tool invocation. In REPORT mode, the agent MAY proceed and log the ungoverned invocation for later audit.

15.7 Authentication

All agentic protocol messages are authenticated using the existing HMAC-SHA256 mechanism (Section 4) with the addition of the X-AIGP-Agent-Id header. The signature computation includes the agent identity:

Headers required for all agentic endpoints:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}

The HMAC secret is derived from the application’s registered secret. Agent key pairs (key_id + public_key) provide an additional layer of proof-of-possession for agent-specific operations.

15.8 PLAN_SUBMIT Message

Sent when an agent formulates a multi-step execution plan. The Governance Authority evaluates the plan against the agent’s Scope Envelope, configured Approval Gates, and autonomy budget before any steps are executed. This enables governance to approve, modify, or reject entire workflows before irreversible actions occur.

15.8.1 Request

POST /api/v1/agent/plan-submit
Headers:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}
  Content-Type: application/json

Body:
{
  "protocol_version": "2.0",
  "message_type": "PLAN_SUBMIT",
  "agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "plan_id": "plan-abc123",
  "scope_envelope_id": "scope-env-001",
  "steps": [
    {
      "step_number": 1,
      "action": "tool_invoke",
      "tool_id": "iam_create_user",
      "description": "Create IAM user for new employee",
      "estimated_tokens": 500,
      "reversible": true
    },
    {
      "step_number": 2,
      "action": "tool_invoke",
      "tool_id": "iam_add_to_group",
      "description": "Add user to engineering group",
      "estimated_tokens": 300,
      "reversible": true
    },
    {
      "step_number": 3,
      "action": "model_invoke",
      "model_id": "us.anthropic.claude-opus-4-7",
      "description": "Generate welcome message",
      "estimated_tokens": 2000,
      "reversible": false
    }
  ],
  "estimated_total_tokens": 2800,
  "estimated_total_cost_usd": 0.12
}

15.8.2 PLAN_SUBMIT Fields

Field	Type	Required	Description
`protocol_version`	string	YES	Must be `"1.1"` for agentic messages
`message_type`	string	YES	Must be `"PLAN_SUBMIT"`
`agent_id`	string	YES	Submitting agent’s identity
`app_id`	string	YES	Parent application identity
`plan_id`	string	YES	Unique identifier for this execution plan
`scope_envelope_id`	string	YES	Reference to the agent’s active scope envelope
`steps`	array	YES	Ordered list of planned execution steps
`estimated_total_tokens`	integer	YES	Estimated total token consumption across all steps
`estimated_total_cost_usd`	number	YES	Estimated total cost in USD across all steps

15.8.3 Steps Array Item Fields

Field	Type	Required	Description
`step_number`	integer	YES	Ordinal position of the step in the plan (1-indexed)
`action`	enum	YES	One of: `tool_invoke`, `model_invoke`, `delegate`, `memory_write`
`tool_id`	string	CONDITIONAL	Tool identifier (required when action is `tool_invoke`)
`model_id`	string	CONDITIONAL	Model identifier (required when action is `model_invoke`)
`description`	string	YES	Human-readable description of the step’s purpose
`estimated_tokens`	integer	YES	Estimated token consumption for this step
`reversible`	boolean	YES	Whether this step can be undone if the plan is halted mid-execution

15.8.4 Response

{
  "decision": "APPROVED_WITH_MODIFICATIONS",
  "plan_id": "plan-abc123",
  "modifications": [
    {
      "step_number": 1,
      "gate": "HUMAN_APPROVAL",
      "reason": "iam_create_user requires human approval per policy"
    }
  ],
  "approval_expires_at": "2026-06-01T01:00:00Z"
}

15.8.5 PLAN_SUBMIT Response Fields

Field	Type	Required	Description
`decision`	enum	YES	One of: `APPROVED`, `APPROVED_WITH_MODIFICATIONS`, `REJECTED`
`plan_id`	string	YES	Echoed plan identifier for correlation
`modifications`	array	NO	List of modifications applied to the plan (present when decision is `APPROVED_WITH_MODIFICATIONS`)
`modifications[].step_number`	integer	YES	Step number that was modified
`modifications[].gate`	string	YES	Type of gate applied (e.g., `HUMAN_APPROVAL`)
`modifications[].reason`	string	YES	Human-readable reason for the modification
`approval_expires_at`	ISO 8601	YES	Timestamp after which the plan approval is no longer valid
`reason`	string	NO	Human-readable reason (present when decision is `REJECTED`)

15.8.6 Decision Values

Decision	Meaning
`APPROVED`	All steps are authorized; agent may proceed with execution
`APPROVED_WITH_MODIFICATIONS`	Plan is authorized with additional gates or constraints on specific steps
`REJECTED`	Plan is denied; agent must not execute any steps

15.8.7 Governance Evaluation

The Governance Authority evaluates a PLAN_SUBMIT by checking:

Scope Envelope — Are all tool_id and model_id values in the agent’s permitted lists? If any are not, REJECT.
Autonomy Budget — Does the estimated_total_tokens and estimated_total_cost_usd fit within the agent’s remaining budget? If not, REJECT.
Approval Gates — Do any steps match configured approval_gates[].action_pattern? If yes, add HUMAN_APPROVAL gates to those steps.
Reversibility Assessment — Are irreversible steps (where reversible: false) within the agent’s autonomy tier? If the agent is ACT_WITH_APPROVAL, irreversible steps require explicit approval.
Delegation Chain — If any step is a delegate action, validate the target agent and scope narrowing rules.

If all checks pass, the Governance Authority returns APPROVED (or APPROVED_WITH_MODIFICATIONS if gates are required) and records the plan for progress tracking.

15.9 ESCALATE Message

Sent when an agent requires human-in-the-loop approval for an action that exceeds its autonomy tier, or when its autonomy budget approaches or reaches a configured threshold. The Governance Authority routes the escalation to the designated human reviewer and blocks the agent until a decision is received or the timeout expires.

15.9.1 Request

POST /api/v1/agent/escalate
Headers:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}
  Content-Type: application/json

Body:
{
  "protocol_version": "2.0",
  "message_type": "ESCALATE",
  "agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "escalation_id": "esc-001",
  "reason": "ACTION_REQUIRES_APPROVAL",
  "action": {
    "tool_id": "iam_remove_user",
    "description": "Remove user john.doe from IAM",
    "risk_level": "HIGH"
  },
  "context": {
    "plan_id": "plan-abc123",
    "step_number": 4,
    "actions_taken": 3,
    "budget_remaining": {
      "actions": 12,
      "tokens": 45000
    }
  },
  "timeout_seconds": 300,
  "timeout_action": "DENY"
}

15.9.2 ESCALATE Fields

Field	Type	Required	Description
`protocol_version`	string	YES	Must be `"1.1"` for agentic messages
`message_type`	string	YES	Must be `"ESCALATE"`
`agent_id`	string	YES	Escalating agent’s identity
`app_id`	string	YES	Parent application identity
`escalation_id`	string	YES	Unique identifier for this escalation request
`reason`	enum	YES	Reason for escalation (see Section 15.9.3)
`action`	object	YES	Description of the action requiring approval
`action.tool_id`	string	NO	Tool identifier (if escalation is for a tool invocation)
`action.description`	string	YES	Human-readable description of the action
`action.risk_level`	enum	NO	Risk classification: `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`
`context`	object	YES	Current execution context for the human reviewer
`context.plan_id`	string	NO	Reference to the active execution plan
`context.step_number`	integer	NO	Current step within the plan
`context.actions_taken`	integer	YES	Number of actions already executed in this session
`context.budget_remaining`	object	YES	Current budget status
`timeout_seconds`	integer	YES	Maximum time to wait for human response
`timeout_action`	enum	YES	Action to take on timeout: `DENY`, `ALLOW_ONCE`, `REDUCE_AUTONOMY`

15.9.3 Reason Values

Reason	Description
`ACTION_REQUIRES_APPROVAL`	The action matches an approval gate in the agent’s Scope Envelope
`BUDGET_WARNING`	The agent’s autonomy budget has reached the configured warning threshold
`BUDGET_EXHAUSTED`	The agent’s autonomy budget is fully depleted
`ANOMALY_DETECTED`	The Governance Authority detected anomalous behavior patterns
`SCOPE_EXCEEDED`	The agent attempted an action outside its Scope Envelope

15.9.4 Response

{
  "escalation_id": "esc-001",
  "decision": "APPROVED",
  "approved_by": "admin@example.com",
  "approved_at": "2026-06-01T00:15:30Z",
  "constraints": {
    "one_time_only": true
  }
}

15.9.5 ESCALATE Response Fields

Field	Type	Required	Description
`escalation_id`	string	YES	Echoed escalation identifier for correlation
`decision`	enum	YES	One of: `APPROVED`, `DENIED`, `TIMEOUT`
`approved_by`	string	NO	Identity of the human who approved (present when decision is `APPROVED`)
`approved_at`	ISO 8601	NO	Timestamp of approval (present when decision is `APPROVED`)
`constraints`	object	NO	Additional constraints applied to the approval
`constraints.one_time_only`	boolean	NO	If true, approval is valid for this single action only
`reason`	string	NO	Human-readable reason (present when decision is `DENIED`)

15.9.6 Decision Values

Decision	Meaning
`APPROVED`	Human reviewer approved the action; agent may proceed
`DENIED`	Human reviewer denied the action; agent must not proceed
`TIMEOUT`	No human response within `timeout_seconds`; apply `timeout_action`

15.9.7 Timeout Behavior

When the configured timeout_seconds elapses without a human decision, the Governance Authority applies the timeout_action specified in the request:

DENY — The escalated action is denied. The agent must find an alternative approach or halt execution. This is the recommended default for high-risk actions.
ALLOW_ONCE — The escalated action is permitted for this single invocation only. Use only for low-risk actions where blocking would cause unacceptable delays.
REDUCE_AUTONOMY — The agent’s autonomy level is reduced by one tier (e.g., from ACT_WITH_APPROVAL to SUGGEST). All subsequent actions require explicit approval until a human restores the original tier.

The Governance Authority records the timeout event in the audit trail regardless of the timeout action applied.

15.10 DELEGATE Message

Sent when an agent delegates work to a sub-agent. The Governance Authority validates the delegation request, enforces scope narrowing, and issues a new Scope Envelope for the target agent that is guaranteed to be a subset of the delegating agent’s scope.

15.10.1 Request

POST /api/v1/agent/delegate
Headers:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}
  Content-Type: application/json

Body:
{
  "protocol_version": "2.0",
  "message_type": "DELEGATE",
  "delegating_agent_id": "agent-orchestrator-001",
  "target_agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "delegation_id": "del-001",
  "requested_scope": {
    "tools": ["iam_create_user", "iam_add_to_group"],
    "models": ["us.anthropic.claude-opus-4-7"],
    "max_actions": 10,
    "max_tokens": 50000,
    "max_ttl_seconds": 1800
  },
  "delegation_chain": ["agent-orchestrator-001"],
  "task_description": "Onboard new employee to IAM"
}

15.10.2 DELEGATE Fields

Field	Type	Required	Description
`protocol_version`	string	YES	Must be `"1.1"` for agentic messages
`message_type`	string	YES	Must be `"DELEGATE"`
`delegating_agent_id`	string	YES	Identity of the agent initiating the delegation
`target_agent_id`	string	YES	Identity of the agent receiving the delegation
`app_id`	string	YES	Parent application identity
`delegation_id`	string	YES	Unique identifier for this delegation
`requested_scope`	object	YES	Requested permissions and budgets for the target agent
`requested_scope.tools`	array[string]	YES	Tools the target agent should have access to
`requested_scope.models`	array[string]	YES	Models the target agent should have access to
`requested_scope.max_actions`	integer	YES	Maximum actions for the target agent
`requested_scope.max_tokens`	integer	YES	Maximum tokens for the target agent
`requested_scope.max_ttl_seconds`	integer	YES	Maximum time-to-live for the delegated scope
`delegation_chain`	array[string]	YES	Ordered list of agent IDs from root to delegating agent
`task_description`	string	YES	Human-readable description of the delegated task

15.10.3 Response

{
  "decision": "ALLOW",
  "delegation_id": "del-001",
  "issued_scope_envelope_id": "scope-env-002",
  "scope_envelope": {
    "tools": {"mode": "allowlist", "allowed": ["iam_create_user", "iam_add_to_group"]},
    "models": {"mode": "allowlist", "allowed": ["us.anthropic.claude-opus-4-7"]},
    "budgets": {"max_actions": 10, "max_tokens": 50000, "max_ttl_seconds": 1800}
  },
  "delegation_depth": 1
}

15.10.4 DELEGATE Response Fields

Field	Type	Required	Description
`decision`	enum	YES	One of: `ALLOW`, `DENY`
`delegation_id`	string	YES	Echoed delegation identifier for correlation
`issued_scope_envelope_id`	string	NO	Identifier of the newly issued scope envelope (present when decision is `ALLOW`)
`scope_envelope`	object	NO	The issued scope envelope contents (present when decision is `ALLOW`)
`delegation_depth`	integer	YES	Resulting depth in the delegation chain
`reason`	string	NO	Human-readable reason (present when decision is `DENY`)

15.10.5 Decision Values

Decision	Meaning
`ALLOW`	Delegation is authorized; scope envelope issued to target agent
`DENY`	Delegation is denied; target agent receives no scope

15.10.6 Scope Narrowing Enforcement

When processing a DELEGATE message, the Governance Authority enforces strict scope narrowing. The target agent’s scope is computed as:

B.scope = A.scope ∩ delegation_request.scope

Where:

A.scope is the delegating agent’s current Scope Envelope
delegation_request.scope is the requested_scope from the DELEGATE message
B.scope is the resulting scope envelope issued to the target agent

The intersection is applied per-dimension:

Tools — B.tools = A.tools.allowed ∩ requested_scope.tools. Any tool not in both sets is excluded from B’s envelope.
Models — B.models = A.models.allowed ∩ requested_scope.models. Same intersection logic.
Actions — B.max_actions = min(A.budget_remaining.actions, requested_scope.max_actions). The target cannot receive more actions than the delegator has remaining.
Tokens — B.max_tokens = min(A.budget_remaining.tokens, requested_scope.max_tokens).
TTL — B.max_ttl_seconds = min(A.remaining_ttl, requested_scope.max_ttl_seconds).

If the requested_scope contains any tool or model not present in the delegating agent’s scope, the Governance Authority MUST deny the delegation with a SCOPE_VIOLATION reason.

15.10.7 Maximum Delegation Depth

The Governance Authority enforces a hard limit of 5 on delegation chain depth. This prevents:

Infinite delegation loops
Unbounded chain complexity that degrades governance evaluation performance
Privilege laundering through deep delegation chains

The depth is computed as delegation_chain.length + 1. If the resulting depth exceeds 5, the Governance Authority MUST deny the delegation with a MAX_DEPTH_EXCEEDED reason.

Additionally, each agent declares a max_delegation_depth at registration time. The effective maximum is min(5, agent.max_delegation_depth).

15.11 Autonomy Levels and Budget Tracking

The Governance Authority assigns each agent an autonomy level and tracks resource consumption against a depletable budget. Together, these mechanisms ensure agents cannot exceed their authorized level of independence.

15.11.1 Autonomy Tiers

Level	Behavior	Escalation Trigger	Use Case
`OBSERVE`	Agent may reason but not act; all proposed actions are logged without execution	Any action attempt triggers a log entry	Shadow mode, new agent onboarding, audit-only deployments
`SUGGEST`	Agent proposes actions; each action requires explicit human approval before execution	Every proposed action is escalated	High-risk environments, compliance-sensitive workflows
`ACT_WITH_APPROVAL`	Agent executes pre-approved plan steps autonomously; escalates for any action not in the approved plan	Unplanned actions, irreversible actions matching approval gates	Standard production, most enterprise deployments
`ACT_AUTONOMOUS`	Agent acts freely within its Scope Envelope; escalates only when budget limits are approached	Budget warning threshold reached, budget exhausted	Low-risk read-only tasks, analytics, monitoring

The autonomy level is set in the agent’s Scope Envelope (autonomy_level field) and cannot be elevated by the agent itself. Only the Governance Authority or a human reviewer may change an agent’s autonomy level.

15.11.2 Budget Tracking

The Governance Authority tracks four budget dimensions for each agent session:

Dimension	Unit	Description
`actions`	count	Total number of tool invocations and model calls executed
`tokens`	count	Total tokens consumed across all model invocations
`cost_usd`	USD	Total monetary cost incurred across all operations
`time`	seconds	Elapsed wall-clock time since scope envelope issuance

Budget tracking is enforced at the Governance Authority level. Each TOOL_REQUEST response includes the current budget_remaining object, enabling agents to self-regulate before hitting hard limits.

Budget values are decremented atomically:

Actions — Decremented by 1 for each ALLOW decision on a TOOL_REQUEST
Tokens — Decremented by the actual token count reported via STEP_COMPLETE
Cost — Decremented by the actual cost computed from token usage and model pricing
Time — Computed as elapsed time since scope_envelope.issued_at

15.11.3 Escalation Triggers

The Governance Authority emits automatic escalations at configurable warning thresholds:

Threshold	Default	Behavior
Budget warning	80% consumed	Emit ESCALATE with reason `BUDGET_WARNING` to designated reviewer
Budget exhausted	100% consumed	Deny all further actions; emit ESCALATE with reason `BUDGET_EXHAUSTED`
Time limit approaching	90% of TTL elapsed	Emit ESCALATE with reason `BUDGET_WARNING` including time remaining
Time limit reached	100% of TTL elapsed	Expire scope envelope; deny all further actions

When a budget warning is emitted, the agent continues operating until the budget is fully exhausted or a human reviewer intervenes. The human reviewer may:

Replenish — Issue a new Scope Envelope with a fresh budget
Reduce — Lower the agent’s autonomy tier
Halt — Revoke the agent’s Scope Envelope entirely

15.12 Input Attestation

Input Attestation verifies that all content entering an agent’s context window originates from authorized sources and has not been tampered with. This mechanism prevents prompt injection, context poisoning, and unauthorized instruction sources from influencing agent reasoning.

Every content segment assembled into an agent’s context window — whether from a user, another agent, a tool response, a knowledge base, or persistent memory — MUST be attested before the agent reasons over it.

15.12.1 Request

POST /api/v1/agent/attest-input
Headers:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}
  Content-Type: application/json

Body:
{
  "protocol_version": "2.0",
  "message_type": "ATTEST_INPUT",
  "agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "scope_envelope_id": "scope-env-001",
  "segments": [
    {
      "source_type": "user",
      "source_id": "user-session-abc123",
      "content_hash": "sha256:a1b2c3d4e5f6...",
      "classification": "LOW",
      "attestation_signature": null
    },
    {
      "source_type": "tool_response",
      "source_id": "iam_create_user",
      "content_hash": "sha256:f7g8h9i0j1k2...",
      "classification": "MEDIUM",
      "attestation_signature": "hmac-sha256:l3m4n5o6..."
    },
    {
      "source_type": "knowledge_base",
      "source_id": "kb-prod-001",
      "content_hash": "sha256:p7q8r9s0t1u2...",
      "classification": "LOW",
      "attestation_signature": "hmac-sha256:v3w4x5y6..."
    },
    {
      "source_type": "memory",
      "source_id": "mem-001",
      "content_hash": "sha256:z1a2b3c4d5e6...",
      "classification": "MEDIUM",
      "attestation_signature": null
    }
  ]
}

15.12.2 ATTEST_INPUT Fields

Field	Type	Required	Description
`protocol_version`	string	YES	Must be `"1.1"` for agentic messages
`message_type`	string	YES	Must be `"ATTEST_INPUT"`
`agent_id`	string	YES	Identity of the agent assembling the context window
`app_id`	string	YES	Parent application identity
`scope_envelope_id`	string	YES	Reference to the agent’s active scope envelope
`segments`	array	YES	Ordered list of content segments to attest

15.12.3 Segments Array Item Fields

Field	Type	Required	Description
`source_type`	enum	YES	One of: `user`, `agent`, `tool_response`, `knowledge_base`, `memory`
`source_id`	string	YES	Specific identifier of the content source (user session ID, agent ID, tool ID, knowledge base ID, or memory entry ID)
`content_hash`	string	YES	SHA-256 hash of the content segment, prefixed with `sha256:`
`classification`	enum	YES	Data classification level: `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`
`attestation_signature`	string	NO	HMAC signature from the content source proving provenance (null if source does not support signing)

15.12.4 Response

{
  "decisions": [
    {
      "source_id": "user-session-abc123",
      "decision": "ALLOW",
      "reason": null
    },
    {
      "source_id": "iam_create_user",
      "decision": "ALLOW",
      "reason": null
    },
    {
      "source_id": "kb-prod-001",
      "decision": "ALLOW",
      "reason": null
    },
    {
      "source_id": "mem-001",
      "decision": "DENY",
      "reason": "CLASSIFICATION_EXCEEDS_SCOPE"
    }
  ],
  "all_allowed": false
}

15.12.5 ATTEST_INPUT Response Fields

Field	Type	Required	Description
`decisions`	array	YES	Per-segment attestation decisions
`decisions[].source_id`	string	YES	Echoed source identifier for correlation
`decisions[].decision`	enum	YES	One of: `ALLOW`, `DENY`
`decisions[].reason`	string	NO	Human-readable reason (present when decision is `DENY`)
`all_allowed`	boolean	YES	Convenience flag: `true` if all segments are `ALLOW`, `false` if any segment is `DENY`

15.12.6 Governance Evaluation

The Governance Authority evaluates an ATTEST_INPUT by checking each segment:

Source Authorization — Is the source_id present in the agent’s Scope Envelope authorized input sources? The Scope Envelope’s permissions.data_sources and permissions.agents.may_receive_from define the allowlist. If the source is not authorized, DENY with reason UNAUTHORIZED_SOURCE.
Content Integrity — Does the content_hash match the expected hash for the content? If an attestation_signature is provided, the Governance Authority verifies it against the source’s registered key. If verification fails, DENY with reason INTEGRITY_VIOLATION.
Classification Validation — Is the segment’s classification level within the agent’s permitted classification levels (defined in the Scope Envelope’s memory_scope.allowed_classifications)? If the classification exceeds what the agent is authorized to process, DENY with reason CLASSIFICATION_EXCEEDS_SCOPE.
Source Type Consistency — Does the source_type match the expected type for the given source_id? For example, a source_id registered as a tool cannot be attested as source_type: "user". If inconsistent, DENY with reason SOURCE_TYPE_MISMATCH.

If all segments pass all checks, the Governance Authority returns all_allowed: true. If any segment fails, the agent MUST strip the denied content from its context window before proceeding with reasoning.

15.12.7 Self-Attestation Prevention

Agents MUST NOT attest their own generated content as source_type: "user" input. The Governance Authority enforces this by:

Checking that the source_id in segments with source_type: "user" does not match any registered agent identifier.
Checking that the source_id in segments with source_type: "agent" does not match the requesting agent’s own agent_id.
If self-attestation is detected, the Governance Authority MUST deny the segment with reason SELF_ATTESTATION_VIOLATION and record the violation in the audit trail.

This prevents agents from injecting instructions into their own context window and attributing them to a user or another agent, which would bypass governance controls on agent-generated content.

15.13 MEMORY_WRITE Message

Sent when an agent persists state to long-term memory. The Governance Authority evaluates the write request against the agent’s memory governance policy to enforce data classification, retention limits, and isolation boundaries.

15.13.1 Request

POST /api/v1/agent/memory-write
Headers:
  X-AIGP-Signature: hmac-sha256={signature}
  X-AIGP-Timestamp: {iso_timestamp}
  X-AIGP-App-Id: {app_id}
  X-AIGP-Agent-Id: {agent_id}
  Content-Type: application/json

Body:
{
  "protocol_version": "2.0",
  "message_type": "MEMORY_WRITE",
  "agent_id": "agent-gandalf-spell-executor-001",
  "app_id": "APP_PRJ",
  "memory_id": "mem-001",
  "memory_scope": "AGENT_PRIVATE",
  "data_classification": "MEDIUM",
  "content_hash": "sha256:f7g8h9...",
  "retention_seconds": 86400,
  "purpose": "Cache onboarding workflow state for retry"
}

15.13.2 MEMORY_WRITE Fields

Field	Type	Required	Description
`protocol_version`	string	YES	Must be `"1.1"` for agentic messages
`message_type`	string	YES	Must be `"MEMORY_WRITE"`
`agent_id`	string	YES	Identity of the agent requesting the memory write
`app_id`	string	YES	Parent application identity
`memory_id`	string	YES	Unique identifier for this memory entry
`memory_scope`	enum	YES	Isolation level: `AGENT_PRIVATE`, `APP_SHARED`, `CROSS_APP`
`data_classification`	enum	YES	Data classification: `LOW`, `MEDIUM`, `HIGH`, `CRITICAL`
`content_hash`	string	YES	SHA-256 hash of the content being persisted, prefixed with `sha256:`
`retention_seconds`	integer	YES	Requested retention duration in seconds
`purpose`	string	YES	Human-readable description of why this memory entry is being persisted

15.13.3 Response

{
  "decision": "ALLOW",
  "memory_id": "mem-001",
  "actual_retention_seconds": 86400,
  "storage_location": "governed"
}

15.13.4 MEMORY_WRITE Response Fields

Field	Type	Required	Description
`decision`	enum	YES	One of: `ALLOW`, `DENY`
`memory_id`	string	YES	Echoed memory identifier for correlation
`actual_retention_seconds`	integer	NO	Actual retention granted (may be less than requested; present when decision is `ALLOW`)
`storage_location`	string	NO	Where the memory will be stored: `governed` (present when decision is `ALLOW`)
`reason`	string	NO	Human-readable reason (present when decision is `DENY`)

15.13.5 Memory Isolation Levels

The memory_scope field controls the isolation boundary for the persisted entry:

Level	Visibility	Use Case
`AGENT_PRIVATE`	Only the writing agent may read this entry	Session state, intermediate reasoning, agent-specific caches
`APP_SHARED`	All agents within the same `app_id` may read this entry	Shared workflow state, cross-agent coordination within an application
`CROSS_APP`	Agents across different applications may read this entry (requires explicit policy)	Platform-wide knowledge, shared reference data

The default isolation level is AGENT_PRIVATE. Escalation to APP_SHARED or CROSS_APP requires the agent’s Scope Envelope to explicitly authorize the broader scope via the memory_scope.isolation field.

15.13.6 Retention Enforcement

The Governance Authority enforces memory retention as follows:

Maximum Retention — The actual_retention_seconds granted MUST NOT exceed the agent’s Scope Envelope memory_scope.max_retention_seconds. If the requested retention exceeds the maximum, the Governance Authority reduces it to the maximum allowed value.
Automatic Purge — The Governance Authority maintains a background process that purges memory entries exceeding their actual_retention_seconds. Purged entries are removed from the agent’s accessible memory and recorded in the audit trail.
Early Revocation — The Governance Authority or a human reviewer may revoke a memory entry before its retention expires. This is used when a memory entry is found to contain policy-violating content or when an agent’s Scope Envelope is revoked.
Retention Extension — An agent may request a retention extension by submitting a new MEMORY_WRITE for the same memory_id. The Governance Authority evaluates the extension request against current policy.

15.13.7 Memory Read Governance

When an agent reads from persistent memory, the Governance Authority verifies:

Scope Envelope Active — The reading agent has a valid, non-expired Scope Envelope.
Classification Check — The memory entry’s data_classification is within the reading agent’s memory_scope.allowed_classifications.
Isolation Check — The memory entry’s memory_scope permits access by the reading agent (e.g., AGENT_PRIVATE entries are only accessible to the writing agent).
Retention Valid — The memory entry has not exceeded its retention duration.

If any check fails, the read is denied and the agent receives an empty response as if the memory entry does not exist. This prevents information leakage through error messages.

15.14 Circuit Breaker

The Circuit Breaker is a governance mechanism that automatically halts agent execution when error rates or anomalous behavior exceed configured thresholds. It prevents cascading failures across multi-agent delegation chains and provides a controlled recovery path.

15.14.1 State Machine

The Circuit Breaker operates as a three-state machine:

                 ┌─────────┐
                 │  CLOSED  │ ← Normal operation
                 └────┬────┘
                      │ error_rate > threshold
                      ▼
                 ┌─────────┐
                 │   OPEN   │ ← All requests denied
                 └────┬────┘
                      │ cooldown_elapsed
                      ▼
                 ┌─────────────┐
                 │  HALF-OPEN  │ ← Limited requests for recovery testing
                 └──────┬──────┘
                   │         │
            success│         │failure
                   ▼         ▼
              ┌────────┐  ┌──────┐
              │ CLOSED │  │ OPEN │
              └────────┘  └──────┘

15.14.2 States

State	Behavior	Description
`CLOSED`	Normal operation; all requests evaluated normally	The agent is healthy. TOOL_REQUEST and REQUEST messages are processed against the Scope Envelope as usual. Error events are counted within the sliding time window.
`OPEN`	All requests denied with `CIRCUIT_OPEN`	The agent has exceeded the error rate threshold. All TOOL_REQUEST and REQUEST messages are immediately denied without policy evaluation. The agent MUST NOT execute any actions.
`HALF-OPEN`	Limited requests allowed for recovery testing	The cooldown period has elapsed. A limited number of requests are permitted to test whether the underlying issue has been resolved. Success transitions to CLOSED; failure transitions back to OPEN.

15.14.3 Transitions

Transition	Trigger	Description
CLOSED → OPEN	`error_rate > error_rate_threshold` within `time_window_seconds`	The agent’s error rate (denied requests, failed tool invocations, policy violations) exceeds the configured threshold within the sliding time window.
OPEN → HALF-OPEN	`cooldown_seconds` elapsed since entering OPEN state	The configured cooldown period has passed. The Governance Authority allows a limited number of probe requests to test recovery.
HALF-OPEN → CLOSED	Probe request succeeds (receives ALLOW decision and completes without error)	The agent has demonstrated recovery. Normal operation resumes and the error counter is reset.
HALF-OPEN → OPEN	Probe request fails (receives DENY, times out, or produces an error)	The underlying issue persists. The circuit breaker returns to OPEN state and the cooldown timer resets.

15.14.4 Configuration

The Circuit Breaker is configured per-agent via a CIRCUIT_BREAKER policy:

Parameter	Type	Default	Description
`error_rate_threshold`	float	0.5	Error rate (0.0–1.0) that triggers the breaker. A value of 0.5 means 50% of requests within the time window resulted in errors.
`time_window_seconds`	integer	60	Sliding time window over which the error rate is computed.
`cooldown_seconds`	integer	30	Duration the breaker remains in OPEN state before transitioning to HALF-OPEN.
`recovery_conditions`	object	—	Conditions that must be met for HALF-OPEN → CLOSED transition.
`recovery_conditions.consecutive_successes`	integer	3	Number of consecutive successful probe requests required to close the breaker.
`recovery_conditions.max_probe_requests`	integer	5	Maximum probe requests allowed in HALF-OPEN state before forcing back to OPEN.

15.14.5 Cascading Failure Prevention

When a Circuit Breaker activates for an agent, the Governance Authority prevents cascading failures through the delegation chain:

Downstream Halt — All agents that received delegations from the halted agent (downstream in the delegation chain) are also transitioned to OPEN state. This prevents downstream agents from continuing work that depends on a failing upstream agent.
Upstream Notification — The agent that delegated to the halted agent (upstream in the delegation chain) receives an ESCALATE notification with reason DOWNSTREAM_CIRCUIT_OPEN, enabling it to take corrective action or re-route work.
Chain-Wide Recovery — When the root agent’s circuit breaker transitions from OPEN to CLOSED, downstream agents are permitted to recover independently through their own HALF-OPEN → CLOSED transitions.
Isolation Boundary — Circuit breaker activation in one delegation chain does not affect agents in unrelated delegation chains, even within the same application.

15.14.6 CIRCUIT_OPEN Response

When a Circuit Breaker is in OPEN state, all TOOL_REQUEST and REQUEST messages from the affected agent receive an immediate denial:

{
  "decision": "DENY",
  "reason": "CIRCUIT_OPEN",
  "circuit_breaker": {
    "state": "OPEN",
    "opened_at": "2026-06-01T00:30:00Z",
    "cooldown_remaining_seconds": 25,
    "error_rate": 0.72,
    "threshold": 0.5
  }
}

The circuit_breaker object provides the agent with visibility into the breaker state, enabling it to implement backoff strategies or notify its orchestrator.

The agent MUST NOT retry requests while the circuit breaker is OPEN. Retries during the OPEN state are counted as additional errors and may extend the cooldown period.

15.15 Protocol Bridge Architecture

The Protocol Bridge defines how AIGP integrates with external agent protocols to preserve governance decisions across protocol boundaries. When agents communicate via protocols outside AIGP — such as A2A (Agent-to-Agent), MCP (Model Context Protocol), or IATP (Identity and Trust Protocol) — the Protocol Bridge ensures that AIGP governance remains authoritative and audit continuity is maintained.

15.15.1 Purpose

Agents operating in heterogeneous environments may interact with external systems using protocols that have their own capability models, identity frameworks, and communication patterns. The Protocol Bridge translates AIGP governance artifacts into equivalent controls in external protocols and enforces AIGP policy on inbound external protocol messages.

The Protocol Bridge guarantees:

Governance Continuity — AIGP governance decisions are preserved when crossing protocol boundaries. An agent governed by AIGP does not lose governance coverage when communicating via an external protocol.
Audit Continuity — Trace identifiers are correlated across protocol boundaries, enabling end-to-end observability of agent interactions regardless of the underlying transport.
Default-Deny for Unmapped Interactions — If an external protocol interaction cannot be mapped to an AIGP governance decision, the Protocol Bridge applies default-deny and logs the unmapped interaction.

15.15.2 A2A (Agent-to-Agent) Bridge

The A2A Bridge translates AIGP governance artifacts into Google A2A protocol constructs and enforces AIGP policy on A2A messages.

Scope Envelope to A2A Capability Translation:

When an AIGP-governed agent communicates with an external agent via A2A, the Protocol Bridge translates the agent’s Scope Envelope into A2A-compatible capability declarations:

AIGP Scope Envelope Field	A2A Equivalent	Translation Rule
`permissions.tools.allowed`	A2A `capabilities.skills`	Each allowed tool maps to an A2A skill declaration
`permissions.models.allowed`	A2A `capabilities.models`	Model identifiers are passed through as capability metadata
`budgets.max_actions`	A2A task metadata	Communicated as task-level constraints
`autonomy_level`	A2A agent card metadata	Mapped to A2A interaction mode (request/delegate)

Governance Enforcement on A2A Messages:

When an AIGP-governed agent receives an A2A message, the Protocol Bridge intercepts the message and evaluates it against the agent’s Scope Envelope before delivery.
The sending agent’s A2A identity is correlated with AIGP agent identities via the identity registry. If no correlation exists, the message is treated as originating from an unauthorized source.
A2A task delegations are mapped to AIGP DELEGATE messages. The Protocol Bridge enforces scope narrowing on the translated delegation.

15.15.3 MCP (Model Context Protocol) Bridge

The MCP Bridge enforces AIGP tool authorization policies on MCP tool invocations and maps MCP interactions to AIGP governance messages.

Tool Authorization Enforcement:

When an agent invokes a tool via MCP, the MCP Bridge intercepts the tool call and translates it into an AIGP TOOL_REQUEST message before the invocation reaches the MCP server.
The MCP tool name and server identity are mapped to AIGP tool identifiers using the Tool Manifest registry.
If the TOOL_REQUEST is denied by the Governance Authority, the MCP Bridge returns an error response to the agent without forwarding the call to the MCP server.

MCP to AIGP Message Mapping:

MCP Interaction	AIGP Message	Description
`tools/call`	`TOOL_REQUEST`	MCP tool invocation maps to pre-invocation authorization
`tools/list`	Scope Envelope query	Available tools filtered by agent’s Scope Envelope
`resources/read`	`ATTEST_INPUT`	Resource reads attested as `source_type: "knowledge_base"`
`prompts/get`	`ATTEST_INPUT`	Prompt templates attested as `source_type: "tool_response"`

MCP Server Authorization:

Before an agent establishes a connection to an MCP server, the Protocol Bridge verifies that the MCP server’s identity and endpoint are authorized in the agent’s Scope Envelope. Unauthorized MCP server connections are denied and logged as policy violations.

15.15.4 IATP (Identity and Trust Protocol) Bridge

The IATP Bridge correlates AIGP agent identities with IATP identity assertions, enabling trust establishment across identity frameworks.

Identity Correlation:

The Governance Authority maintains a mapping between AIGP Agent_Identity records and IATP identity assertions (verifiable credentials, DID documents).
When an external agent presents an IATP identity assertion, the Protocol Bridge resolves it to an AIGP agent identity (if one exists) or treats the agent as unregistered.
When an AIGP-governed agent communicates with an IATP-aware system, the Protocol Bridge presents the agent’s AIGP identity as an IATP-compatible assertion.

Trust Chain Validation:

AIGP Concept	IATP Equivalent	Correlation Rule
`agent_id`	IATP subject identifier	Direct mapping via identity registry
`public_key`	IATP verification method	Key material shared across frameworks
`delegation_chain`	IATP delegation credential	Chain depth and scope preserved in IATP assertions
`scope_envelope_id`	IATP capability credential	Scope boundaries expressed as IATP capability claims

15.15.5 Audit Continuity

The Protocol Bridge maintains audit continuity by correlating AIGP trace identifiers with external protocol trace identifiers:

Trace Correlation Record — For every cross-protocol interaction, the Protocol Bridge records a correlation entry linking the AIGP trace_id with the external protocol’s trace identifier (A2A task_id, MCP request ID, or IATP transaction ID).
Span Propagation — When an AIGP trace span crosses a protocol boundary, the Protocol Bridge creates a child span in the external protocol’s tracing format and links it to the parent AIGP span.
Unified Query — The Governance Authority supports querying audit records by either AIGP trace identifiers or external protocol trace identifiers, returning the full cross-protocol interaction history.

15.15.6 Default-Deny for Unmapped Interactions

If an external protocol interaction cannot be mapped to an AIGP governance decision, the Protocol Bridge MUST:

Deny the interaction (default-deny).
Log the unmapped interaction with full context: source protocol, message type, agent identifiers (if available), and timestamp.
Emit an alert to operators indicating an unmapped protocol interaction was blocked.
Return a protocol-appropriate error response to the external system indicating that the interaction is not authorized.

The Governance Authority SHALL NOT permit pass-through of ungoverned interactions under any circumstances. This ensures that protocol boundary crossings cannot be used to bypass AIGP governance.

15.16 Backward Compatibility

The agentic governance extension is designed to be fully backward compatible with the existing AIGP protocol. Non-agentic applications continue to function without modification, and the Governance Authority serves both protocol versions simultaneously.

15.16.1 Existing Endpoints Unchanged

The following base protocol endpoints retain their current schemas and behavior without modification:

Endpoint	Method	Behavior
`/api/v1/register/{app_id}`	GET	Application registration and heartbeat
`/api/v1/request`	POST	Pre-invocation governance check
`/api/v1/record`	POST	Post-invocation audit record
`/api/v1/trace`	POST	Trace span submission

Applications using these endpoints with protocol_version: "1" continue to operate identically to the pre-extension protocol. No schema changes, no new required fields, and no behavioral differences.

15.16.2 New Endpoints Namespaced

All agentic governance endpoints are namespaced under /api/v1/agent/ to avoid any collision with existing endpoints:

Endpoint	Message Type
`/api/v1/agent/tool-request`	TOOL_REQUEST
`/api/v1/agent/plan-submit`	PLAN_SUBMIT
`/api/v1/agent/escalate`	ESCALATE
`/api/v1/agent/delegate`	DELEGATE
`/api/v1/agent/memory-write`	MEMORY_WRITE
`/api/v1/agent/step-complete`	STEP_COMPLETE
`/api/v1/agent/attest-input`	ATTEST_INPUT

15.16.3 Version Detection

Protocol version detection uses the protocol_version field in the REGISTER message:

"protocol_version": "2.0" — Base protocol. The Governance Authority applies only base governance (stages 1–17).
"protocol_version": "2.0" — Agentic protocol. The Governance Authority applies base governance plus agentic governance (stages 18–26).

Additionally, the REGISTER message includes "agent_capable": true to signal that the application declares agent capabilities. This field is only meaningful when protocol_version is "1.1".

15.16.4 Graceful Degradation

If an agent sends agentic protocol messages to a Governance Authority that does not support protocol version 1.1:

The agent receives HTTP 404 responses on /api/v1/agent/* endpoints.
Upon receiving a 404, the agent MUST fall back to base protocol behavior:
- Use /api/v1/request for pre-invocation checks (without agent-specific governance).
- Use /api/v1/record for audit recording.
- Operate without scope envelopes, delegation governance, or tool-level authorization.
The agent SHOULD log a warning indicating that agentic governance is unavailable and base protocol governance is in effect.
The agent MUST NOT fail or halt execution due to the absence of agentic governance endpoints. Graceful degradation to base protocol is mandatory.

15.16.5 Mixed Fleet Operation

The Governance Authority supports simultaneous operation of protocol version 1.0 and 1.1 clients:

Routing — The Governance Authority routes requests based on the endpoint path. Base protocol endpoints (/api/v1/register, /api/v1/request, /api/v1/record, /api/v1/trace) are handled by the base protocol engine. Agentic endpoints (/api/v1/agent/*) are handled by the agentic governance engine.
Shared Policy Store — Both protocol versions share the same policy store. Base protocol policies (use case governance, rate limits, model restrictions) apply to all applications. Agentic policies (scope envelopes, delegation policies, circuit breakers) apply only to applications that declare agent_capable: true.
Unified Audit Trail — Both protocol versions write to the same audit trail. Trace spans from base protocol and agentic protocol are interleaved chronologically and queryable through the same /api/v1/trace interface.
Independent Lifecycle — Base protocol applications and agentic applications have independent registration lifecycles. Upgrading an application from 1.0 to 1.1 does not affect other applications.

15.16.6 Non-Agentic Application Behavior

If an application does not declare agent_capable: true in its REGISTER message:

Only base protocol governance applies (stages 1–17).
Requests to /api/v1/agent/* endpoints are rejected with HTTP 403 Forbidden and reason AGENT_CAPABILITY_NOT_DECLARED.
The application is not assigned scope envelopes, delegation policies, or circuit breaker configurations.
The application continues to use protocol_version: "1" messages exclusively.

This ensures that existing non-agentic applications are completely unaffected by the agentic governance extension and cannot accidentally invoke agentic endpoints.

15.17 Security Considerations

This section defines security requirements specific to the agentic governance extension. These requirements address attack vectors unique to multi-agent architectures, including delegation abuse, scope escalation, replay attacks, and state tampering.

15.17.1 Agent Key Rotation

Agent keys MUST be rotatable without downtime. Key rotation is achieved through key versioning:

Each agent key is identified by a key_id (e.g., kid-a1b2c3d4).
When rotating a key, the agent registers a new key with a new key_id while the previous key remains valid for a configurable grace period.
The Governance Authority accepts signatures from any valid (non-expired) key_id for the agent during the grace period.
After the grace period, the old key_id is revoked and signatures using it are rejected.
Key rotation events are recorded in the audit trail with the old key_id, new key_id, and rotation timestamp.

15.17.2 Delegation Chain Depth Limit

The Governance Authority enforces a hard maximum delegation chain depth of 5 levels:

The root agent (depth 0) may delegate to an agent at depth 1.
An agent at depth 1 may delegate to an agent at depth 2, and so on.
An agent at depth 5 MUST NOT delegate further. Any DELEGATE message from an agent at depth 5 is denied with reason MAX_DELEGATION_DEPTH_EXCEEDED.
This limit prevents infinite delegation loops and bounds the blast radius of a compromised agent in the delegation chain.
The maximum depth is a protocol-level constant and is not configurable per agent. Individual agents may set a lower max_delegation_depth in their registration, but cannot exceed 5.

15.17.3 Scope Envelope Expiry

All scope envelopes have a mandatory time-to-live (TTL):

The expires_at field in the Scope Envelope is REQUIRED and MUST be set to a time no more than 1 hour from issued_at (default maximum TTL).
If an agent presents a scope envelope with an expires_at in the past, the Governance Authority MUST deny all requests and require the agent to obtain a new scope envelope.
Agents MUST proactively request scope envelope renewal before expiry to avoid service interruption.
The Governance Authority MAY issue scope envelopes with shorter TTLs based on risk assessment (e.g., 5 minutes for high-risk operations).
Expired scope envelopes are immutable — they cannot be extended. A new scope envelope must be issued.

15.17.4 Input Attestation Bypass Prevention

Agents MUST NOT self-attest their own generated content as “user” input:

The Governance Authority checks that source_id in segments with source_type: "user" does not match any registered agent identifier.
The Governance Authority checks that source_id in segments with source_type: "agent" does not match the requesting agent’s own agent_id.
If self-attestation is detected, the segment is denied with reason SELF_ATTESTATION_VIOLATION and the violation is recorded in the audit trail.
This prevents agents from injecting instructions into their own context window and attributing them to a user or another agent, which would bypass governance controls on agent-generated content.

15.17.5 Circuit Breaker Tampering Prevention

Circuit breaker state is maintained server-side only:

The Governance Authority is the sole authority for circuit breaker state transitions (CLOSED → OPEN → HALF-OPEN → CLOSED).
Agents cannot reset, override, or modify their own circuit breaker state.
Circuit breaker state is not included in any agent-writable message. Agents receive circuit breaker state as read-only information in DENY responses.
Only human operators or automated recovery policies (evaluated server-side) can force a circuit breaker state transition.
Any attempt by an agent to influence its circuit breaker state (e.g., by suppressing error reports) is detectable through audit trail analysis and constitutes a policy violation.

15.17.6 Memory Isolation Enforcement

Cross-agent memory reads require explicit policy authorization:

The default memory isolation level is AGENT_PRIVATE — an agent’s persisted state is accessible only to that agent.
Reading another agent’s memory requires the reading agent’s Scope Envelope to explicitly authorize access to the target agent’s memory namespace.
The Governance Authority enforces isolation at read time, not write time. Even if an agent writes with memory_scope: "APP_SHARED", other agents cannot read it unless their Scope Envelope permits.
Memory isolation violations are logged and trigger alerts. Repeated violations may activate the agent’s circuit breaker.

15.17.7 Replay Attack Prevention

All AIGP messages include timestamp validation to prevent replay attacks:

Every message includes an X-AIGP-Timestamp header containing an ISO 8601 timestamp.
The Governance Authority rejects messages where the timestamp differs from server time by more than 300 seconds (5 minutes maximum clock drift).
The Governance Authority maintains a short-lived cache of recently processed request_id values. Duplicate request_id values within the time window are rejected with reason DUPLICATE_REQUEST.
For TOOL_REQUEST messages, the combination of agent_id, tool_id, and request_id must be unique within the replay window.
Clock synchronization between agents and the Governance Authority is the responsibility of the deploying organization. NTP or equivalent time synchronization is RECOMMENDED.

15.17.8 Privilege Escalation Prevention

Delegation can never expand scope — only narrow it:

When Agent A delegates to Agent B, the Governance Authority computes B.scope = A.scope ∩ delegation_request.scope. The resulting scope is always a subset of (or equal to) Agent A’s scope.
If the requested delegation scope contains any permission not present in Agent A’s current Scope Envelope, the DELEGATE request is denied with reason SCOPE_ESCALATION_ATTEMPT.
An agent cannot delegate permissions it does not possess, even if the target agent previously held those permissions under a different scope envelope.
Scope narrowing is enforced transitively: if A delegates to B and B delegates to C, then C.scope ⊆ B.scope ⊆ A.scope.
The Governance Authority logs all delegation scope computations in the audit trail, enabling post-hoc verification that no privilege escalation occurred.

← 14. Summary · Section index · 16. Post-Hoc Evaluation Loop (RFC-032) →