PIC Standard -- fail-closed action security layer for agent tool calls

[madeinplutofabio]

Hello AGNTCY community,

I would like to propose PIC Standard for consideration in the Identity working group.

WHAT IT ADDRESSES
The Causal Gap: agents executing high-impact tool calls (payments, data deletion, PII exports) based on untrusted or injected data, with no pre-execution verification that the action is causally justified.

HOW PIC WORKS
Agent generates an Action Proposal JSON before any tool call.
Fail-closed verifier checks schema, causal taint, tool binding, evidence.
High-impact actions require trusted evidence (Ed25519 signatures).
Every decision produces a structured audit record.

IDENTITY WG RELEVANCE
PIC’s Ed25519 keyring with expiry and revocation lifecycle manages signer identity for evidence verification. Provenance tracking classifies data sources by trust level. Both align with the Identity WG scope.

CURRENT STATUS
Apache 2.0, on PyPI
pip install "pic-standard[mcp]" or "pic-standard[langgraph]"
Integrations: LangGraph, MCP, OpenClaw (TS), HTTP bridge
RFC-0001: github.com/madeinplutofabio/pic-standard
Github: https://github.com/madeinplutofabio/pic-standard

-- Fabio Marcello Salvadori,

[0xbrainkid]

The PIC Standard addresses a critical gap — fail-closed verification before high-impact tool calls. The causal justification requirement ("why is this action happening?") is much stronger than simple permission checks.

The Ed25519 keyring with expiry/revocation lifecycle aligns well with what we see converging across the agent identity space:

• MCP core repo is actively discussing agent identity for tool calls (discussion #2404)
• OpenAPI 3.3 is considering an agentAuth security scheme (OAI #5267)
• IETF has three Internet-Drafts on agent trust frameworks (draft-sharif-agent-payment-trust)

One question: PIC verifies that an action is causally justified within a system, but how does the verifier establish trust in the originating agent when it crosses organizational boundaries? If Agent A from Org 1 generates an Action Proposal that references evidence signed by Agent B from Org 2, the verifier needs a way to resolve Agent B's identity without a shared directory.

This is where on-chain identity (like SATP) could complement PIC: the Ed25519 public key in the Action Proposal maps to a verifiable on-chain identity with a trust score, giving the verifier an external trust signal alongside the causal chain.

Would PIC consider supporting pluggable identity resolvers? The keyring management you describe is solid for intra-org, but cross-org evidence verification is where the hard problems live.

[madeinplutofabio]

Thanks for the thoughtful engagement. You have landed on exactly the integration point that PIC v0.7.0 introduced.

PIC’s trust-resolution hook for this is the KeyResolver protocol. Rather than hardcoding file-based keyring lookups, PIC exposes a KeyResolver interface that the caller injects at verification time.

That means:

• within a single organization, keys come from a local keyring you control
• across organizations, any external identity service can act as the resolver: a shared registry, a certificate authority, or whatever the AGNTCY Identity WG defines
• in testing, you swap in a lightweight resolver without touching the verifier

The verifier stays agnostic to where the trust material comes from. It requires that the resolved public key be active and successfully verify the Ed25519 signature on the evidence. Trust policy (for example, what evidence is sufficient for a given impact class) remains separate from key resolution.

So my view is:

PIC already provides the extension point for pluggable trust resolution.
The open standards question is what shared federation / resolver-metadata profile cross-org deployments should use for discovering and validating trust material across organizational boundaries.

That’s exactly why I’m raising this here rather than treating it as a contained PIC-only concern.

Happy to walk through the KeyResolver API or the evidence verification flow in more detail if useful for the WG.