Designing Intelligent Access: Definition, Taxonomy and Risk

Scope: this article retains its October 2026 viewpoint and release context. Design goals, plans, examples and delivered capabilities are distinct; availability depends on the release in use.

The worldview and introductory articles described the world we think is coming and the basic Intelligent Access (IA) concept. This part is about something more basic: what Intelligent Access means, how to classify it, how to count it, and how to read its risk. These are not word games. They decide whether a catalog can scale, what belongs on a card, and whether two records can be compared at all.

These are project definitions for discussion and correction. Listing 100,000–150,000 entries and expanding machine and human review is a long-term aspiration, not the current state, a v0.4.8 / v0.5.0 launch metric, or a delivery promise.

1. Definition: what counts as an IA endpoint

The wording we adopted:

Intelligent Access: an interface or packaged tool that offers programs a stable calling contract, through which an AI can connect to an external system to read or write data, execute operations, or orchestrate other systems. Forms include MCP, API, CLI, SDK, Skills, and forms yet to appear. Listing does not imply testing or any security endorsement.

The boundary begins with the following contract and scope questions:

The first criterion is where the boundary lives: a stable, program-facing contract — documented inputs and outputs, commands, a schema or a protocol. A web page that an AI drives by clicking through a browser does not count; an interface with OpenAPI docs does. Without this line, nearly all software would qualify.

Two groups get special handling. Edge cases are included but flagged: UI automation (browser, desktop RPA), aggregation gateways, and device control — usable, but with unstable contracts or unusual risk shapes. Excluded: GUI-only software; the AI's own abilities (screen control, built-in search); static datasets and tutorials; and descriptor files such as OpenAPI specs, llms.txt and A2A agent cards — these are not counted on their own but attached to the matching record as evidence of discoverability.

One companion rule: "Intelligent Access" is a neutral umbrella term. It implies no testing and no security endorsement. Safety and reliability are evidence dimensions, not part of the definition.

2. How it differs from a classic interface

Technically, not at all — the same HTTP requests, command lines and function calls. What changed is the caller: from code an engineer wrote, to an AI that reads, guesses and decides. That produces five traits:

• Discoverable. The AI has to find it — registries, llms.txt, agent cards and package repositories are the paths. An IA endpoint the AI cannot find does not exist for it.
• Self-describing. Name, description and parameter schema decide whether the AI picks it and calls it correctly. A poorly described IA capability is a "bad" IA capability in the AI's eyes.
• Many forms, mutually convertible. The same capability often ships as API, SDK, CLI and MCP at once, and gateways are converting existing APIs to MCP in bulk.
• Action is a risk-screening dimension. Read, write, execute and orchestrate describe effects, not universal safety levels. Data sensitivity, permissions, environment and downstream consequences also matter.
• Maintenance and reachability need evidence. Some entries may have unclear update histories or unreachable endpoints. Their prevalence, causes and affected provider groups require defined samples and dates.

Each trait informs CapaLens's design: helping AI discover, organizing descriptions as structured records, linking forms to products, describing action levels and tracking change. The actual coverage of each capability depends on the released implementation; this list is not a claim that v0.4.8 delivers them all.

3. Three independent dimensions — never mixed

This article covers the first two. Organizing business needs as verb + object, with technical tags as a lower layer, is a product design direction. Actual search behavior depends on the release and recorded mappings; this article does not set a release deadline.

Proposed taxonomy by form

The proposed taxonomy groups AI-native forms; general program interfaces; events and messaging; direct data access; UI automation; and orchestration or physical-world control. This is a project design model, not a claim that every listed form is currently supported or that a category has a fixed safety level.

New forms can be considered during future taxonomy review. Proposed codes such as mcp, web_api and cli are design vocabulary; adopting the full set requires implementation and compatibility evidence. An article alone does not change the catalog schema.

Action and risk

One record can involve several actions; the highest action level is used for initial screening. This is an internal classification rule, not a universal security judgment: reading sensitive data can also be high-risk, and assessment must consider data, permissions, environment and consequences. This dimension feeds directly into the pre-connection "permissions and risk" explanation: what an IA endpoint can read, change, execute or command should be written down before anyone connects, so that people and policy engines can judge.

Note that "what the AI is granted and what data it can reach" is a separate item in our checklist from the IA endpoint's own authentication. The first asks "what of mine can the AI touch"; the second asks "how do you log in."

4. The vendor landscape: three tiers

As an initial prioritization hypothesis, the team may vary review effort by provider context, permissions and impact. Actual evidence, change frequency and task risk should override broad labels: a large provider is not automatically reliable, and a small project is not automatically unmaintained.

Publisher concentration, organization type and adoption across product categories are useful research questions. This article omits the original registry shares and B2B penetration figures because their underlying snapshots, samples and methods have not been verified.

5. Unit of record

With the taxonomy settled, we had to decide how to count. We use three levels of entity:

Vendor → software → IA record. The proposed unit is an implementation under a product with its own identity, calling contract and configuration boundary; form and version are attributes. REST, GraphQL, MCP, CLI and SDK may be separate records when the evidence establishes those boundaries; labels alone do not establish separate units. The preparation snapshot retains a formal catalog of 246 software entries and 363 interface records, 11,382 separately counted Registry listings, and six additional unreviewed local information records. These scopes are not added into a globally deduplicated IA unit count; this article does not recalculate the directory.

The target field design calls for version scope, conditions and evidence status, with missing evidence marked unknown. AI self-reports, documentation checks, machine checks, human checks and user feedback need their own methods and scope; a human identity check is not a business call test. The design does not make those observations interchangeable or collapse them into a single score.

6. Why the definitions matter

Definitions look dry, but they decide three things:

1. Whether it can scale. Listing 100,000–150,000 IA records while progressively expanding machine and human review is a long-term aspiration. It is not the current listing or verification count, a v0.4.8 / v0.5.0 launch metric, or a committed delivery promise. Coverage depends on per-entry evidence and available capacity. The field standard has to be standardized, extensible and accurate from day one, or every addition becomes rework.
2. Whether it can be compared. Only with one set of fields, one three-state scheme and one evidence ladder can two IA capabilities sit side by side without an AI mixing them up.
3. Whether it can be honest. Listing and testing are counted separately; "the vendor documented it" and "we tested it" are labeled separately; unknown is written as unknown. These are constraints at the definition level, not an attitude added later.

The next two articles preserve the early IAP 1.7-draft proposal and the current, narrower internal evidence-format discussion separately. Neither is an adopted formal standard.

---

Definitions from the team's internal October 2026 design memo. Unverified public-census figures have been omitted; the classification and review priorities remain proposals.