IAP: Designing an Evidence Format for Intelligent Access

Status: this is the current design discussion for internal evidence and test-proof format 0.1, not a formal public specification. The early 1.7-draft is retained separately; the two documents must not be merged into one adopted standard.

Earlier articles covered the landscape, the Intelligent Access (IA) concept and the early IAP draft. This part is about evidence: when a person or an AI is about to connect to a tool, what format should "here is what this IA endpoint looks like right now, and here is the proof" take? We call that format Intelligent Access Protocol (IAP).

One thing up front. IAP began as a much larger idea — an "Intelligent Access Protocol standard." After several rounds of internal review we narrowed it to "a format for evidence and test proofs about one IA endpoint," and decided to use it inside CapaLens first and only consider publishing it after accumulating more than 100 real test records. This article explains the design and the trade-offs. It is not a public specification.

1. Where the gap is: four links in the security chain

To see where IAP fits, follow an IA endpoint from publication to invocation and count the security checkpoints:

• Identity — who published it. Registries handle this link, but they verify namespace ownership, not content.
• Definition — what the tool actually does, what permissions it needs, how this version differs from the last.
• Runtime — permissions and isolation at call time. Gateways, clients and security vendors handle this.
• Audit — accountability after the fact. Enterprise logging handles this.

We see incomplete evidence around tool definitions, permission scope and version changes. Definition hashes, publisher attribution and least-privilege review can be useful inputs, but their coverage and standards status must be checked for the specific implementation. This article does not claim the area is empty or that all registries and gateways behave alike.

IAP is built for that link. It is not another calling protocol; it does not replace MCP or the registry. It is a uniform format for evidence about one IA endpoint: version, conditions, permissions, test results, check date, evidence source. The registry answers "what exists." IAP answers "can it be relied on." A complement, not a competitor.

2. What one evidence record looks like

A guiding principle is that the planned probe report should itself become the evidence record, reducing translation and field drift. The internal format 0.1 is a design proposal; its key choices are described below.

The key design choices:

Applicable version plus check date. Evidence holds only for this version on this date. The design goal is to mark old evidence "re-test pending" when versions or permissions change, display freshness, and optionally apply a validity window such as 90 days. Automated behavior depends on the delivered implementation.

Evidence levels are labeled separately, never blended. Machine checks, human confirmation and AI self-reports are three different grades of trustworthiness. A card may show all three, but each is labeled; there is no composite score.

Three-state conditions: met / unmet / unknown. Unknown is written as unknown — no guessing, no defaults. A missing field is always "unknown." Each condition points to an evidence id that resolves to raw exchanges.

Definition and attribution fields. Action level (read / write / execute / orchestrate), publisher identity (official / vendor-hosted / community / bulk publisher), and a tool-definition hash. The hash covers name, description, input and output schema and annotations together — because the classic rug pull changes the description or annotations and leaves the schema alone. A changed hash is intended to trigger review or an alert; the hash does not determine whether a change is malicious.

Raw, replayable reports. The goal is to publish authorized, shareable and redacted requests and responses with each report so others can repeat the check. Thirty minutes is a design target, not a verified guarantee; restricted data must not be exposed. That is how "the claim equals the test" becomes an engineering property rather than a promise.

3. How evidence is produced: a four-rung ladder

The project proposes separate labels for self-declared, documentation-reviewed, machine-checked and human-reviewed observations. These labels describe methods, not a universal scale: each needs its object, version, environment, scope and result. Human review of identity or documentation is not automatically an end-to-end business test.

A label should cover only the check actually recorded. "The vendor documented it" is not "we tested it," and live business calls need separate evidence. The preparation snapshot contains many unreviewed Registry listings and unreviewed supplementary information; it would be incorrect to describe the whole directory as documentation-reviewed. Machine and human validation are development directions. This article does not establish that a framework was accepted, a real-data pilot began, or validation reached production scale.

The proposed lightest layer is a bounded liveness check: endpoint reachability, protocol response, capability discovery and recorded authorization behavior. A budget such as five requests and ten seconds would be a proposed test configuration, not a demonstrated capacity or a security verdict. A failed request may reflect permissions, environment or a temporary outage. Deeper conformance, functional and security-definition checks require their own authorization, method and evidence; disagreements with official suites should be retained for review rather than silently resolved.

Language models flag suspicions; they never conclude. Possible poisoning in a tool description, gaps between documentation and behavior — a rule vocabulary plus a model produce candidates, and a person decides. Only reproduced and confirmed findings count.

4. Baking the check into every call

Evidence is only useful if it reaches the moment of use. Our long-term goal is to make "check the evidence once" a built-in step of every AI call to an IA endpoint.

The governing principle is that calls should not pass through CapaLens; clients may consult evidence beside the call path. Avoiding a business-call proxy reduces that dependency and avoids vendor credential custody, but does not eliminate system failures or security risks.

Four proposed routes, none activated by publishing this article:

1. Offline-verifiable signed proofs — issued per IA endpoint and per version, bound to the tested version and definition hash, with signatures verifiable locally. Fresh revocation status still depends on status-list timestamps, cache validity and any necessary online refresh.
2. Embedded in the toolchain — agent frameworks, SDKs and MCP client plugins check before connecting by default; when a proof is missing or the version does not match, the user is warned and keeps the decision.
3. Written into specifications — pushing registries and standards to add trust-and-evidence fields.
4. Into enterprise policy — helping organizations write "no unverified IA capabilities" into their AI governance rules.

On cryptography, the review's advice was not to invent: consider RFC 8785 (JCS) for JSON canonicalization and W3C Verifiable Credentials 2.0 with status lists for credential and revocation design. JCS is not a signature algorithm; proof formats, key distribution, status refresh and interoperability tests need separate definitions.

5. What we dropped, and why

An honest design note should show the trade-offs. Our own review struck a fair amount from the early IAP draft:

Vulnerability information disclosure must follow applicable rules, including China's Provisions on the Management of Security Vulnerabilities in Network Products where applicable. Public status, affected versions and details all require review; omitting technical details does not by itself establish compliance. Timing and recipients depend on vendor response and applicable requirements.

6. The road

The current design goal is to use the probe engine's evidence.json as IAP internal format 0.1 and align it with the v0.5.0 field standard. Completion and coverage must be established by implementation and test records. Next: accumulate more than 100 real records that are machine-checked and human-confirmed. Only then a public draft, aligned with the official registry and existing standards — not a rival camp.

A standard's value is not in who writes it first, but in how many real records are produced in it and how many platforms choose to cite it. So IAP's path is records before format, filling the gap before claiming a standard.

---

Based on the team's internal reviews and memos (October 2026). The format shown is an internal draft; field names may change; nothing here is a public specification or a commitment.