MCP and Trusted Agents

Review status: This foundation page requires specialist review before public approval. Its claims must remain within the scope stated here.

The Model Context Protocol, or MCP, provides a standardized connection between AI applications and external resources, prompts, and tools. It defines how a host, client, and server negotiate capabilities and exchange structured messages.

In UbID, MCP is an integration protocol for governed software assistance. It is not an identity credential standard, a trust decision engine, or authority for an AI model to issue credentials, recover identities, use institutional keys, or change production systems autonomously.

MCP roles

Role	Responsibility
Host	The user-facing AI application that manages interaction, consent, and policy.
Client	The connector inside the host that communicates with one MCP server.
Server	The service that exposes approved resources, prompts, or tools.
Domain service	The authoritative UbID service that validates and performs a permitted identity operation.
Human or policy approver	The accountable actor or rule that authorizes a sensitive transition.

The model can interpret and propose. Authoritative services and deterministic policy remain responsible for execution.

Resources, prompts, and tools

Resources

Resources provide structured context, often through URIs. UbID can use read-only resources to expose approved information such as public architecture capabilities, issuer status, credential types, protocol support, or operational summaries.

A resource URI does not grant unrestricted database access. The server applies authorization, minimisation, filtering, and evidence rules before returning content.

Prompts

Prompts can provide controlled templates for recurring workflows. They should be treated as versioned assistance, not policy or executable authority.

Tools

Tools expose operations with defined inputs and outputs. Tool descriptions are not proof that a tool is safe, and input validation cannot be delegated to an LLM. Sensitive tools require explicit scopes, deterministic validation, approval gates, idempotency, bounded effects, and auditable execution.

The UbID control pattern

Sensitive operations follow a staged pattern:

1. Discover — identify approved resources and capabilities.
2. Prepare — assemble a proposed request without executing it.
3. Validate — apply schema, identity, policy, status, and risk checks deterministically.
4. Approve — obtain human authorization or an explicit pre-approved policy decision.
5. Execute — invoke the authoritative domain service with bounded credentials.
6. Evidence — record the request, checks, authorization, outcome, and references without secret material.

Preparation and validation can be automated extensively. Approval and execution remain constrained according to impact.

Read-only first

The initial UbID MCP posture prioritizes read-only resources and diagnostic tools. Read-only does not mean risk-free: operational data, identity metadata, credential schemas, and alerts can still be sensitive or enable reconnaissance.

Servers should therefore apply least privilege, purpose limitation, tenant isolation, rate limits, output filtering, and clear user consent.

Security and trust boundaries

MCP implementations should account for:

• prompt injection from untrusted resource content;
• malicious or misleading tool descriptions;
• confused-deputy behavior;
• excessive scopes and long-lived credentials;
• cross-tenant data exposure;
• tool chaining that creates an unintended high-impact action;
• data exfiltration through model output or sampling;
• replay, duplicate execution, and partial failure;
• unauthorized server substitution;
• version drift and capability changes.

Tool output is evidence to be evaluated, not a reason to bypass normal authorization.

Identity and authorization

MCP transport authorization controls access to the server. UbID still requires identity-aware authorization at the resource or tool level. The server should know which principal, tenant, purpose, and scope apply to each request.

The AI model must not receive raw private keys, KMS root authority, recovery shares, unrestricted database credentials, or direct shell access.

Evidence-grounded assistance

A trustworthy assistant should distinguish:

• observed facts returned by authoritative resources;
• deterministic validation results;
• policy decisions;
• model-generated interpretation;
• uncertainty and missing evidence;
• actions actually executed.

This separation prevents fluent text from being mistaken for an authoritative platform state.

UbID position

MCP read-only discovery and operational assistance form part of the implemented UbID reference baseline, with controlled expansion planned for additional tools. Sensitive identity actions remain subject to domain authorization, explicit policy, approval, and evidence.

Because MCP is versioned and continues to evolve, UbID integrations should pin a reviewed protocol version and capability set rather than assume compatibility with every draft or extension.

Public documentation boundary

This page does not publish internal resource inventories, tool schemas, prompts, tokens, scopes, operational endpoints, alert contents, system instructions, guardrail thresholds, execution credentials, or production approval rules.

Source standard

• Model Context Protocol specification

See Trusted Digital Agents and UbID Sentinel AI.