Five different states that are too often conflated
A tool catalog answers what functions exist. A credential or a connected server says which interface can be reached. Neither tells us whether an agent should be allowed to use the interface in the current workflow. This article focuses on L5 Capability & Integration, with two interfaces: L6 Security, Identity & Governance for authorization and L7 Evaluation & Observability for evidence of actual effects.
- Discovery: the client learns that a tool exists and reads its declared input and output contracts.
- Possession: a client can address the endpoint or holds a credential. This is connectivity, not approval.
- Eligibility: policy determines whether this version of the capability is approved for this workflow, environment and data class.
- Invocation: a concrete request is prepared with arguments, target resource and anticipated side effects.
- Authority: the trusted service independently evaluates whether that exact operation is allowed now, and records the decision and observed outcome.
The distinction is especially important for agentic workflows: a model can propose an action, but its proposal must not be the source of its own permission. Descriptions, skill files, search results and tool responses are lower-trust inputs. They can inform routing but cannot grant roles or override policy.
A capability contract is not an access token
For each reusable integration, record a stable capability identifier, provider and version, input/output schema, data classifications, permitted side effects, required identity and scopes, expected destinations, budget limits, failure behavior, revocation path and provenance of qualification. Publish only the information needed for discovery. Keep internal policy logic, credentials and private catalog content behind the service boundary.
A capability should have a lifecycle: proposed, inspected, qualified for a specific context, admitted, monitored, suspended and retired. Promotion of a capability version does not automatically extend the authority of existing users or agents. Likewise, revoking access must be enforced at the resource or broker, not only by removing the tool name from a prompt.
One concrete example: a customer support refund tool
A support assistant discovers a refund_order tool and can produce schema-valid arguments. The current task, however, concerns an order in another tenant and exceeds the delegated refund limit. The integration may be healthy and the request well formed, yet the operation must be denied. The policy decision must bind the authenticated requester, delegated agent, order owner, amount, currency, workflow purpose, current approval and expiry. A successful response from the model is not evidence that the refund happened.
For a read-only order lookup, the same capability family may have a different decision path. This is not a reason to make the whole server trusted: authorization follows the specific action and resource. When approval is needed, capture its scope and expiry; a later argument change requires reevaluation.
Where the protocol boundary sits
The Model Context Protocol tools specification describes how servers expose tools and clients call them, including declared schemas. It does not make tool discovery equivalent to user authorization. The MCP authorization specification addresses authorization for protected HTTP resources, including resource indicators and token validation; application-level decisions for particular tool effects remain necessary.
OWASP's Excessive Agency risk describes how excessive functionality, permissions and autonomy can enable unintended actions. NIST SP 800-207 provides a zero-trust rationale for evaluating access rather than relying on network location or possession alone. Neither source specifies the five-state L5 model proposed here.
Architecture invariant and evidence
Invariant: tool visible ≠ tool qualified ≠ invocation authorized ≠ effect verified. Keep an auditable chain from capability version and signed principal to proposed invocation, policy decision, resource-side enforcement, tool result and independently observed side effect. Do not treat a tool's success message as sufficient effect evidence.
Evaluation should include a hidden-but-callable tool, expired delegated authority, cross-tenant object IDs, a tool description containing malicious instructions, a substituted server, changed arguments after approval, and a tool reporting success without any resource change. Report test denominators, denials, and mismatches between reported and observed effects.
Source, claim and limitation ledger
- MCP tools: primary protocol documentation supports discovery and invocation contracts; it does not certify any particular server as safe or approved.
- MCP authorization: primary specification supports resource-server token boundaries; it does not replace business-specific authorization for each operation.
- OWASP Excessive Agency: security guidance supports reducing unnecessary functions and authority; it is not evidence that the proposed control sequence is implemented.
- NIST SP 800-207: zero-trust principles inform the design; they are not a certification or endorsement of this architecture.
Actual Harness change: this publication introduces an L5 architecture explanation and a proposed capability-to-effect evidence contract. It does not assert a new Harness Collection release, a deployed MCP authorization service or production adoption of these controls.
Open questions: who signs capability manifests; how are version changes detected before invocation; which resource-side effects require fresh approval; and how will revocation propagate across cached clients and long-running workflows?
Next: the L5 applied article will examine admission, MCP integration and governed invocation. For context, see Skills Replace Prompts and Memory Admission.
Privacy Notice: With your consent, this website uses Google Analytics to understand aggregate visits and content usage. Analytics is optional and is not used for advertising or cross-site profiling. Some content and images may be generated or modified with the assistance of AI; every AI-assisted item is reviewed and manually edited by a human before publication. Full Privacy Policy ·