RFC-009: Pre-Authorized Action Manifest Protocol¶

Version: 1.0
Status: Draft Authors: CapiscIO Core Team
Created: 2026-04-30
Updated: 2026-04-30
Requires: RFC-001 (AGCP), RFC-005 (Policy Definition, Distribution & Enforcement), RFC-008 (Delegated Authority Envelopes)

1. Abstract¶

This RFC defines the Pre-Authorized Action Manifest (PAM), the cryptographic artifact that declares the bounded action surface an agent is authorized to operate within before any tool call is issued. Where RFC-008 Authority Envelopes establish what authority has been delegated, Action Manifests establish what actions are permitted within that authority — at the level of specific tools, action signatures, capability classes, and operational constraints.

The manifest is a signed, version-hashed artifact registered at agent onboarding time and referenced on every agent-to-agent communication via the Intent Envelope, a required artifact in A2A protocol messages. Enforcement is deterministic: the RFC-009 Policy Enforcement Point (PEP) checks each incoming tool call against the Capability Binding Registry and the manifest before any PDP query is executed.

Governing Principle: This specification implements CapiscIO's core architectural invariant: LLMs can propose actions. They cannot define what is allowed. All authorization decisions are made by the deterministic enforcement plane. RFC-010 classifier output is advisory signal consumed at Step 1C; it does not make authorization decisions and MUST NOT be the sole basis for a DENY.

This specification defines:

• The Action Manifest format and schema, built as a CapiscIO Extension Profile over OASF (Open Agentic Schema Framework) records.
• The Capability Binding Registry — an authoritative, server-side mapping of (tool_name, action_signature) → capability_class, registered at manifest onboarding time and consulted deterministically at Step 1A.
• The Intent Envelope — a signed artifact carried on A2A requests that references the governing manifest.
• The three-phase validation model: Step 1A (deterministic capability binding check), Step 1B (deterministic manifest scope check), Step 1C (advisory RFC-010 signal enrichment), followed by Step 2 (RFC-005 PDP query).
• PERMISSIVE and STRICT transition modes for deployments where manifests are not yet present on all agents.
• The SDK provisioning model: zero developer configuration via CapiscIO.connect().
• Delegation pass-through semantics: an agent may delegate any capability it holds at 1:1 parity by default.
• Rejection codes: CAPABILITY_BINDING_MISMATCH (deterministic binding failure), MANIFEST_SCOPE_VIOLATION (manifest ceiling violation), INTENT_CLASSIFICATION_MISMATCH (classifier mismatch advisory), and others.

This specification is transport-agnostic. A normative A2A binding and a non-normative MCP binding are provided in appendices.

2. Relationship to Other RFCs¶

3. Terminology¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

4. Goals and Non-Goals¶

4.1 Goals¶

• Define a verifiable, pre-registered artifact that declares agent action scope before execution begins.
• Provide a required A2A message artifact that downstream agents can verify without round-trips to a central authority.
• Define deterministic Step 1 enforcement that catches the most dangerous action surface violations (operation type mismatch, boundary crossing) locally without PDP overhead.
• Enable zero-friction developer onboarding: manifest provisioning is handled automatically by CapiscIO.connect().
• Support incremental adoption through PERMISSIVE/STRICT transition modes.
• Define delegation pass-through semantics that do not penalize legitimate multi-agent workflows.

4.2 Non-Goals¶

• RFC-009 does not solve automated intent classification for open-ended natural language requests. That problem is addressed by RFC-010 as an advisory input layer. RFC-009 enforcement is always deterministic.
• RFC-009 does not define a general-purpose capability class vocabulary. Vocabulary is defined by the CapiscIO Capability Class Registry (separate publication). RFC-009 defines the manifest schema and enforcement model that consumes that vocabulary.
• RFC-009 does not define behavioral monitoring or dynamic trust adjustment over time. That is addressed by a future RFC.
• RFC-009 does not require enumeration of every possible tool call path for open-ended agents. It requires declaration of the capability class ceiling and action type boundaries. Individual tool call paths are validated against those ceilings, not against an exhaustive enumeration.

5. Action Manifest Schema¶

5.1 Overview¶

An Action Manifest is an OASF record extended with CapiscIO-specific fields. It is serialized as JSON, registered in the Manifest Registry, content-addressed via OCI/ORAS, and signed with the registering agent's Badge-bound key.

The manifest is registered once at agent onboarding. Updates require a new version with a new manifest hash. The previous version remains valid until explicitly revoked.

5.2 OASF Extension Profile¶

CapiscIO defines the following OASF record extensions under the namespace capiscio.v1:

{
  "oasf_version": "0.3",
  "record_type": "agent.capability_manifest",
  "agent_did": "did:web:example.com:agents:invoice-processor",
  "manifest_version": "1.0.0",
  "issued_at": 1746000000,
  "expires_at": 1777536000,
  "issuer_badge_jti": "b8f2c6a5-2d6f-4e44-9f55-2a1d6d9e0f12",
  "capiscio.v1": {
    "binding_schema_version": 3,
    "capability_classes": [
      {
        "class": "finance.invoicing.management",
        "action_type_ceiling": ["Read", "Write"],
        "boundary_ceiling": "Intra-org",
        "allowed_tools": [
          "read_invoice",
          "write_invoice",
          "approve_invoice",
          "list_invoices",
          "manage_invoice"
        ],
        "denied_tools": [],
        "constraints": {
          "max_records_per_query": 500,
          "allowed_resource_patterns": ["invoices/*"]
        }
      },
      {
        "class": "finance.invoicing.admin",
        "action_type_ceiling": ["Read", "Write", "Execute"],
        "boundary_ceiling": "Intra-org",
        "allowed_tools": [
          "manage_invoice",
          "delete_invoice"
        ],
        "denied_tools": [],
        "constraints": {}
      }
    ],
    "action_bindings": [
      {
        "tool_name": "write_invoice",
        "action_signature": {
          "operation_discriminator": null,
          "required_params": ["invoice_id", "amount", "vendor_id"],
          "declared_side_effect_class": "Write"
        },
        "capability_class": "finance.invoicing.management"
      },
      {
        "tool_name": "read_invoice",
        "action_signature": {
          "operation_discriminator": null,
          "required_params": ["invoice_id"],
          "declared_side_effect_class": "Read"
        },
        "capability_class": "finance.invoicing.management"
      },
      {
        "tool_name": "manage_invoice",
        "action_signature": {
          "operation_discriminator": {"param": "action", "value": "read"},
          "required_params": ["invoice_id"],
          "declared_side_effect_class": "Read"
        },
        "capability_class": "finance.invoicing.management"
      },
      {
        "tool_name": "manage_invoice",
        "action_signature": {
          "operation_discriminator": {"param": "action", "value": "delete"},
          "required_params": ["invoice_id"],
          "declared_side_effect_class": "Write"
        },
        "capability_class": "finance.invoicing.admin"
      }
    ],
    "delegation_policy": {
      "pass_through_allowed": true,
      "max_delegatable_depth": null
    },
    "enforcement_profile": "STRICT",
    "unknown_tool_behavior": "DENY"
  },
  "skills": [
    {
      "id": "invoice-processing",
      "name": "Invoice Processing",
      "description": "Read and write operations on invoice records within the Acme finance system.",
      "tags": ["finance", "invoicing"]
    }
  ]
}

5.3 CapiscIO Extension Field Definitions¶

5.4 Empty Allowlist Principle¶

An allowed_tools array that is empty MUST be treated as unsatisfiable, not unrestricted. A manifest entry with an empty allowed_tools is equivalent to DENY for all tools under that capability class. This prevents misconfiguration from silently granting broad access.

A denied_tools array that is empty means no tools are explicitly denied. This is the normal case for most capability classes. The denied_tools field is an explicit deny list that takes precedence over allowed_tools — it is not subject to the Empty Allowlist Principle.

5.5 Manifest Signature¶

The manifest MUST be signed by the registering agent's Badge-bound key using the same JWS Compact Serialization format as RFC-008 Authority Envelopes. The signature covers the canonical UTF-8 JSON serialization of the manifest object (excluding whitespace).

<base64url(header)>.<base64url(manifest_payload)>.<base64url(signature)>

Header:

{
  "alg": "EdDSA",
  "typ": "capiscio-action-manifest+jws",
  "kid": "did:web:example.com:agents:invoice-processor#key-1"
}

5.6 Manifest Hash Computation¶

The manifest hash is computed as:

manifest_hash = lowercase(hex(SHA-256(JWS_Compact_Serialization_bytes)))

This hash is the stable reference carried on Intent Envelopes. A manifest update produces a new hash and requires re-registration.

5.7 Capability Binding Registry¶

5.7.1 Purpose¶

The Capability Binding Registry is the authoritative server-side store for Action Bindings. It holds the deterministic mapping of (tool_name, action_signature) → capability_class for every registered agent. It is the primary enforcement input for Step 1A (§7.2).

The registry closes the parameter-escalation attack vector: without it, an agent could use the same tool name with different parameters to escalate from one capability class to another. By binding at the action-signature level — not just the tool-name level — the registry ensures that manage_user(action="delete") and manage_user(action="update") map to distinct, explicitly registered capability classes. No parameter combination can produce a class escalation not declared at registration time.

5.7.2 Action Binding Schema¶

Each Action Binding in the registry conforms to the following structure:

{
  "agent_did": "did:web:example.com:agents:invoice-processor",
  "binding_schema_version": 3,
  "tool_name": "manage_invoice",
  "action_signature": {
    "operation_discriminator": {
      "param": "action",
      "value": "delete"
    },
    "required_params": ["invoice_id"],
    "declared_side_effect_class": "Write"
  },
  "capability_class": "finance.invoicing.admin",
  "registered_at": 1746000000,
  "registered_by_badge_jti": "b8f2c6a5-2d6f-4e44-9f55-2a1d6d9e0f12"
}

5.7.3 Action Signature Resolution¶

When a tool call arrives at the PEP, the PEP MUST resolve the action signature before performing the registry lookup. Resolution algorithm:

1. Extract tool_name from the tool call.
2. Fetch all registered bindings for this agent_did and tool_name from local cache or registry.
3. If operation_discriminator is non-null for any binding, examine the tool call parameters for the specified param. If the param is present and its value matches a binding's value, select that binding. If multiple operation discriminators match, select the most specific (longest matching param path).
4. If operation_discriminator is null for a binding, it is the default binding for that tool name. Use it when no discriminator-based match is found.
5. If no binding matches: CAPABILITY_BINDING_MISMATCH with unregistered signature path. DENY in STRICT mode.
6. If the resolved binding's capability_class does not match the capability_class declared on the Intent Envelope: CAPABILITY_BINDING_MISMATCH. DENY regardless of mode.

Parameter Matching Semantics. When resolving an action signature, the PEP MUST use superset matching on tool call parameters:

• All parameters declared in the binding's operation_discriminator MUST be present in the tool call with matching values. Missing required discriminator parameters are a mismatch.
• Tool call parameters not referenced by any operation_discriminator are tolerated — their presence does not cause a mismatch. However, PEPs SHOULD log undeclared parameters as an UNDECLARED_PARAMS audit event to support binding completeness analysis.
• This ensures that bindings remain forward-compatible as tool schemas evolve (new optional parameters do not break existing bindings), while discriminator-specified parameters are strictly enforced.

5.7.4 Registry API¶

All registry responses MUST be signed by the CapiscIO server. PEPs MUST verify the server signature before caching binding data.

5.7.5 Three-Way Consistency Check¶

At Step 1A, the PEP MUST verify three-way consistency before performing any binding lookup:

1. Manifest hash match. The manifest_hash on the Intent Envelope MUST match the hash of the manifest retrieved from the Manifest Registry for this agent.
2. Tool inventory hash match (conditional). When RFC-010 is active: the tool inventory hash recorded at session init (RFC-010 tool_inventory_hash) MUST match the hash of the tool set declared in the current manifest's allowed_tools aggregate. When RFC-010 is not active, this check is SKIPPED.
3. Binding schema version match. The binding_schema_version embedded in the retrieved manifest MUST match the binding_schema_version returned by the Capability Binding Registry for this agent.

If any of the applicable checks fail, the PEP MUST NOT proceed to binding lookup. Behavior:

This prevents stale-binding attacks where a tool is re-registered under a new signature but an old manifest still references the previous binding version.

5.7.6 OASF Relationship¶

The Capability Binding Registry is designed as an OASF Attachable Object under the capiscio.v1.bindings extension namespace. This follows the OASF community extension model (OASF Discussion #314) for dynamic associations that provide additional functionality beyond the core agent record. Implementing CapiscIO registries SHOULD publish Action Binding sets as OASF attachable objects alongside the agent's OASF record to enable cross-platform capability discovery.

Integration with the MCP Registry (registry.modelcontextprotocol.io) for initial tool discovery during registration is non-normative but RECOMMENDED. When a developer registers an MCP server with CapiscIO, the SDK MAY query the MCP Registry for the server's tool list to pre-populate the action_bindings template before the developer declares side-effect classes and operation discriminators.

6. Intent Envelope¶

6.1 Purpose¶

The Intent Envelope is a signed artifact that an agent (the requestor) supplies on every A2A request. It declares:

1. Which Action Manifest governs this request (by manifest hash).
2. Which capability class the requestor claims for this operation.
3. Which action type the requestor declares for this operation.
4. The delegation chain reference linking this request to its RFC-008 Authority Envelope.

The receiving agent's RFC-009 PEP uses the Intent Envelope to perform Step 1 validation before any PDP query.

6.2 Intent Envelope Schema¶

{
  "envelope_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901",
  "manifest_hash": "a1b2c3d4e5f6...",
  "capability_class": "finance.invoicing.management",
  "declared_action_type": "Write",
  "declared_boundary": "Intra-org",
  "authority_envelope_hash": "e5f6a7b8c9d0...",
  "txn_id": "018f4e1d-7e5d-7a9f-a9d2-8b6a0f2c9b11",
  "tool_name": "write_invoice",
  "prompt_summary": "Process approved invoice INV-2024-0042 for vendor Acme Supplies",
  "issued_at": 1746000123,
  "expires_at": 1746000423,
  "issuer_did": "did:web:taxco.example:agents:taxbot",
  "issuer_badge_jti": "c9a3d7b6-3e7g-5f55-0g66-3b2e7e1f1g23"
}

6.3 Intent Envelope Field Definitions¶

6.4 Intent Envelope Signature¶

The Intent Envelope MUST be signed by the requestor's Badge-bound key:

<base64url(header)>.<base64url(intent_envelope_payload)>.<base64url(signature)>

Header:

{
  "alg": "EdDSA",
  "typ": "capiscio-intent-envelope+jws",
  "kid": "did:web:taxco.example:agents:taxbot#key-1"
}

7. Three-Phase Validation Model¶

7.1 Overview¶

RFC-009 validation is a strict sequence of three phases within Step 1, followed by Step 2. Failure at any phase MUST prevent all subsequent phases from executing. All three Step 1 phases must pass before Step 2 executes.

The three phases are explicitly named and sequenced to prevent mental collapse of distinct enforcement concerns:

Incoming Tool Call + Intent Envelope
        │
        ▼
┌─────────────────────────────────────────┐
│ STEP 1A: Capability Binding Validation  │
│ (Deterministic. Capability Binding      │
│  Registry lookup. No PDP.)              │
│                                         │
│ a. Intent Envelope present?             │
│ b. Signature + expiry valid?            │
│ c. Three-way consistency check:         │
│    - manifest_hash matches registry?    │
│    - tool_inventory_hash matches?       │
│    - binding_schema_version matches?    │
│ d. Action signature resolved?           │
│ e. Registry binding → declared class?  │
│                                         │
│ PASS → Step 1B                         │
│ FAIL → CAPABILITY_BINDING_MISMATCH     │
│        or MANIFEST_VERSION_MISMATCH    │
│        (DENY, do not continue)          │
└─────────────────────────────────────────┘
        │
        ▼ (on PASS)
┌─────────────────────────────────────────┐
│ STEP 1B: Manifest Scope Check           │
│ (Deterministic. Local manifest check.   │
│  No PDP.)                               │
│                                         │
│ f. tool_name in allowed_tools for class?│
│ g. declared_action_type within ceiling? │
│ h. declared_boundary within ceiling?    │
│                                         │
│ PASS → Step 1C                         │
│ FAIL → MANIFEST_SCOPE_VIOLATION         │
│        (DENY, do not continue)          │
└─────────────────────────────────────────┘
        │
        ▼ (on PASS)
┌─────────────────────────────────────────┐
│ STEP 1C: RFC-010 Signal Enrichment      │
│ (Advisory. Non-blocking by default.     │
│  Classifier output only.)               │
│                                         │
│ i. RFC-010 active and verdict present?  │
│ j. Composite confidence ≥ threshold?    │
│ k. Classifier class consistent with     │
│    declared class?                      │
│                                         │
│ Consistent or inactive → Step 2        │
│ Inconsistent → log INTENT_CLASSIF-     │
│   ICATION_MISMATCH warning, escalate   │
│   if confidence below threshold        │
│                                         │
│ NOTE: Step 1C MUST NOT block execution  │
│ solely on classifier output. It MAY     │
│ escalate. It MUST NOT DENY.             │
└─────────────────────────────────────────┘
        │
        ▼ (on PASS through all Step 1 phases)
┌─────────────────────────────────────────┐
│ STEP 2: PDP Authorization Query         │
│ (RFC-005, existing path)                │
│                                         │
│ PIP projection includes:                │
│ - agent identity (RFC-002 badge)        │
│ - capability_class                      │
│ - declared_action_type                  │
│ - declared_boundary                     │
│ - manifest_hash                         │
│ - tool_name                             │
│ - intent_envelope_hash                  │
│ - RFC-008 authority envelope claims     │
│ - classification.* (RFC-010, advisory)  │
│                                         │
│ ALLOW → execute tool call               │
│ DENY  → SCOPE_INSUFFICIENT              │
└─────────────────────────────────────────┘

7.2 Step 1A: Capability Binding Validation (Deterministic)¶

Step 1A is the authoritative, deterministic check that the tool call's action signature maps to the declared capability class via the Capability Binding Registry. It does not contact the PDP. It is not probabilistic. A mismatch at Step 1A is a hard security boundary, not an advisory signal.

Step 1A sequence (in order, fail-closed at each sub-step):

1. Intent Envelope presence. If no Intent Envelope is present, behavior is governed by the active enforcement mode (§8). In STRICT mode, DENY immediately with SCOPE_INSUFFICIENT. In PERMISSIVE mode, log warning and proceed directly to Step 2 without any Step 1 checks.

2. Signature verification. Verify the Intent Envelope JWS signature against the issuer's Badge-bound key per RFC-002 and RFC-003. MUST reject alg: "none". On failure: INTENT_ENVELOPE_INVALID.

3. Expiry check. expires_at MUST be in the future. On failure: INTENT_ENVELOPE_EXPIRED.

4. Manifest retrieval. Retrieve the Action Manifest by manifest_hash from local cache or Manifest Registry. On failure: MANIFEST_NOT_FOUND. Cache manifests with TTL aligned to manifest expires_at.

5. Three-way consistency check. Per §5.7.5, verify:

6. The retrieved manifest's hash matches the manifest_hash on the Intent Envelope.
7. If RFC-010 is active, the tool inventory hash recorded at session init matches the hash of the manifest's declared tool surface.
8. The binding_schema_version in the retrieved manifest matches the version returned by the Capability Binding Registry for this agent.

9. On any mismatch: MANIFEST_VERSION_MISMATCH (manifest or inventory) or CAPABILITY_BINDING_MISMATCH (binding version). DENY in STRICT mode; escalate in PERMISSIVE.

10. Action signature resolution. Extract the tool name and relevant parameters from the tool call. Apply the resolution algorithm in §5.7.3 to identify the matching Action Binding in the Capability Binding Registry. If no binding matches the resolved signature: CAPABILITY_BINDING_MISMATCH (unregistered signature path).

11. Binding class check. The capability_class returned by the Capability Binding Registry lookup MUST exactly match the capability_class declared on the Intent Envelope. If they differ: CAPABILITY_BINDING_MISMATCH. This check is deterministic. It is not influenced by RFC-010 classifier output.

7.3 Step 1B: Manifest Scope Check (Deterministic)¶

Step 1B validates that the declared action is within the capability class boundaries declared in the manifest. It uses the manifest retrieved in Step 1A. No additional network calls are required.

Step 1B sequence (in order, fail-closed at each sub-step):

1. Tool authorization. Verify tool_name is present in allowed_tools for the declared capability_class in the retrieved manifest. If not present: MANIFEST_SCOPE_VIOLATION with rejected_tool and presented_class fields.

2. Action type check. Verify declared_action_type is within the action_type_ceiling for the declared capability_class. If the action type exceeds the ceiling: MANIFEST_SCOPE_VIOLATION.

3. Boundary check. Verify declared_boundary does not exceed the boundary_ceiling for the declared capability_class. If the boundary exceeds the ceiling: MANIFEST_SCOPE_VIOLATION.

7.4 Step 1C: RFC-010 Signal Enrichment (Advisory)¶

Step 1C receives the RFC-010 classifier verdict if RFC-010 is active. It is advisory. It MUST NOT block execution solely on classifier output.

Step 1C is governed by the following invariant:

Step 1C may escalate. Step 1C MUST NOT DENY.

Decisions to DENY are made at Step 1A and Step 1B (deterministic) or Step 2 (PDP). Step 1C routes anomalous signals to the escalation handler and logs mismatch events. It does not add a third enforcement gate.

Step 1C sequence:

1. RFC-010 verdict availability. If RFC-010 is not active or the classifier timed out, skip to Step 2.

2. Confidence threshold check. If the composite confidence score is below the configured threshold (default: 0.7): route to escalation handler (§9). Do not block. Do not proceed silently — escalation is required.

3. Classifier class consistency. If the RFC-010 classified capability class differs from the declared capability class: log INTENT_CLASSIFICATION_MISMATCH warning event with rfc010_verdict_class and declared_class fields. Route to escalation handler. Do not block.

Note: An INTENT_CLASSIFICATION_MISMATCH event emitted at Step 1C is a warning event, not a block event. It is correlated to the capiscio.policy_enforced event by txn_id for forensic analysis and feeds the RFC-010 Policy Recommendation Engine. A pattern of persistent Step 1C mismatches for a given agent is the signal for a server-side manifest refinement recommendation.

7.5 Rejection Code Summary¶

7.6 Step 2: PDP Authorization Query¶

Step 2 is the existing RFC-005 PDP query path, extended with RFC-009 attribute projections.

The PIP projection for RFC-009 requests MUST include the following additional fields beyond those defined in RFC-005:

{
  "intent": {
    "manifest_hash": "<hash>",
    "binding_schema_version": 3,
    "capability_class": "finance.invoicing.management",
    "declared_action_type": "Write",
    "declared_side_effect_class": "Write",
    "declared_boundary": "Intra-org",
    "tool_name": "write_invoice",
    "intent_envelope_hash": "<hash of intent envelope JWS>",
    "prompt_summary": "<if present, selectively disclosed>"
  }
}

The PDP MAY use these fields for fine-grained policy decisions. Existing RFC-005 policies that do not reference intent.* fields are unaffected. The classification.* fields from RFC-005 §5.1 (RFC-010 classifier output) are projected separately and are subject to the normative constraint in RFC-005 §5.1: they MUST NOT be the sole basis for a DENY decision.

8. Enforcement Modes¶

8.1 PERMISSIVE Mode¶

PERMISSIVE mode is intended for development environments and incremental rollout where not all agents in a deployment have been updated to supply Intent Envelopes.

In PERMISSIVE mode: * Agents without an Intent Envelope are NOT blocked. A warning event is emitted. * Agents with an Intent Envelope undergo full Step 1 validation. * Agents with an Intent Envelope referencing an unregistered manifest are logged and warned but NOT blocked.

PERMISSIVE mode MUST NOT be used in production environments where enforcement guarantees are required.

8.2 STRICT Mode¶

STRICT mode is the production-default and RECOMMENDED mode.

In STRICT mode: * Agents without an Intent Envelope are DENIED immediately. SCOPE_INSUFFICIENT is emitted. * Agents with an invalid Intent Envelope (expired, bad signature, missing fields) are DENIED. * Agents with an Intent Envelope referencing an unregistered manifest are DENIED with MANIFEST_NOT_FOUND. * All Step 1 checks are enforced fail-closed.

8.3 Mode Configuration¶

Enforcement mode is configured at the PEP level, not in policy YAML. This is consistent with RFC-008's enforcement_mode placement on EvaluateToolAccessRequest. The @guard decorator accepts an intent_enforcement_mode parameter:

@guard(
    config="policy.yaml",
    capability_class="finance.invoicing.management",
    intent_enforcement_mode="strict"   # or "permissive"
)
async def write_invoice(ctx, params):
    ...

Default: "strict" in production SDK builds.

9. Escalation Protocol¶

9.1 Escalation Triggers¶

The following conditions trigger escalation rather than immediate block or allow:

• Low RFC-010 confidence. When RFC-010 is active and the classifier confidence for any REQUIRED axis is below the configured threshold (default: 0.7), the PEP SHOULD pause execution and route to the escalation handler rather than proceeding or blocking.
• Declared action type is Irreversible. When the declared_action_type maps to an inherently irreversible operation (Delete, bulk mutation, Provision) and boundary_ceiling is External, a human gate escalation is RECOMMENDED regardless of confidence.
• Manifest version mismatch. If the manifest referenced by the Intent Envelope has been superseded by a newer version, the PEP SHOULD warn and continue (not block), but MUST log the version delta.

9.2 Escalation Handler Interface¶

Escalation is routed to a registered EscalationHandler. The SDK provides a no-op default that logs and blocks. Operators MAY register custom handlers:

guard = CapiscIO.connect(
    config="policy.yaml",
    escalation_handler=MyHumanApprovalHandler()
)

The escalation handler receives: * The Intent Envelope * The triggering condition (low confidence, irreversible action, etc.) * The RFC-010 classification verdict (if available) * The pending tool call parameters

The handler MUST return ALLOW or DENY within the configured timeout (default: 30 seconds). If the handler times out, the PEP MUST DENY (fail-closed).

10. Delegation Pass-Through Semantics¶

10.1 Default Pass-Through¶

By default (delegation_policy.pass_through_allowed: true), an agent MAY delegate any capability class it holds to a downstream agent at 1:1 parity. This is consistent with RFC-008 §8.2, which defines equal capability class as a valid narrowing (subset-or-equal).

Delegation at 1:1 parity is not an expansion of scope and MUST NOT be treated as a policy violation. Restricting pass-through is an optional operator policy choice, not a default security requirement.

10.2 Optional Restriction¶

Operators who require that agents delegate only a narrower subset of their capability classes MAY configure per-class delegation restrictions in the manifest:

{
  "capiscio.v1": {
    "capability_classes": [
      {
        "class": "finance.invoicing.management",
        "action_type_ceiling": ["Read", "Write"],
        "boundary_ceiling": "Intra-org",
        "allowed_tools": [...],
        "delegatable_action_types": ["Read"]
      }
    ]
  }
}

The optional delegatable_action_types field restricts which action type sub-ceiling the agent may pass to a downstream agent. This is evaluated by the PDP as an optional policy constraint, not a PEP structural check. When absent, the full action_type_ceiling is delegatable.

10.3 Delegation Validation at Issuance¶

When an agent creates a derived RFC-008 Authority Envelope for a downstream agent, the RFC-008 PEP MUST verify that delegation_policy.pass_through_allowed is true on the delegating agent's manifest before permitting derived envelope creation. If pass_through_allowed is false, all delegation attempts MUST fail with SCOPE_INSUFFICIENT.

11. SDK Provisioning: Zero Developer Friction¶

11.1 Automatic Manifest Management¶

Action Manifest creation, registration, and versioning are handled automatically by CapiscIO.connect(). Developers do not create, sign, or register manifests manually.

At CapiscIO.connect() time, the SDK:

1. Inspects all @guard-decorated functions in the connected agent to enumerate the tool surface (tool names, declared capability classes, action types).
2. Constructs an Action Manifest reflecting the declared surface.
3. Compares the candidate manifest to the last registered manifest by content hash.
4. If changed, signs and registers the new manifest with the Manifest Registry.
5. Returns the current manifest_hash for inclusion in outbound Intent Envelopes.
6. Caches the manifest locally for Step 1 validation of inbound requests.

This provisioning happens once per session initialization. Developers interact only with @guard decorators; manifest management is invisible.

11.2 Manifest Versioning¶

Manifests are immutable after registration. Any change to the declared tool surface (adding a tool, changing a capability class, updating a boundary ceiling) results in a new manifest version with a new hash. Old versions remain retrievable for audit purposes and are not automatically revoked.

The Manifest Registry MUST maintain a version chain: each manifest version records the hash of its predecessor.

11.3 Intent Envelope Construction¶

Outbound Intent Envelopes are constructed automatically by the SDK at tool dispatch time. The developer does not construct envelopes manually.

# Developer code — unchanged from current usage
@guard(
    config="policy.yaml",
    capability_class="finance.invoicing.management"
)
async def write_invoice(ctx, params):
    # SDK intercepts the tool call, constructs and attaches
    # the Intent Envelope automatically before dispatch
    ...

The SDK resolves declared_action_type from the tool's @guard metadata and the manifest's action_type_ceiling. Where a tool can perform multiple action types (e.g., a tool that reads and writes depending on parameters), the SDK uses the highest applicable action type from the ceiling.

12. A2A Protocol Binding (Normative)¶

12.1 Intent Envelope as Required A2A Field¶

In A2A protocol messages governed by RFC-009, the Intent Envelope MUST be present in the _meta extension field of the JSON-RPC request:

{
  "jsonrpc": "2.0",
  "method": "message/send",
  "params": { "...": "..." },
  "_meta": {
    "capiscio_txn": "<txn_id>",
    "capiscio_hop": "<hop_attestation_jws>",
    "capiscio_intent": "<intent_envelope_jws>"
  }
}

The capiscio_intent field carries the JWS Compact Serialization of the Intent Envelope.

12.2 Receiving Agent Obligations¶

A receiving agent operating under RFC-009 MUST:

1. Extract the Intent Envelope from _meta.capiscio_intent.
2. Execute Step 1 validation before processing the request payload.
3. Execute Step 2 PDP query on Step 1 pass.
4. Return structured rejection responses on failure per §7.3.

12.3 Rejection Response Format¶

{
  "code": "MANIFEST_SCOPE_VIOLATION",
  "declared_class": "finance.invoicing.management",
  "declared_action_type": "Read",
  "rejected_tool": "delete_invoice",
  "manifest_hash": "a1b2c3d4...",
  "intent_envelope_id": "b2c3d4e5...",
  "txn_id": "018f4e1d..."
}

13. Manifest Registry¶

13.1 Registry Operations¶

13.2 Registry Outage Behavior¶

PEPs SHOULD cache manifests locally by manifest_hash with TTL aligned to the manifest's expires_at field. When the Registry is unreachable:

• Requests referencing a cached manifest: proceed normally.
• Requests referencing an uncached manifest: behavior governed by enforcement mode. STRICT: DENY. PERMISSIVE: warn and proceed.

14. Security Considerations¶

15. Future Work¶

• Capability Class Registry. A standardized, publicly maintained registry of typed capability class definitions with formal action_type_ceiling, boundary_ceiling, and allowed_tools profiles. Enables cross-organizational interoperability without custom vocabulary negotiation.
• Manifest Composition. Rules for merging manifests from multiple registries or principals when an agent acts under authority from multiple sources simultaneously.
• Structured Constraint Vocabulary. Typed constraint types beyond the opaque constraints object, aligned with the Mastercard Verifiable Intent constraint registry pattern. Enables deterministic PDP evaluation without per-deployment policy interpretation.
• RFC-010 Integration Tightening. As RFC-010 classifier confidence improves empirically, future revisions may allow high-confidence RFC-010 verdicts to partially substitute for declared capability class in Step 1, reducing manifest enumeration burden for open-ended agents.

Appendix A: MCP Transport Binding (Non-Normative)¶

For MCP tool calls, the Intent Envelope SHOULD be carried in the _meta field of the JSON-RPC tools/call request:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "write_invoice",
    "arguments": { "...": "..." }
  },
  "_meta": {
    "capiscio_txn": "<txn_id>",
    "capiscio_hop": "<hop_attestation_jws>",
    "capiscio_intent": "<intent_envelope_jws>"
  }
}

The capiscio-mcp package handles this automatically when CapiscIO.connect() is initialized.

Appendix B: Glossary of Rejection Codes¶

Changelog¶