6. Implementation and design evolution · Historical project proposal · 1.7-draft
IAP: Understanding the Intelligent Access Protocol Draft
On a narrow screen, scroll each comparison table horizontally. Focus a table region to scroll with the keyboard.
IAP aims to give capability descriptions, verification evidence, and trust assessments a shared data language. It is intended to help people and AI understand a tool's boundaries, applicable conditions, and unresolved questions before using it.
This article introduces the Intelligent Access Protocol (IAP) proposed by the CapaLens project, based on IAP-SPEC-001, version 1.7-draft, dated 2026-10-18. It is currently a project protocol proposal, not a formal standard adopted by an industry standards body, and it is not part of the official MCP standard. The mechanisms described here are draft designs; they do not mean that CapaLens has deployed all the related capabilities.
Why access evidence matters
A tool being discoverable, accepting parameters, and returning a result answers only some of the questions involved in connecting to it. To choose whether to use it, we also need to know what data it reads, whether it changes external state, which version was tested, who reached the conclusions, and whether the evidence still applies.
Consider a hypothetical inventory service. "Query inventory" and "adjust inventory" might appear in the same tool list, yet their permissions, effects, and confirmation requirements differ. A successful test of the query interface cannot simply be applied to an inventory adjustment operation.
IAP seeks to record these differences in information that both people and programs can read. Instead of stopping at "it works," an access assessment can state which capability is supported, under which conditions, and on what evidence.
The draft's four layers
IAP organizes capability descriptions, evidence, signed statements, and governance information separately. The four layers are related, but none can replace another.
| Layer | What it primarily describes | What to examine when using it |
|---|---|---|
| Capability description | Node identity, access type, capability list, inputs, side effects, risks, and confirmation requirements | The specific capability and version covered by the statement, and whether they fit the current task |
| Evidence | Protocol conformance, functional testing, security checks, and proposed tracking of changes over time | Scope, method, environment, time, results, and areas not covered |
| Trust credentials | Verifiable statements an issuer makes about a particular subject and its evidence | Whether the issuer is trusted, the evidence matches, and the credential is valid |
| Governance and audit | Call-chain records and governance support for combined use | Who made a judgment, what it was based on, and how it should be reassessed after changes |
Here, "governance" describes a protocol design direction. It does not mean that an adopter already has a complete enterprise approval, audit, or security system for composed tools. Users and the relevant systems must still implement the specific controls.
What capability manifests and evidence files record
A capability manifest first explains what kind of connection is being described. Version 1.7-draft lists fields such as node identifier, provider type and name, service name, service version, access type, capability list, and update time. It uses JSON Schema 2020-12 to express the structure.
For each capability, the draft proposes recording an identifier, name, description, input structure, side effects, risk level, and whether confirmation is required. For example, side_effects describes the effects of an operation, while requires_confirmation declares its confirmation requirements. These are claims that need verification. Field values alone do not establish that an implementation is read-only, low-risk, or authorized by the user.
Provider categories distinguish businesses, individuals, education, research, healthcare, and other providers. A category label does not establish identity, professional or industry qualifications, or legal status.
An evidence file explains where the assessments come from. The required sections explicitly listed in 1.7-draft are protocol_compliance, functional_test, and security_audit, covering protocol conformance, functional testing, and security auditing respectively. Tracking changes over time is also part of the project design, but the current text does not fully specify the related fields or decision rules.
When reading evidence, consider at least the following information together:
| Verification dimension | Questions it should answer |
|---|---|
| Subject and scope | Which node, version, capability, and permission configuration were checked? What was not covered? |
| Method and conditions | Who performed the checks, how were they performed, and under what environment and data conditions? |
| Results and status | Was the result a pass, a failure, not tested, insufficient evidence, or not applicable? |
| Time and changes | When was the evidence produced? Do subsequent version or permission changes affect the conclusions? |
"Not tested" must not be presented as either "failed" or "passed." One successful call does not establish that the business result is correct. Public evidence should enable verification while respecting authorization and redaction requirements; reproducibility is not a reason to disclose keys, personal information, or restricted business data.
How trust credentials are intended to work
The draft's proposed issuance process calculates a SHA-256 digest of an evidence file. It then organizes the issuer, subject, issuance time, expiration time, evidence digest, trust level, and claims into canonicalized JSON, and signs it with the issuer's private key. The draft recommends Ed25519 as the signature algorithm.
A verifier must recalculate the evidence digest, verify the signature, and check validity and revocation status. The draft also suggests publishing public-key information at /.well-known/iap-jwks.json.
Provided that the association between the public key and the issuer's identity is trustworthy, and that the algorithm and implementation are correct, this process can verify the source of issuance and content integrity. A signature does not automatically establish that a claim is true or guarantee that a tool is safe. The issuer's capabilities, test quality, evidence scope, and actual usage context still need to be assessed separately.
The project memorandum proposes four trust-level labels: untested, basic, verified, and high. It also considers node self-attestation and independent third-party issuance. These labels are not statutory qualifications or security certifications. The current combined text does not fully define the criteria for each level. Test coverage, third-party endorsement, or suitability for a use case therefore cannot be inferred from a label, and readers should not invent thresholds to fill the gaps.
How IAP relates to MCP, APIs, and CLIs
IAP is designed as an independent evidence and governance layer. It does not perform business operations or require every call to pass through a new proxy gateway. MCP, APIs, and CLIs continue to provide their respective access methods; IAP associates the corresponding descriptions and evidence with them.
| Access method | Existing role | Information IAP proposes to add |
|---|---|---|
| MCP | Establish standardized interactions between AI applications and external tools and data | Check records, risk statements, and credential associations for specific tools and versions |
| API | Provide callable service interfaces; OpenAPI can describe HTTP APIs | Whether an interface implementation matches its description, and the evidence for checks in a particular environment |
| CLI | Make software capabilities available through a command line | Execution environment, permissions, side effects, and corresponding test evidence |
MCP already includes requirements concerning user control, data privacy, tool safety, and access control. It should not be understood as providing "calls without security design." The IAP proposal focuses on organizing and exchanging evidence about particular implementations, so the two can complement each other. For MCP's foundational capabilities and security requirements, see the official MCP specification. For the scope of interface descriptions in OpenAPI, see the official OpenAPI specification.
The project proposes two ways to discover evidence: publishing IAP information at paths such as /.well-known/iap.json, or exposing related material through MCP Resources. MCP Resources can provide contextual data to clients, but using them to carry IAP material is an integration approach proposed by this project, not an official MCP-defined IAP feature. See the official MCP Resources documentation.
In this design, a client can first retrieve capabilities and evidence, then decide whether to make a call based on its own policies, task risks, and user authorization. Discovering evidence or validating a credential does not grant permission to execute an operation.
What remains before the draft is a complete implementation specification
Version 1.7-draft proposes data structures, a signature-verification process, test-suite commands, and specialized appendices that can support discussion and implementation design. However, the current combined text still refers to earlier sections and a provider-category list that are not included. It does not provide complete $defs, and it uses example.com as a placeholder Schema identifier. As a result, this text alone is not yet sufficient to serve as a complete, executable conformance standard.
Work still needed includes complete field definitions and constraints, the criteria for each level, a specific JSON canonicalization method, signature and key identification, conventions for querying revocation status, and reproducible tests and cross-implementation validation examples.
The iap-tester commands listed in the draft are interface designs. A command name appearing in the text does not mean that a tester is available to download, can run, and has passed acceptance testing. Likewise, a credential workflow design does not mean that an issuance service is already operating.
CapaLens's role
CapaLens aims to help people and AI choose trustworthy and effective Intelligent Access (IA) capabilities. The IAP proposal provides a shared structure for capability descriptions and evidence exchange. CapaLens plans to use practical evidence-service work to assess whether those structures are clear, verifiable, and useful.
The protocol direction, product plans, and delivered features must be described separately. For each connection, users need capabilities, risks, supporting evidence, and unknowns that match the current version, rather than a decision based only on a "trusted" label.
IAP aims to support access decisions with a defined scope, identified sources, and a basis for reassessment. Whether to adopt a capability ultimately remains a decision for its users, taking into account the actual task, permissions, and boundaries of responsibility.
Project sources and version notes
The description of IAP in this article is based on the CapaLens project document *Intelligent Access Protocol Standard* (IAP-SPEC-001, 1.7-draft, 2026-10-18) and the project memorandum on the relationship between IAP and MCP dated the same day. These materials describe a project proposal. They do not establish recognition by an external standards body, real deployment cases, or completed product acceptance. Specific implementations and subsequent revisions should be assessed against the formally published versions and their acceptance results.
This article is an overview of the project proposal, not a download of the complete specification. The material reviewed here does not establish a public redistribution license for the full specification. Refer to the project's formally published text and license before quoting, redistributing or implementing it.