Clarify Provider 06 action_context → Agent Integrity envelope contract

[SimranPabla]

Clarify Provider 06 action_context → Agent Integrity Envelope Contract

Summary

Provider 06 currently proves Agent Integrity verdict mapping into CAGE, but the contract for forming the Agent Integrity verification envelope from CAGE v3 action_context remains unclear.

From the prior design discussion, the intended flow appears to be:

1. CAGE gathers the governed transaction context.
2. CAGE constructs a complete Agent Integrity envelope.
3. CAGE sends the envelope to Agent Integrity.
4. Agent Integrity returns a signed PASS, REVIEW, or BLOCKED receipt.
5. CAGE maps the result to ALLOW, DEFER, or DENY and preserves the proof in its audit trail.

Before changing either project's schema, we should define the exact boundary between CAGE's internal v3 payload and Agent Integrity's canonical public protocol.

Confirmed Current Behavior

• Provider 06 implements the NormativeProvider seam and posts the supplied payload to /verify.
• The adapter maps:
  • PASS → admitted / ALLOW
  • REVIEW → human-review DEFER
  • BLOCKED → DENY
• The mock and tests prove verdict translation.
• Agent Integrity's canonical envelope expects policy, response, sources, decisionRegistryDigest, decisions, evidence, and claims.
• CAGE v3 action-context field drift includes amount → magnitude and symbol → context.
• Those action-context fields are not fields in the canonical Agent Integrity envelope.
• Provider 06 must not implement or register GovernanceTierPlugin, InvariantModel, DomainToolProvider, or a cage.plugins entry point.

Contract Questions

1. Exact /verify Request

Should /verify receive:

• the canonical Agent Integrity envelope directly; or
• a CAGE-owned transport wrapper containing both action_context and an Agent Integrity envelope?

Please provide the intended JSON structure.

2. Canonical Transformation Example

Please provide one complete example containing:

• a realistic CAGE v3 action_context;
• the exact request body sent to /verify;
• the expected signed PASS, REVIEW, or BLOCKED result;
• the resulting CAGE gating outcome.

This is the most important artifact needed to remove ambiguity.

3. Verified Artifact

For a governed transaction, what exact bytes should CAGE place in response.content?

Examples might include:

• the JCS-canonicalized proposed action;
• an agent-generated recommendation;
• a governance decision;
• a transaction explanation;
• another release artifact.

The receipt binds to these exact bytes, so their meaning and lifecycle point must be explicit.

4. Envelope Formation Ownership

Which CAGE component constructs and supplies:

• response sections;
• claims;
• evidence anchors;
• source records;
• decisions;
• decisionRegistryDigest;
• verification policy?

For each field, please identify whether it is trusted host state or agent-supplied data.

5. Source-Byte Access

How will Agent Integrity independently obtain the source bytes needed to recompute hashes?

Candidate models:

• inline immutable bytes;
• a read-only per-run snapshot;
• short-lived object-storage capabilities.

Paths and supplied hashes alone are insufficient for independent byte verification.

6. Evidence Completeness

Which trusted component decides that the supplied evidence set is complete?

Agent Integrity can verify the supplied bytes and relationships, but cannot determine whether CAGE omitted a relevant source unless a trusted collector defines and attests the evidence set.

7. Intended Guarantee

Please state the exact guarantee expected from Provider 06. For example:

• response or recommendation consistency with approved sources and decisions;
• proposed-action support by approved evidence;
• policy compliance;
• correct derivation of a governance decision;
• payload integrity;
• a defined combination of these.

8. Schema Ownership and Versioning

Proposed boundary:

• CAGE owns its v3 action_context schema and action-context-to-envelope mapper.
• Agent Integrity owns its canonical envelope and receipt schemas.
• CAGE internal field renames are absorbed by the mapper.
• Agent Integrity's public schema changes only when a genuinely new verification capability requires a versioned protocol or profile.

Please confirm whether this matches the intended architecture.

9. Runtime Wiring

Is enforce_fria_boundary() wired into a live execution path on another branch or planned stage?

In the inspected refactor branch, the function, adapter, mock, and tests are present, but a non-test call site constructing a complete Agent Integrity envelope was not found.

10. Enforcement Timing

For confidence scores at or above 0.95, CAGE allows the action and performs external verification asynchronously. A later BLOCKED result cannot prevent the action.

Is post-hoc verification intentional for Provider 06, or should selected action or artifact classes require synchronous verification before execution or release?

11. Receipt Atomicity and Storage

Can /verify return the signed receipt atomically, rather than requiring separate /verify and /receipt calls?

Can CAGE preserve the complete signed receipt as a first-class immutable audit artifact instead of embedding signature data in an untyped findings entry?

12. Failure Behavior

Please confirm the required behavior for:

• unavailable verifier;
• timeout;
• malformed request;
• schema mismatch;
• unsupported protocol version;
• missing source bytes;
• digest mismatch;
• invalid receipt signature.

Recommendation: every synchronous verification failure fails closed.

Requested Migration Artifacts

Please provide:

• canonical CAGE v3 action_context schema;
• renamed-key mapping;
• valid v3 action-context fixture;
• expected Agent Integrity request fixture;
• signed PASS fixture;
• signed REVIEW fixture;
• signed BLOCKED fixture;
• malformed and unknown-key fixtures;
• unavailable-provider and timeout behavior.

Schema Loading Issue

mock_endpoint.py currently appears to load:

local/integrations/singh/integrity-envelope.schema.json

The vendored schema is located at:

third_party/agent-integrity/schemas/integrity-envelope.schema.json

When schema loading fails, validation is disabled. The integration should use the vendored schema and fail closed when it is unavailable or invalid.

Proposed Acceptance Criteria

• The CAGE v3 input contract is documented.
• A deterministic CAGE v3 action_context → Agent Integrity request mapping is documented and tested.
• The canonical Agent Integrity envelope is not silently forked for CAGE.
• Exact verified bytes and source-byte transport are defined.
• Evidence-completeness ownership is defined.
• PASS / REVIEW / BLOCKED behavior is tested end to end.
• Receipt issuance is cryptographically bound to the exact verified request.
• Synchronous failure behavior is fail closed.
• Schema loading cannot silently disable validation.
• Provider 06 remains outside all domain-plugin protocols.
• Attribution uses Agent Integrity by Simran Pabla and the current repository: https://github.com/SimranPabla/agent-integrity

Forward-Looking Note

Agent Integrity can be extended if CAGE requires independent pre-execution action verification. If that is the intended capability, it should be designed as an explicit, versioned action-integrity profile with its own schema, threat model, conformance fixtures, and documented guarantee rather than implicitly reinterpreting the existing response-verification envelope.

[SimranPabla]

Update after merged conformance PR #205

The conformance question is now resolved. PR #205 merged and proved that the existing Agent Integrity 1-alpha response envelope can represent and verify the frozen CAGE governed-response fixture without changing Provider 06 runtime behavior or either public schema.

I also reviewed current CAGE main after PR #218 (fcb98bef0b5faea1afcc5a430148fe065b985ef4). The Provider 06 assets now live under:

• docs/partners/provider_06/
• tests/integrations/provider_06/

The runtime seam remains src/integrations/provider_06/adapter.py.

Approved next direction

The next phase will use an Agent Integrity-owned private HTTP sidecar, initially deployed on the same host over loopback or a private Unix socket. The API will remain transport-compatible with a future same-pod Kubernetes deployment.

Ownership boundary

CAGE owns:

• selection and freezing of the exact response/artifact;
• trusted source and decision collection;
• creation of an immutable per-request evidence snapshot;
• evidence-completeness attestation;
• construction of the canonical Agent Integrity envelope;
• request authentication credentials;
• routing PASS, REVIEW, and BLOCKED into CAGE behavior.

Agent Integrity owns:

• canonical envelope and receipt schemas;
• trusted verification behavior;
• real Ed25519 receipt signing;
• receipt and replay storage;
• exact-byte release;
• fail-closed service behavior.

Provider 06 remains a first-party integration through NormativeProvider. It will not implement or register any domain-plugin protocol.

Runtime contract direction

The production operation should be atomic, conceptually:

POST /v1/verify-release

One authenticated call will:

1. resolve an allowlisted immutable evidence bundle;
2. verify the canonical envelope against the actual source and decision bytes;
3. return PASS, REVIEW, or BLOCKED;
4. create and persist a real signed receipt;
5. consume replay/idempotency state;
6. return releasable response bytes only for a valid PASS.

The production design will not use separate /verify and /receipt calls because that creates an avoidable binding gap. CAGE will preserve the complete signed receipt as a first-class audit artifact rather than flattening signature data into generic findings.

Failure behavior

Authentication failure, malformed input/output, unsupported protocol version, unavailable verifier, timeout, missing evidence, source mutation, invalid signature, receipt-store failure, and replay detection will all fail closed. REVIEW will never admit or release the response.

Planned sequence

1. Agent Integrity PR: add the private sidecar, atomic verify/sign/release service, authentication boundary, durable receipt/replay storage, health checks, limits, and fail-closed tests.
2. CAGE PR: construct the real envelope and immutable evidence snapshot, call the authenticated sidecar, preserve the complete receipt, release only the returned verified bytes, and route REVIEW/BLOCKED correctly.

Each repository will receive a separate reviewed PR. The public 1-alpha response envelope remains unchanged.

Explicit non-goals

This phase will not:

• reinterpret the response envelope as arbitrary action authorization;
• expose a public anonymous verification API;
• give Agent Integrity broad CAGE filesystem, database, shell, or cloud access;
• claim evidence completeness, objective truth, legal correctness, production reliability, or commercial validation;
• use the current mock receipt as production cryptographic evidence.

[SimranPabla]

Architecture review draft is now open:

SimranPabla/agent-integrity#11

@lahlfors, this is a docs-only Draft PR in Agent Integrity because Agent Integrity owns the sidecar, receipt signing, replay storage, recovery, and exact-byte release behavior.

The PR contains:

• the private verified-release sidecar architecture;
• the reviewed 11-task implementation plan;
• the CAGE Provider 06 ownership and integration contract;
• a direct mapping of the five requested CAGE boundaries: fail-closed ConsequenceGateway routing, Provider 06 isolation, out-of-band kid trust anchors, durable REVIEW/BLOCKED evidence, and exact-byte release.

It contains no runtime code or public schema changes. Agent Integrity implementation remains paused pending architecture feedback.

After the cross-project boundary is agreed, Agent Integrity runtime work and the later CAGE Provider 06 adapter work will remain separate PRs in their owning repositories.