Agent and MCP trust boundaries

The DASF v3 catalog adds risks for the agent core, MCP servers and MCP clients. These overlap with the supporting data, model and platform lifecycle. An agent’s ability to act makes the effective authority of each tool and its downstream service central to the investigation.

Follow one action through the system

sequenceDiagram
  participant U as User
  participant A as Agent
  participant C as Retrieved content
  participant M as MCP tool
  participant S as Protected service
  U->>A: Request within user authority
  C-->>A: Untrusted evidence
  A->>M: Proposed operation and arguments
  M->>S: Authenticated, scoped request
  S-->>M: Authorization decision and result
  M-->>A: Structured result with provenance
  A-->>U: Outcome and evidence

Project-authored investigation prompts:

Boundary	What to establish	Relevant starting points
Retrieval → reasoning	Content does not gain instruction authority; retrieval respects the user’s data permissions	9.1, 13.16, DASF-46, DASF-54
Model → tool	The requested action, arguments and destination remain within user authority	13.2, 13.22, DASF-64
Tool → downstream service	The service validates identity, audience and effective privileges	13.17, 13.19, DASF-67
Session → memory	State is isolated by tenant/user and contaminated state can be invalidated	13.1, 13.34, DASF-72
Human → side effect	Approval is bound to the exact action, expires and cannot be replayed	13.10, DASF-66
Client → server metadata	The client verifies server identity and reviews changes to tools or destinations	13.26, 13.29, DASF-70
Agent → agent	Delegated authority does not widen and messages preserve origin	13.12, 13.13, DASF-71
Execution → network/resources	Egress, isolation and budgets constrain harmful effects independently of the model	13.4, DASF-34, DASF-56, DASF-60

The MCP security best practices describe protocol threats including confused deputies, token passthrough, SSRF and state-handle abuse. Use an audience-bound token for each service; do not treat a session identifier as authentication. If a remote deployment is added, assess its transport, authorization and network boundaries separately.

For traceability, collect decision summaries, identities, tool arguments, authorization outcomes and effects, with redaction. Hidden model chain-of-thought is neither required nor a trustworthy substitute for observable action evidence. This is an explicit adaptation of DASF-65 for portable auditability.