Multi-Agent Systems and High-Risk Capabilities

Mission

By the end, you can distinguish manager, handoff, and peer coordination; design a bounded agent-to-agent contract; and contain computer-use and code-execution capabilities behind API-first, least-privilege controls.

Prerequisite: Chapters 5.1-5.2 and the security boundaries from Modules 1-4. Build artifact: a multi-agent justification record and containment profile for one high-risk capability. Time: 80-100 minutes.

Before you read: Predict → Commit → Connect

A single support agent is accurate on password resets but weak on privacy requests. Should you add a privacy specialist agent and let both agents talk until they agree?

Commit to an architecture. Specify who owns the user interaction, who can call tools, what authority transfers, how the conversation ends, and how you would prove the second agent improved outcomes.

More agents do not create more authority

A multi-agent system coordinates two or more independently prompted or operated components that can select actions, exchange messages, or own parts of a task. It may improve specialization, context isolation, concurrency, or organizational interoperability.

It also creates new routes, identities, trust boundaries, failure combinations, and places for instructions or data to be altered. Two uncertain model outputs do not become a policy decision by voting. A specialist can propose a refund; only an authorized control can approve and execute it.

Start with a single agent plus deterministic tools. Add another agent only when a representative evaluation shows a specific advantage that cannot be obtained more simply through better context, retrieval, routing, or ordinary functions.

Three coordination patterns

Manager pattern

One coordinator owns the task and delegates bounded subtasks. Specialists return structured results; the manager combines them. This makes ownership and the final answer clear, but the manager can become a bottleneck or distort specialist evidence.

Use it when subtasks are separable and one component can enforce budgets, contracts, and final synthesis.

Handoff pattern

The active agent transfers conversation ownership to another agent. The handoff includes a bounded context package, reason, user-visible status, and explicit scope. The recipient either accepts or rejects it.

Use it when a specialist must directly gather information from the user or when responsibility genuinely changes. Do not silently hand off privileged credentials or assume the recipient inherits the sender’s authority.

Peer pattern

Agents communicate without one permanent manager. They may negotiate tasks, publish capabilities, or form a graph dynamically. This can support cross-organization work, but termination, conflict resolution, trust, cost, and incident ownership become harder.

Use it only when decentralized coordination is itself a requirement. A group chat among model instances is not automatically a robust peer protocol.

The patterns can be nested, but each composition multiplies states. Name one owner for user communication, budgets, cancellation, security decisions, and incidents.

The multi-agent complexity tax

For each extra agent, price:

• another prompt, context policy, model configuration, and evaluation surface;
• message schemas, delivery semantics, ordering, duplication, and version negotiation;
• identity, authentication, authorization, and credential delegation;
• context loss, conflicting outputs, loops, and deadlocks;
• additional model calls, latency, rate limits, and cost variance;
• more traces, retention, redaction, and incident evidence;
• a larger supply chain of frameworks, remote services, skills, and tools.

A specialist that improves accuracy by two points but doubles tail latency and opens a cross-tenant data path may be a regression. Measure task success, safety violations, routing quality, latency, cost, and recovery together.

A2A is a protocol boundary, not a shared mind

Current protocol note (verified July 17, 2026): A2A 1.0.0 is the latest released specification. The concepts below are durable, but production implementations should pin and negotiate a supported protocol version rather than silently following a moving latest document.

The Agent2Agent (A2A) specification defines interoperable concepts such as agent discovery through an Agent Card, messages, tasks with lifecycle state, parts, artifacts, streaming or asynchronous updates, protocol bindings, and security schemes. It is useful when independently built agents need to collaborate without exposing their private implementation, tools, or memory.

Treat every A2A boundary like an external service boundary:

1. obtain an Agent Card from an approved discovery path;
2. verify server identity and any card signature required by your trust model;
3. match a declared skill to an allowlisted business need;
4. authenticate with a narrowly scoped client identity;
5. authorize each requested operation on the receiving server;
6. send the minimum task data and a correlation ID;
7. validate messages and artifacts as untrusted inputs;
8. enforce time, message, byte, and cost budgets;
9. retain receipts and handle cancellation, duplication, and terminal states.

An Agent Card is a capability advertisement, not proof that a remote agent is safe, correct, or entitled to data. Authentication proves an identity according to a scheme; authorization still decides what that identity may do. The model cannot mint or enlarge either permission.

A2A and tool protocols solve different boundaries. A remote agent may own a task and return an artifact; a tool exposes an operation to a host. Neither protocol removes application-level policy.

API-first for action

Prefer a narrow, documented API over screen manipulation when both can accomplish the task. APIs usually offer typed inputs, smaller scopes, stable identities, idempotency, explicit errors, and receipts. Computer use sees a broad visual surface, can be redirected by untrusted content, and may click the wrong object after layout changes.

The order of preference is generally:

1. deterministic local function for local computation;
2. scoped service API with typed contracts;
3. supervised computer use in an isolated environment when no suitable API exists;
4. no automation when the residual risk is unacceptable.

API-first is not API-blind. A dangerous API still needs least privilege, validation, approval, and evidence.

Contain computer use

A computer-use agent can read pixels, type, click, download, upload, and interact with authenticated sessions. That combines untrusted content with broad ambient authority.

Use a dedicated ephemeral browser profile or isolated desktop, not a person’s everyday session. Remove password-manager access, unrelated tabs, personal files, clipboard history, saved payment methods, and broad cloud sessions. Restrict destinations and downloads; block local and metadata endpoints; scope upload directories; apply time and action budgets; and pause before irreversible or high-impact actions.

Assume pages, documents, chat messages, filenames, QR codes, and images may contain indirect prompt injection. Page text is data, never higher-authority instruction. Use deterministic confirmation surfaces that show the destination, normalized arguments, and effect independently of the page the agent just read.

Contain code execution

Generated code is untrusted even when it looks reasonable. Do not run it on the host, mount the container engine socket, pass host credentials, or allow unrestricted network egress.

A strong execution profile uses:

• an ephemeral sandbox or virtual machine with a read-only base image;
• an unprivileged user, dropped capabilities, and restrictive syscall policy;
• no host filesystem mounts except a narrow synthetic input and output area;
• network denied by default, with destination allowlists only when essential;
• short-lived task credentials scoped to one operation and injected only after authorization;
• CPU, memory, process, disk, output, and wall-clock limits;
• pinned and scanned dependencies where installation is allowed;
• captured exit status, resource use, file manifest, and sanitized output;
• destruction of the environment after artifact extraction.

Containers reduce exposure but share a kernel; their configuration and host security matter. For hostile multi-tenant code, stronger isolation may be required. “Sandboxed” is a claim to verify with escape, network, mount, secret, and denial-of-service tests.

Notice that the model proposes before the privilege funnel. It never operates as the authorization layer.

I do: test whether two capstones need two agents

The offline package contains a research capstone and a support capstone. That does not mean they should talk to each other.

Run them independently:

cd courses/ai-agents/labs
python3 -m agent_lab.capstones.research "How should an agent handle secrets?"
python3 -m agent_lab.capstones.support T-1004

Research uses a synthetic knowledge corpus. Support uses synthetic tickets and policy. Their data, tools, success criteria, and authority differ. Isolation is a feature.

If support needs a policy citation, the simplest design is a bounded read-only retrieval function or manager subtask that returns {answer, citations, confidence}. It should not grant the research component ticket access or let it execute support tools.

We do: design a remote privacy handoff

Assume a partner operates a privacy-request specialist through A2A.

Together define:

• a task contract containing synthetic case ID, request type, jurisdiction category, and redacted evidence references;
• no customer message body unless necessary and authorized;
• a client credential scoped to privacy_case:assess, not deletion;
• accepted artifact schema: classification, missing evidence, recommended human queue, source references;
• terminal, cancelled, timeout, and duplicate-task behavior;
• a human owner who validates any deletion request in the system of record.

The remote agent assesses. It does not inherit the local user’s session or deletion authority.

You do: LAB-15 — Justify coordination and prove containment

Run the safety and boundary tests:

cd courses/ai-agents/labs
python3 -m unittest \
  tests.test_safety_contract.StaticSafetyContractTests \
  tests.test_agent.AgentLoopTests.test_unknown_tool_is_rejected_without_execution \
  tests.test_tools.ToolRegistryTests.test_rejects_unknown_missing_extra_and_wrong_type_arguments \
  tests.test_memory_approvals_trace.MemoryTests.test_sessions_are_isolated -v

Then create two records:

1. Coordination decision: compare one agent, manager, handoff, and peer designs for the privacy case. List expected gain, new states, data shared, identity, permissions, termination, metrics, and rollback. Choose one.
2. Containment profile: for either browser or code execution, specify isolation boundary, filesystem, network, credentials, resource limits, approval points, output validation, evidence, and teardown.

Add five adversarial tests: prompt injection on a page, attempted access to another session, unexpected tool name, network call to an unapproved host, and a fork bomb or infinite loop. Describe the deterministic expected result.

Done when: the selected design has one accountable owner, no authority flows through natural-language messages, and every high-risk capability is least-privileged and disposable.

Pause & Recall

1. Distinguish manager, handoff, and peer coordination.
2. Why is an Agent Card not a trust decision?
3. What does API-first reduce?
4. Name six code-sandbox controls.
5. Why can adding a specialist reduce total system reliability?

Production lens

Give every service agent a workload identity and every task a correlation ID. Use mutually understood schemas, protocol versions, deadlines, and idempotency semantics. Limit message size and hop count. Detect loops. Propagate cancellation. Make remote-agent failure visible rather than letting the manager invent a successful artifact.

Keep credentials local to the component that needs them and delegate the narrowest short-lived scope. Do not place bearer tokens in prompts, inter-agent messages, screenshots, or traces. Redact artifacts before crossing organizational boundaries and enforce tenant filters before retrieval.

Canary multi-agent changes against a single-agent control. Evaluate both outcome and trajectory: wrong recipient, excess messages, unauthorized request, failure to terminate, tool misuse, latency, and cost. Maintain a kill switch that disables remote peers, computer use, or code execution without taking down safe read-only functions.

Chapter compression

• Multi-agent systems may add specialization or interoperability, but they never create authority.
• Managers delegate, handoffs transfer ownership, and peers coordinate without one permanent controller.
• A2A standardizes discovery, tasks, messages, artifacts, and security declarations across opaque agents.
• Authenticate identities and authorize operations in trusted code; natural-language messages carry no privilege.
• Prefer narrow APIs; isolate computer use and code execution when they are genuinely required.
• Every added agent and capability must repay its security, reliability, latency, cost, and operational taxes.

Memory hook: Coordinate by contract; delegate little; contain powerful tools.

Retrieval deck

• Q: When is a manager pattern useful?
  A: When bounded subtasks can be delegated while one component retains budgets, final synthesis, and accountable ownership.
• Q: What does A2A reveal about a remote agent?
  A: Declared interfaces, skills, tasks, messages, artifacts, and security schemes—not its private internals or inherent trustworthiness.
• Q: Why prefer an API to computer use?
  A: A scoped API usually offers narrower authority, typed inputs, explicit errors, idempotency, and receipts.
• Q: Who authorizes generated code or a computer-use click?
  A: Trusted policy and approval controls outside the model, using exact normalized action details.

Spaced review

• Now: redraw the three coordination patterns and assign one owner to each.
• +1 day: reconstruct the A2A boundary checklist.
• +3 days: threat-model a browser session with a malicious page.
• +7 days: write a sandbox profile that blocks secrets, host access, egress, and resource exhaustion.
• +14 days: compare a multi-agent canary with a single-agent control on success, safety, latency, and cost.

Sources and further study

• A2A Protocol Specification 1.0.0
• Wu et al.: AutoGen—Enabling Next-Gen LLM Applications via Multi-Agent Conversation
• NIST SP 800-190: Application Container Security Guide
• NIST SP 800-207: Zero Trust Architecture
• OWASP AI Agent Security Cheat Sheet