Governing MCP Tool Delegation and Agent-to-Agent Trust with Cryptographic Evidence

1. The Runtime Delegation Problem

Every agent orchestration system must answer three questions at runtime:

1. Is this caller trusted? The agent requesting tool execution must present verifiable evidence of its compliance posture before execution proceeds.
2. What scope is authorized? The delegation grant must bound what the downstream agent can do, how deep it can re-delegate, and when its authority expires.
3. How do I prove the boundary held? After execution, the evidence chain must demonstrate that the scope was not exceeded and the containment boundary was enforced.

Discovery is solved. A2A Agent Cards (.well-known/agent.json) enable agents to find each other and advertise capabilities. Audit trails are solved. SWT3 witness anchors produce immutable, independently verifiable evidence of every governance-relevant event.

The gap is the runtime decision point: should this tool call proceed, and who is accountable if it should not have? This gap sits between discovery and audit. It is where compliance failures occur in production multi-agent systems -- not because agents lack capabilities, but because the delegation decision was never witnessed and the scope boundary was never attested.

The delegation problem is not limited to cloud-to-cloud agent communication. On-device orchestrators that delegate to cloud-hosted agents face the same trust boundary challenge, often with additional constraints: the device cannot expose user context to the cloud agent, the cloud agent operates under a different tenant's governance policy, and the delegation must traverse a network boundary where latency and connectivity are not guaranteed. The fiduciary handoff model described in Section 2 applies equally to device-to-cloud, cloud-to-cloud, and cloud-to-edge delegation patterns.

2. The Fiduciary Handoff Model

The SWT3 delegation loop is a seven-step sequence. Each step maps to a specific procedure. Each procedure produces independently verifiable evidence. No step is optional when the trust mesh operates in strict mode.

The loop is the product. Each step mints one or more SWT3 witness anchors. The full chain -- from discovery through execution to chain verification -- produces a minimum of seven anchors for a single delegated tool call. For transitive chains (A to B to C), each additional hop adds four anchors (steps 3-6 repeat at each boundary).

3. MCP Middleware Integration

The @tenova/swt3-mcp server intercepts tools/call requests and enforces the delegation loop at the transport layer. The SDK provides both caller-side (minting delegation grants) and server-side (verifying trust and executing within boundaries) integration points.

Python -- Caller Side (Minting Delegation + Calling Tool)

from swt3_ai import Witness

w = Witness(
    tenant="ACME_CORP",
    api_key="axm_...",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Step 4: Mint delegation grant before calling external tool
w.witness_delegation_tree(
    delegator_id="planning-agent",
    scope="read-only",
    delegation_depth=1,
    delegates=["data-retrieval-agent"]
)

# Step 5: Call the MCP tool (AI-TOOL.1 fires automatically via wrap_tool)
@w.wrap_tool(tool_name="search_database")
def search_db(query: str, limit: int = 10):
    return mcp_client.call_tool("search_database", {"query": query, "limit": limit})

results = search_db("quarterly revenue")
w.flush()

The wrap_tool decorator intercepts the function call and mints an AI-TOOL.1 anchor containing the tool_name_hash and args_hash. The delegation grant (AI-DEL.1) was minted before the tool call, establishing the scope boundary in the evidence chain.

TypeScript -- Server Side (Verifying Trust + Executing)

import { Witness } from "@tenova/swt3-ai";

const w = new Witness({
  tenant: "PARTNER_ORG",
  apiKey: "axm_...",
  endpoint: "https://sovereign.tenova.io/api/v1/witness"
});

// Step 3: Verify caller trust before executing tool
const trust = w.witnessVerifyAgentTrust({
  counterpartAgentId: "planning-agent",
  trustLevel: 2,
  checksPassed: 4,
  checksTotal: 5
});

// Step 5: Execute tool within delegation boundary
const tool = w.wrapTool(searchDatabase, "search_database");
const results = await tool("quarterly revenue");

// Step 6: Return execution receipt
w.witnessA2ATaskLifecycle({ stateCode: 3, latencyMs: 142, depth: 1 });
await w.flush();

The server-side witness verifies the caller's trust credential (AI-TRUST.1), executes the tool within the delegation boundary (AI-TOOL.1), and returns an execution receipt (AI-A2A.1). Three anchors minted at the server boundary alone.

4. Trust Mesh Verification (Pre-Delegation Gate)

Before any tool executes, the MCP server verifies the caller. The @tenova/swt3-mcp server exposes two trust tools:

• present_trust_credential -- read-only, no anchors minted. Returns the agent's current compliance credential for transmission to the counterpart.
• verify_agent_trust -- mints AI-TRUST.1 + AI-TRUST.2 anchors. Evaluates the counterpart's credential against configured policy and ledger state.

Trust Levels

Configuration via .swt3.yaml

trust_mesh:
  mode: strict
  min_trust_level: 2
  require_signature: true
  freshness_window: 3600
  required_procedures: [AI-INF.1, AI-GRD.1]
  trusted_tenants: [PARTNER_A, PARTNER_B]
  deny_agents: [compromised-bot]

Three Enforcement Modes

strict -- the tool call fails. The MCP server returns an error response. No execution occurs. The denial is recorded as an AI-TRUST.1 FAIL anchor. This is the production target for regulated environments.

permissive -- the violation is logged, the tool executes, and the control plane receives an alert. The AI-TRUST.1 anchor records the trust level shortfall. The tool call proceeds because operational continuity takes precedence over enforcement during rollout.

monitor -- log only. No alerts. No enforcement. The trust evaluation still runs and AI-TRUST.1 anchors are still minted, but the result does not affect tool execution. This mode exists for rollout baseline measurement.

Tuning for High-Volume Environments

The freshness_window parameter (default: 3600 seconds) controls how recently the counterpart's credential must have been witnessed to pass verification. In high-volume environments with thousands of agents, a short freshness window increases re-verification overhead. For fleet-scale deployments, consider tiering freshness by trust level: trusted partners at 7200s, verified agents at 3600s, basic agents at 900s. The per_level_freshness configuration in .swt3.yaml supports this pattern.

Zero-Knowledge Verification

The downstream agent verifies the upstream caller's public key against the Axiom ledger without transmitting prompt data, API secrets, or customer content across the boundary. Only the cryptographic credential crosses the wire. The caller presents a fingerprint, a timestamp, and a signature. The verifier checks these against the ledger. No inference payloads, no model outputs, no business data.

This is the key security property for cross-organization agent delegation. Two tenants can establish trust without sharing sensitive operational data. The trust boundary is cryptographic, not contractual.

Replay protection and key rotation: The trust credential includes a timestamp that the verifier checks against the freshness_window. Stale credentials are rejected even if the signature is valid, which prevents replay attacks using captured credentials. Signing keys should be rotated on a schedule defined in the organization's key management policy. When a key is rotated, the old key's signing_keys entry in .swt3.yaml is replaced and the new key is registered via trust_registry.register_signing_key(). Anchors minted with the old key remain verifiable against the ledger; only new trust presentations require the current key.

5. Transitive Delegation Chains (A -> B -> C)

Core principle: scope can only narrow, never widen. Agent B cannot grant Agent C more authority than Agent A granted Agent B. This is enforced structurally through the delegation depth and scope fields in AI-DEL.1 anchors.

AI-DEL.1 (delegation_depth) tracks hops from the root agent. The root orchestrator operates at depth 0. Each delegation increments the depth by 1.

AI-DEL.2 (boundary_action) enforces the maximum depth. When an agent attempts to delegate beyond the authorized depth, the boundary action records whether the attempt was blocked (code 0) or allowed (code 3).

AI-DEL.3 (chain_integrity) detects orphaned hops -- broken chains where an intermediate agent's delegation was revoked but downstream agents continued executing. An orphaned hop count greater than zero indicates a chain integrity failure.

Scope Narrowing Example (Python)

# A delegates to B: read-write, max depth 2
w.witness_delegation_tree(
    delegator_id="orchestrator",
    scope="read-write",
    delegation_depth=1,
    delegates=["planner"]
)

# B delegates to C: scope narrows to read-only
w.witness_delegation_tree(
    delegator_id="planner",
    scope="read-only",
    delegation_depth=2,
    delegates=["retriever"]
)

# C attempts to delegate to D: blocked at boundary
w.witness_delegation_boundary(
    max_depth=2,
    actual_depth=3,
    boundary_action="blocked"
)

# Verify chain integrity
w.witness_delegation_chain(
    chain_length=2,
    orphaned_hops=0,
    chain_status="complete"
)

The evidence chain tells the full story: the orchestrator authorized two hops with read-write scope. The planner narrowed scope to read-only before delegating to the retriever. The retriever attempted to delegate further and was blocked at the boundary. Chain integrity verification confirmed zero orphaned hops.

6. Tool Execution Containment (AI-SHELL.1)

When a sub-agent executes shell commands, Python scripts, or terminal operations, three layers of containment must be verifiable. Tool call witnessing alone is insufficient -- the assessor must also verify that the executing agent was operating within its authorized scope and that a runtime sandbox was enforced.

Layer 1: AI-TOOL.1 (Tool Call Witnessing)

Records what was called and with what arguments. The tool_name_hash and args_hash create a forensic record of the exact invocation. The hash is computed over the tool name and serialized arguments, producing a deterministic fingerprint that can be compared against approved tool registries.

Layer 2: AI-DEL.2 (Delegation Boundary)

Attests that the executing agent was operating within its authorized scope and depth. The boundary action field records whether the execution was within bounds (code 0 = allowed within boundary) or exceeded the authorized scope (code 3 = allowed despite exceeding boundary, which represents an enforcement failure).

Layer 3: AI-SHELL.1 (Runtime Containment Attestation)

Attests that runtime containment was active during execution. This is the procedure that maps to EU AI Act Art. 9(2)(a) and OWASP Agentic MCP-03. The attestation records that the execution environment enforced containment boundaries -- it does not prescribe the specific sandbox implementation. Whether the containment is process isolation, filesystem restrictions, network policies, or managed-service guardrails depends on the deployment architecture.

Applicability note: AI-SHELL.1 applies where the agent or its operator controls the execution environment (self-hosted runtimes, on-premises containers, edge devices). In cloud-managed environments where the execution sandbox is provided by the infrastructure provider (e.g., serverless functions, managed container services), runtime containment may be addressed through provider inheritance rather than direct attestation. The assessor should verify whether containment evidence comes from the agent's own AI-SHELL.1 anchors or from the provider's inherited controls documentation.

Combined Containment Example (Python)

@w.wrap_tool(tool_name="execute_shell")
def run_command(cmd: str, timeout: int = 30):
    # AI-TOOL.1 fires automatically on invocation
    result = subprocess.run(
        cmd, shell=True, timeout=timeout, capture_output=True
    )
    return result.stdout.decode()

# Attest delegation boundary was enforced
w.witness_delegation_boundary(
    max_depth=1,
    actual_depth=1,
    boundary_action="allowed"
)

# Attest runtime containment was active during execution
w.witness_runtime_containment(
    sandbox_type="process-isolation",
    containment_active=True,
    restrictions=["filesystem", "network", "resource-limits"]
)

The three anchors (AI-TOOL.1, AI-DEL.2, AI-SHELL.1) form a containment triangle. Each is independently verifiable. Each answers a different question: what was called (TOOL.1), was the caller authorized (DEL.2), and was the sandbox active (SHELL.1). A missing anchor in any vertex is a containment gap.

7. Active Revocation and Containment

When trust breaks mid-chain, AI-REV.1 revocation propagates through the delegation tree. If Agent A revokes Agent B's delegation, all of B's downstream delegations (to C, D, and beyond) are invalidated when cascade revocation is enabled. The revocation anchor records the fingerprint of the revoked delegation grant and the reason for revocation.

# Revoke a delegation grant
w.revoke(
    fingerprint="a3f8c921e4b7",
    reason="policy_violation"
)

Seven Revocation Reason Codes

Revocation creates an immutable boundary in the evidence chain. Every anchor minted after the revocation timestamp by the revoked agent or its downstream delegates is suspect. The assessor checks for post-revocation activity by querying AI-TOOL.1 and AI-INF.1 anchors from the revoked agent ID after the AI-REV.1 timestamp.

8. Break-Glass (Emergency Override)

AI-EMRG.1 (Emergency Override Lifecycle Witnessing) governs the scenario where a Sev-1 production incident requires bypassing the trust gate. The override is witnessed, not silent. The bypass itself becomes auditable evidence. The absence of an AI-EMRG.1 anchor during an acknowledged outage is a finding -- it means the override occurred without governance.

The break-glass pattern: an operator provides a ticket hash or approval ID. The trust gate logs the override event as an AI-EMRG.1 anchor. The tool executes outside normal delegation boundaries. The control plane is immediately alerted. The override anchor records the justification, the approver, and the duration of the bypass window.

Emergency overrides do not disable witnessing. They bypass the trust verification gate while continuing to mint AI-TOOL.1 anchors for every tool execution during the override window. The evidence chain is complete -- it simply includes the AI-EMRG.1 anchor as the authorization basis instead of AI-TRUST.1 + AI-DEL.1.

Authorization requirements: In regulated environments, break-glass invocation may require multi-person integrity (two authorized individuals) or explicit Authorizing Official approval. The AI-EMRG.1 anchor's approval hash field can encode a composite approval (e.g., two ticket hashes concatenated) to satisfy dual-control requirements. Organizations subject to NIST 800-53 AC-3(2) or equivalent controls should configure their override workflow to require a second approver before the trust gate bypass takes effect.

9. Regulatory Alignment

Each step in the delegation governance loop maps to specific requirements across six regulatory frameworks. All citations are live in the SWT3 bidirectional crosswalks registry (/registry/crosswalks.json).

The regulatory alignment is bidirectional. Starting from a framework requirement (e.g., EU AI Act Art. 9(9) on value chain responsibility), the crosswalk identifies which SWT3 procedures produce the required evidence. Starting from an SWT3 anchor (e.g., AI-DEL.1), the crosswalk identifies which framework requirements the anchor supports. The assessor can work in either direction.

Jurisdictional delegation chains: When Agent A (EU jurisdiction) delegates to Agent B (APAC jurisdiction) delegates to Agent C (US jurisdiction), the regulatory requirements differ at each hop. SWT3 supports jurisdiction-aware delegation through CJT fields (jurisdiction, legal_basis, purpose_class) that survive all clearing levels. Each hop in the delegation chain can carry its own jurisdictional context, enabling the assessor to evaluate compliance against the applicable framework at each boundary rather than applying a single framework uniformly across the chain.

10. Quick Reference + Getting Started

Examiner Quick Reference

Quick Start (Python)

pip install swt3-ai

from swt3_ai import Witness

w = Witness(
    tenant="YOUR_TENANT",
    api_key="YOUR_API_KEY",
    endpoint="https://sovereign.tenova.io/api/v1/witness"
)

# Verify trust before tool execution
w.witness_verify_agent_trust(
    counterpart_agent_id="external-agent",
    trust_level=2,
    checks_passed=3,
    checks_total=3
)

# Mint delegation grant
w.witness_delegation_tree(
    delegator_id="my-orchestrator",
    scope="read-only",
    delegation_depth=1,
    delegates=["external-agent"]
)

# Execute tool with automatic witnessing
@w.wrap_tool(tool_name="fetch_data")
def fetch(query: str):
    return external_mcp.call_tool("fetch_data", {"q": query})

result = fetch("compliance status")
w.flush()

Quick Start (TypeScript)

npm install @tenova/swt3-ai

import { Witness } from "@tenova/swt3-ai";

const w = new Witness({
  tenant: "YOUR_TENANT",
  apiKey: "YOUR_API_KEY",
  endpoint: "https://sovereign.tenova.io/api/v1/witness"
});

// Verify trust
w.witnessVerifyAgentTrust({
  counterpartAgentId: "external-agent",
  trustLevel: 2,
  checksPassed: 3,
  checksTotal: 3
});

// Mint delegation grant
w.delegationTreeGrant({
  delegatorId: "my-orchestrator",
  scope: "read-only",
  delegationDepth: 1,
  delegates: ["external-agent"]
});

// Execute with witnessing
const fetch = w.wrapTool(fetchData, "fetch_data");
const result = await fetch("compliance status");
await w.flush();

Related Guides

• MCP Trust Mesh -- How MCP agents verify each other before tool calls
• Trust Mesh Implementation -- SDK-level integration for Python and TypeScript
• Trust Mesh Assessment -- Assessor evidence patterns for trust verification
• A2A Agent Card Integration -- Discovery via .well-known/agent.json
• A2A Task Lifecycle Witnessing -- Full task lifecycle evidence chains
• Agent Protocol Evidence Layer -- Post-hoc audit trail for agent interactions
• Multi-Agent Chain Audit Trail -- Tracing delegation across orchestrators
• CISA/NSA Agentic AI Crosswalk (Five Eyes) -- Federal delegation governance requirements
• OWASP Agentic Top 10 Crosswalk -- Security risk mapping for agent tool calls
• Singapore IMDA Agentic AI Crosswalk -- APAC regulatory alignment
• SDK Documentation -- API reference for all 10 languages
• UCT Registry -- 293 procedures across 10 namespaces
• Create Free Account -- Start witnessing in under 5 minutes