AIUC-1 Q2 2026: Why agent trust is shifting to MCP, A2A, identity, and third-party monitoring
AIUC-1's Apr 15, 2026 update said 14 requirements and 23 controls were updated or added. The plain-English message is that agent assurance is getting more protocol-aware: approved interfaces, verified identities, logged actions, and monitored third parties now matter more in buyer review.
Protocol-aware agent assurance
What changed in plain English
AIUC-1's Q2 2026 update pushed agent assurance closer to the protocols and runtime behaviors buyers actually have to approve.
Approved MCP servers and runtime containment
The update says agent connections should stay on approved MCP servers and that MCP execution environments should be contained at runtime. Control examples: B006.1 and B006.3.
Authentication and encrypted transport across AI interfaces
The update extends caller authentication and encrypted transport expectations across model APIs, MCP, and A2A. Control examples: B008.2 and B008.3.
Tool calls need authorization, validation, and logging
Tool-call authorization and input or output validation now apply more directly to MCP tool actions, with logging expectations expanded to include MCP tool metadata. Control examples: D003.1 and D003.3.
Third-party access monitoring is now front and center
AIUC-1 made third-party access monitoring mandatory and kept vendor due diligence in scope, reflecting how MCP servers and third-party agents can appear dynamically at runtime. Requirement example: E009.
Agents need verifiable identities and scoped permissions
The update adds cryptographically verifiable agent identities and permission-ready access architecture, including just-in-time style controls, so access can stay narrow and reviewable. Control examples: A003.3 and A003.4.
MCP is no longer just a developer integration detail
The current MCP authorization spec says HTTP-based transports should use OAuth 2.1, authorization server metadata, PKCE, secure token handling, and HTTPS. That turns MCP review into a real identity, authorization, and transport question instead of a simple feature checklist.
A2A expands the buyer surface from tools to agents talking to agents
Google introduced A2A as an open protocol that complements MCP for multi-agent interoperability. Once agent-to-agent coordination becomes part of the architecture, buyers have to review not just tools and prompts, but also agent identity, delegation, transport, and logging between connected agents.
Why this is now a buyer and procurement issue
Third-party agent and MCP access is becoming a live approval question because the attack surface changes with each new connection.
Connected agents and MCP servers can appear dynamically
That means approval cannot stop at a static vendor questionnaire. Buyers need to know what is actually allowed at runtime.
Checklist-only governance is not enough
Policies still matter, but buyers increasingly ask for technical proof around interfaces, identities, tool-call controls, transport, and monitoring.
Teams need evidence they can export quickly
Security review, procurement, and platform teams need buyer-ready evidence for MCP, A2A, and connected agents without rebuilding the packet each time.
How CraftedTrust maps to the problem
CraftedTrust is the evidence layer that helps teams show both operational governance and technical proof.
Approved interfaces, scans, and public trust
MCP Trust gives buyers a public registry, scan depth, certification state, and linked research so approved interfaces are easier to compare and explain.
Verified organizations, roles, keys, and access boundaries
CraftedTrust Identity supports the identity layer around organizations, roles, keys, and access boundaries that buyers increasingly ask to see.
Evidence, findings, reports, and monitoring
AI Governance and buyer-diligence flows organize findings, evidence gaps, reports, and monitoring notes into a review-ready record.
Policy and regulatory updates that explain why the controls matter
Touchstone research tracks standards, advisories, and regulatory movement so teams can connect technical findings back to buyer and governance expectations.
Approvals, guardrails, and runtime-proof direction
Runtime Gateway and approval-trace work are the direction for cases where point-in-time review is not enough and buyers need stronger runtime proof, guardrails, or action history.