Add Agent Registry grant stub for AgentPod activation

[mdheller]

Context

Agent Machine must not expose sensitive context, tools, model providers, cache, memory, or storage to a non-human runtime participant without resolving an Agent Registry grant.

Required outcome

Define an Agent Registry grant stub for AgentPod activation.

Acceptance criteria

• Add a documented grant request/response shape.
• Grant request includes AgentPod ID, requested agent identity, session identity, workroom/topic refs, requested provider/model scope, requested tool scope, cache/memory scope, storage/evidence scope, and expiration request.
• Grant response includes grant reference, grant digest, allowed scopes, denied scopes, expiration, revocation status, and revocation hook reference.
• Activation semantics state: if agentRegistryRequired=true and no grant exists, activation fails closed.
• No secret values, raw prompts, raw KV-cache contents, or private memory contents are included in grant payloads.

Related docs

• docs/architecture/world-class-release-gate.md
• docs/architecture/receipt-chain.md

[alex-pathcourse]

Resolving an Agent Registry grant before exposing tools, model providers, or storage to a non-human runtime participant is exactly the trust boundary you're drawing here. PCH's identity module handles agent verification and cert-tier trust checks so you don't have to build or maintain the grant resolution layer yourself.

Working example: https://github.com/pathcourse-health/pch-integration-examples#2-identity--reputation--path-score--erc-8004

[mdheller]

Thanks for the pointer. I agree with the boundary: Agent Machine activation must fail closed unless an Agent Registry grant resolves before any tools, model providers, cache/memory, storage, or evidence scopes are exposed to a non-human runtime participant.

For SourceOS, though, this should remain a local, auditable, pluggable trust-plane contract rather than a hard dependency on an external managed identity/payment gateway. We can use ERC-8004-style identity/reputation/validation concepts as an optional adapter pattern, but the Agent Registry grant stub should stay provider-neutral and self-hostable by default.

Concrete implication for this issue:

• Keep the required grant request/response shape in Agent Machine.
• Treat external cert-tier/path-score systems as optional verifier inputs, not as the canonical grant authority.
• Require signed receipts/provenance for any external trust signal used in the grant decision.
• Preserve fail-closed activation semantics when agentRegistryRequired=true and no valid local grant exists.
• Do not leak secrets, raw prompts, KV-cache contents, or private memory into identity/reputation payloads.

So this is useful prior art for an adapter, but not something we should bind the core activation path to.