An Intelligent World: Humans Use AI, AI Uses Intelligent Access

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.

AI is moving from talking to doing. It looks up orders, opens tickets, makes payments, deploys code, and directs other programs. To do any of that, it has to connect to the outside world — to software, services and devices. We call those connections Intelligent Access (IA).

This article lays out a basic belief: humans use AI, and AI uses IA. It is an author viewpoint about a possible direction, not a measured market forecast or a delivery timetable. Model capability and IA maturity should each be evaluated with specific evidence.

1. A new chain of delegation

Software interfaces used to be called by code that engineers wrote by hand. Code does only what it was told. Now the caller is an AI. It reads a tool's description, it can be swayed by text, and it decides for itself what to call. The result is a new chain of delegation:

People delegate a need to an AI; the AI delegates an action to an IA endpoint; the IA endpoint acts on real software, data and devices. Every added link takes a little control away from the person at the start of the chain.

The weak link is in the middle. An AI usually knows only what is already at hand — the handful of tools connected to it — and fills the rest from training data that may be stale or from an ad-hoc web search. It picks tools by "what do I have" rather than "what fits, and why should I trust it." The trust chain breaks there.

People need three things from that chain: to know what the AI used, to judge whether it deserved the trust, and to keep the final decision. That is what we mean by a trust layer. CapaLens wants to be the mirror between people and AI — so people can see what the AI chooses, and the AI can choose better.

2. What is happening on the IA side

Public directories continue to grow, but their objects, samples, dates and deduplication rules differ. Directory records must not be treated as a count of independent, reachable and verified IA capabilities. This article therefore omits the original industry totals and growth percentages rather than presenting unverified estimates as facts.

CapaLens focuses on making sources, versions, conditions and evidence states reviewable. Any future industry-wide count needs a stated sample, date, unit, deduplication method and primary source.

Potential growth drivers include adapters for existing APIs, agent features in enterprise software, agent cards, and small software services. Their effect on the number of distinct IA capabilities remains a research question; this article does not publish a numerical forecast.

Public catalogs may contain version duplicates, unclear maintenance states, bulk-published entries and unreachable endpoints. Private IA inventories add another counting scope. The prevalence of these issues must be measured against explicit samples and dates; an old update date is not proof of abandonment, and one failed connection is not proof of permanent failure.

Where do IA capabilities come from? Five kinds of publishers, with very different motives and reliability:

Vendor-maintained, gateway-produced, community-maintained, platform-curated and agent-published entries can have different evidence and maintenance practices. Source identity is useful context, but none of these labels establishes reliability by itself. Each implementation still needs its own scope, version and evidence review.

Hardware, government services, finance, payments and enterprise systems are potential IA domains. Their risk depends on data, permissions, deployment and consequences; read access to sensitive data may be high-risk too.

3. Three stages

The following three stages are an author scenario for discussion, not measured milestones or promised dates.

Connectivity: can it be called? Protocol support, adapters and discoverability may broaden access. Client compatibility, authorization and uneven implementation quality still have to be checked in the environment actually used.

Trust: should it be called? Version-bound records, definition hashes and identity evidence could help clients judge IA capabilities before connecting. Enterprise inventory and governance are possible development directions, not proof of widespread adoption.

Autonomy: who is accountable? More agent-to-agent interactions, payments and device operations would increase the need for explicit authorization, execution scope and audit responsibility. The extent and timing of that development remain uncertain.

Certificates and software signatures offer useful analogies for evidence checks, while solving different problems. We see a need for more continuous, cross-platform IA evidence; this is not a claim that no other work exists.

4. Why the security problem is different

Security is where IA capabilities differ most from classic APIs. A classic API's attack surface is code. An IA endpoint's caller is a model that reads tool descriptions and can be talked into things — the attack surface now includes natural language.

Authentication mechanisms vary. Each entry needs its protocol, identity, permissions and deployment conditions checked; absence of OAuth alone does not establish absent authentication or insecurity. Reports about implementation vulnerabilities and exposed services need their original affected-version lists, dates, samples and methods before their figures can be repeated. This article omits those unverified figures and does not attribute implementation defects to inevitable protocol insecurity.

Risks may include malicious tool-description instructions, definitions changed after review, descriptions influencing the use of other tools, and unregistered server connections. Traditional code scanning may not cover every natural-language or runtime risk; a one-time review also cannot establish future behavior.

Changes such as new versions, widened permissions, maintainer turnover or package compromise are reasons to revisit prior evidence. They do not establish the relative prevalence of malicious and accidental failures.

5. What we conclude

From this picture we draw four conclusions, and they set CapaLens's course:

1. Breadth first. Make different forms discoverable while labeling evidence and unknowns. Human review priorities are an initial hypothesis to be adjusted using actual evidence, permissions, risk and observed change frequency.
2. De-noising is a proposed value. Deduplication, maintenance-state review and transparent handling of bulk publishing should make a directory easier to interpret.
3. Enterprise inventories are a hypothesis to validate. Team governance may be useful, but market size and willingness to pay need real user evidence.
4. The long-term goal: help people and AI check relevant evidence before connecting, while preserving their authorization and final decision.

Our viewpoint is that IA evidence remains uneven and changes over time. CapaLens aims to contribute reviewable records across platforms, alongside other work. The value of that contribution must be demonstrated by the records, not by a claim of market uniqueness.

---

Continue with the introduction to Intelligent Access, then CapaLens's positioning and usage, followed by the IA endpoint and evidence-format design articles.

Source scope: this is the team's October 2026 viewpoint. The original manuscript cited public directories, censuses and forecasts without enough primary-source detail to verify its numerical assertions; those figures have been omitted here.