External platform references

External platform references show how a real agent framework or security runtime can carry Ratify authority to an independently controlled receiver. They are executable interoperability profiles, not endorsements, partnerships, or substitutes for the platform’s native identity, isolation, and policy layers.

flowchart LR
    P[Principal] -->|signed, bounded delegation| A[Agent framework]
    A -->|operation + proof| G[Platform transport or runtime]
    G --> R[Independent receiver]
    R -->|verify before action| T[Protected tool]
    R -. deny .-> X[No side effect]

Why a separate authority layer is needed

Workload identity proves which process connected. An agent framework selects and calls tools. A sandbox or gateway restricts what the runtime can reach. Receiver policy decides whether a request is acceptable now.

Ratify supplies the evidence those layers do not: which principal delegated authority to the presenting agent, for which scope and resource, under which signed limits, and whether that authority is fresh and unrevoked. A receiver in another organization can verify the proof before accepting the consequence.

Current profiles

Platform	Native role	Ratify seam	Evidence status
NVIDIA NOOA + OpenShell	Agent middleware plus runtime destination/method/tool isolation	Proof-carrying MCP request; receiver verifies semantic authority after OpenShell admission	Independent draft; hermetic and live OpenShell gates
Google ADK	Agent loop and native MCP toolset	Proof injected after tool selection; independent Streamable HTTP MCP receiver verifies it	Independent draft; deterministic ADK and HTTP MCP gate
LangChain	create_agent loop and MCP tool interceptors	Public interceptor adds a per-call proof; independent Streamable HTTP MCP receiver verifies it	Independent draft; deterministic LangGraph and HTTP MCP gate

Until a profile is merged, its pull request is the source of truth. Draft profiles must say explicitly that the named platform has not reviewed or approved them.

Required repository structure

Use one directory under references/<platform>/ and one authoritative script under scripts/:

references/<platform>/
├── README.md                 # value, architecture, run command, claims, limits
├── DESIGN.md                 # threat boundary and integration decisions, if needed
├── requirements.txt          # or the ecosystem's exact lock/pin file
├── <implementation>/         # presenter, carrier/adapter, receiver
├── tests/                    # positive and adversarial cases
└── evidence/
    └── reference-evidence.md # dated environment and exact recorded result

scripts/<platform>-reference-check.sh

Keep platform-specific code in the profile. Shared protocol behavior belongs in an SDK and its conformance suite, not in a copied helper hidden inside one integration.

README contract

Every reference README must include:

1. Status and non-endorsement. Name the exact platform and say whether its maintainers have reviewed the work.
2. The missing question. Explain why identity, orchestration, transport, sandboxing, and local policy do not themselves prove delegated authority.
3. A visual boundary. Show the principal, presenter, platform seam, independently operated receiver, and protected side effect.
4. One authoritative command. A clean reader must be able to reproduce the claimed result without a paid model or hidden credential.
5. Exact versions and provenance. Pin public dependencies and prove the gate did not accidentally import a local unpublished Ratify SDK.
6. Acceptance matrix. State both the expected decision and whether the protected side effect occurred.
7. Layer separation. Say what the platform provides, what Ratify provides, and what remains receiver policy.
8. Non-claims and production gaps. Cover key custody, trust distribution, durable revocation/challenges, TLS/workload identity, retries, audit storage, rate limits, carrier limits, and any fake protected service.
9. Evidence link. Point to the dated record rather than treating prose as proof.

Minimum security gate

A reference is not merge-ready unless its authoritative gate:

• builds a clean or isolated environment from exact public pins;
• asserts Ratify resolves from the intended published package;
• requires an explicit expected test count;
• fails on skips, xfails, collection errors, missing modules, or retries hidden as success;
• exercises the platform’s real public integration seam, with a deterministic model double when model judgment is irrelevant;
• proves ALLOW reaches the protected handler and every DENY leaves the handler untouched;
• covers expiry, revocation, replay, altered operation, wrong agent, untrusted root, scope/resource/constraint denial, malformed input, and transport denial;
• tests concurrency and bounded receiver state when the profile maintains pending operations; and
• records platform, language, architecture, dependency versions, warnings, and known unexecuted paths.

For any proof carrier, also test missing, duplicated, malformed, and oversized values. Document intermediary limits and secret/log-redaction requirements.

Review and upstreaming

Merge into Ratify when the independent claims are reproducible and accurately bounded; external platform approval is not required for an explicitly labeled independent reference. Keep any proposed upstream adapter or platform-owned namespace in draft until the relevant maintainers agree to that interface.

Ask platform maintainers to review the narrow seam—not to validate the Ratify protocol wholesale. Useful questions are: Is this the supported interception point? Is there a safer standard carrier? Which workload identity should be bound? What version-compatibility contract can the adapter rely on?