Agent Trust Boundary Audit

---
name: agent-trust-boundary-audit
description: "Maps identity, authority, instruction, data, memory, and approval propagation across agents and agent-to-agent handoffs. Use when reviewing multi-agent systems, orchestrators, delegated tools, or confused-deputy exposure."
metadata:
  portability: universal
  discipline: blue-team
  domain: ai-systems
  tags: [agents, a2a, trust-boundaries, identity, confused-deputy]
---

# Agent trust boundary audit

Map how authority actually crosses an agent system. Keep communication,
authentication, authorization, delegation, and downstream effect distinct; a
message path alone does not establish permission to act.

## When to Use

- Reviewing multi-agent, orchestrated, delegated-tool, or agent-to-agent
  architectures.
- Investigating confused-deputy, identity propagation, approval, memory, or
  handoff-validation concerns.
- Establishing which component can cause which other component to act and under
  whose identity.

## When NOT to Use

- Do not treat the audit as authority to exercise a handoff or invoke a tool.
- Do not infer effective permissions from component names, intended roles, or a
  protocol's default security model.
- Do not collapse all agents into one trust zone merely because they share an
  orchestrator or model provider.

## Workflow

1. Define the reviewed system, environments, tenants, versions, evidence cutoff,
   owners, and intended security properties.
2. Inventory principals and components: humans, service identities, agents,
   orchestrators, models, brokers, tools, memories, queues, approval services,
   policy engines, targets, and administrative planes.
3. Record each component's authentication method, effective identity, privilege,
   tenant context, reachable resources, secret access, and policy source.
4. Map five edge types separately:
   - data transfer;
   - instruction transfer;
   - identity or token transfer;
   - delegated authority;
   - result or state transfer.
5. For every handoff, record sender, receiver, message type, provenance,
   integrity, freshness, audience binding, replay protection, target binding,
   approval binding, and failure behavior.
6. Trace authority end to end. Identify where a low-authority principal can
   shape inputs consumed by a higher-authority component, even when no
   credential crosses the boundary.
7. Review confused-deputy conditions: mismatched requester and execution
   identity, ambient authority, incomplete target binding, untrusted arguments,
   result reuse, and approval detached from final action.
8. Review memory and state boundaries: writer, reader, tenant, lifetime,
   revocation, provenance, conflict handling, and stale-state invalidation.
9. Label every edge `observed`, `reported`, `inferred`, `contradicted`, or
   `unknown`. Preserve the exact evidence supporting effective authority.
10. Build abuse-path hypotheses without exercising them. A path remains
    conditional when any identity, authority, policy, or target transition is
    unproven.
11. Prioritize choke points where one control limits multiple paths: scoped
    identity, explicit delegation, exact approval binding, provenance checks,
    tenant isolation, revocation, and target-side authorization.

## Boundary with adjacent skills

- Use `agent-surface-audit` for individual tool definitions and parameter risk.
- Use `agent-runtime-validation` to exercise authorized runtime controls.
- Use `ai-threat-model` for the broader system threat model and crown jewels.

## Deliverable

Return the component and principal inventory, typed trust-edge map, effective
authority matrix, handoff-control table, confused-deputy hypotheses, memory and
tenant findings, evidence gaps, and prioritized control choke points.

## Rationalizations to reject

- **“The agents are internal, so the handoff is trusted.”** Internal components
  can have different identities, tenants, policies, and compromise assumptions.
- **“The protocol authenticates both sides.”** Authentication does not prove
  authorization for the requested target or action.
- **“The approval happened in the workflow.”** Verify that it binds the final
  arguments, identity, target, and time.
- **“No credential is forwarded, so authority does not propagate.”** A deputy
  can act with ambient authority on attacker-shaped input.
- **“Shared memory is just context.”** Persistent context is a cross-task data
  and instruction boundary.
- **“The diagram shows the intended path.”** Intended architecture is reported
  evidence until deployment facts confirm it.