How to Verify an AI Agent Before Delegating Work to It: An A2A Trust Checklist (2026)

Most teams now vet their tools. Before an MCP server touches production, they check its publisher, its permissions, its audit history — and our registry publishes trust scores and verified badges because tool-level vetting works.

But there's a second surface most teams haven't formalized: the agent itself. When your orchestrator delegates a task to another agent — a research, procurement, or booking agent built by someone else — you're trusting a party that will plan, make judgment calls, chain tools together, and possibly spend money. Agent-to-agent (A2A) delegation is now the norm in multi-agent stacks, and verification practices haven't caught up.

This checklist closes that gap: seven checks we'd run before letting an unfamiliar agent act on our behalf.

Why Agent Verification Is Not Tool Verification

A tool is inert. An MCP server does what its schema says, when called. Verification is mostly about provenance: who published it, what the code does, what it can touch.

An agent is different in three ways:

1. It exercises judgment. Two agents with identical tool access can produce wildly different outcomes depending on their instructions and model behavior.
2. It compounds authority. An agent that can call five tools can combine them in ways no single tool permits — read a customer record, then email it somewhere.
3. It has its own economic agency. Pay-per-call APIs and agent-native payments mean a delegated agent can incur costs in your name.

So the question shifts from "is this tool safe?" to "is this counterparty trustworthy?" — closer to vendor risk assessment than code review, and it deserves the same rigor.

The 7-Point A2A Verification Checklist

1. Identity: Who Actually Operates This Agent?

Before anything else, establish who is accountable. A verifiable agent should expose an operator identity — an organization, a domain, or at minimum a stable public key — and that identity should be checkable against an independent source. "An agent my orchestrator discovered on a feed" is not an identity.

Check: Does the agent publish an operator of record? Can you reach that operator when something goes wrong? Agents that can't answer "who made you and how do I reach them" fail here, and should not receive delegation.

2. Declared Capabilities vs. Actual Behavior

Well-designed agent ecosystems use capability declarations — an agent card or manifest listing what the agent claims it can do. Claims are a starting point, not proof. The verification step is comparing the declaration against observed behavior: does the agent request tools it never declared? Does it declare broad capabilities it never justifies?

Check: Request the agent's capability declaration. Run a scoped test task and log every tool call. Undeclared tool usage during the test is an immediate red flag.

3. Least-Privilege Scope

A delegation should grant the minimum authority the task requires. If the task is "summarize these three invoices," the agent has no business holding a write key to your production database. Issue scoped credentials for the delegation — don't hand over your existing session.

Check: Enumerate the tools and access levels the task requires, then confirm the agent operates within exactly that envelope. Anything broader gets rejected or sandboxed.

4. Track Record and Provenance of Past Actions

The strongest predictor of future behavior is an inspectable history. Mature agent ecosystems are converging on audit artifacts — signed receipts of actions taken, comparable to MCP trust receipts — that let you verify what an agent actually did, not what it says it did.

Check: Ask for evidence of past runs: signed action logs, references from operators who delegated to it, or a verifiable audit feed. An agent with zero history isn't disqualified — but it should start with low-value, revocable tasks only.

5. Escalation and Human-Approval Behavior

The check most teams skip: what does the agent do when it hits ambiguity? A trustworthy agent has a defined escalation path — it pauses and asks a human at predefined boundaries (spending above a threshold, destructive actions, external communications) rather than improvising.

Check: Deliberately give the agent a task with an ambiguous edge case. Watch what it does. Agents that silently guess their way through consequential decisions are the ones that eventually email your entire customer list.

6. Data Handling and Residency

If you operate in the EU, delegated agents are part of your compliance surface. Where does the agent process data? Does it retain task content? Does it forward your data to third-party models or storage?

Check: Get a plain answer on data residency, retention, and subprocessors. For EU teams, verify GDPR posture explicitly — data processing beyond your control doesn't stop being your responsibility because you delegated it. This is a core reason EU-first agent infrastructure exists: the compliance chain has to hold end to end.

7. Financial Exposure

Finally, cap the money. Agent-native payments are growing fast — per-call pricing, metered access, autonomous purchases — and a delegated agent with a wallet is a new category of financial risk.

Check: Set explicit spend limits per delegation: a hard cap, a per-action ceiling, and ideally a kill switch. Reconcile the agent's bill against its task list. An agent whose spending doesn't map to its declared tasks is misbehaving, even if every individual action looked innocent.

Red Flags That Should End the Evaluation

Some findings shouldn't be worked around:

• No reachable operator or accountability path
• Tool usage that exceeds the declared capability set
• Refusal to state data handling or retention practices
• History of actions it cannot evidence with logs or receipts
• Improvisation on consequential decisions instead of escalation
• Spending that isn't reconcilable with assigned tasks

Any one of these is a "not yet." Two or more is "not this agent."

Making Verification Repeatable

A checklist you run once is a memo; a checklist embedded in process is infrastructure. Three practical moves:

1. Make verification a gate, not an afterthought. No A2A delegation without a completed checklist on file — same as code review.
2. Tier agents by verified trust. First contact gets read-only, revocable, capped tasks. Full autonomy is earned through evidenced history, not requested.
3. Prefer agents that publish verifiable credentials. Verification gets dramatically cheaper when the other side does half the work — publishing operator identity, capability declarations, and signed action logs up front.

That last point is where marketplaces earn their keep: a directory that verifies publisher identity, audits capabilities, and surfaces trust scores collapses a week of manual diligence into an afternoon. Individual verification doesn't scale; institutional verification does.

Start With Your Next Delegation

You don't need a formal vendor-risk program to benefit from this. Take the next task you'd hand to an unfamiliar agent and run the seven checks. It takes twenty minutes and it's the difference between delegation and hoping.

Want agents that arrive pre-verified? Browse the AgentForge MCP server registry — every listing carries publisher verification, a trust score, and EU-compliant data documentation. For teams building multi-agent systems, the blog covers trust scoring, GDPR-compliant hosting, and secure agent-tool patterns.

Delegate with evidence, not optimism.