AgentCard
An AgentCard is a JSON metadata document served at /.well-known/agent.json. It describes what an agent can do, how to reach it, and what authentication it accepts.
{
"name": "InvoiceProcessingAgent",
"description": "Processes and validates vendor invoices",
"url": "https://agents.acme.com/invoice",
"version": "1.2.0",
"capabilities": {
"streaming": true,
"pushNotifications": true,
"stateTransitionHistory": false
},
"authentication": {
"schemes": ["Bearer"]
},
"skills": [
{
"id": "invoice-extract",
"name": "Extract Invoice Fields",
"description": "Extracts vendor, amount, line items from PDF",
"inputModes": ["file"],
"outputModes": ["data"]
}
]
}
AgentCards are the entry point for agent discovery. A caller fetches /.well-known/agent.json, inspects capabilities, and decides whether to dispatch a task. The spec defines the schema. It does not define who validates the claims inside it.
Task Object
A Task is the fundamental unit of work in A2A. It carries:
interface Task {
id: string; // UUID, caller-assigned
sessionId?: string; // optional session grouping
status: TaskStatus; // submitted | working | input-required | completed | failed | canceled
artifacts?: Artifact[]; // outputs produced by the agent
history?: Message[]; // turn history within this task
metadata?: Record<string, unknown>;
}
Task status transitions are well-defined: submitted β working β completed | failed | canceled, with an optional input-required pause state for human-in-the-loop flows. Tasks can produce streaming Artifact objects for large or incremental outputs.
Message and Part
Messages carry turn-level communication. Each Message has a role (user or agent) and an array of Parts:
type Part = TextPart | FilePart | DataPart;
interface TextPart {
type: "text";
text: string;
metadata?: Record<string, unknown>;
}
interface FilePart {
type: "file";
file: { name?: string; mimeType?: string; bytes?: string; uri?: string; };
}
interface DataPart {
type: "data";
data: Record<string, unknown>;
}
The Part abstraction handles the real-world messiness of agent I/O: structured data, file blobs, streaming text, and tool outputs can all travel over the same wire format.
Transport: HTTP/SSE and JSON-RPC 2.0
A2A uses two transport modes:
- JSON-RPC 2.0 over HTTPS for synchronous method calls (
tasks/send, tasks/get, tasks/cancel)
- Server-Sent Events for streaming responses and real-time task status updates
- Webhook push notifications for long-running async tasks (agent calls back to caller's endpoint)
The JSON-RPC method surface is intentionally minimal:
| Method | Purpose |
|---|
tasks/send | Dispatch a new task or continue an existing session |
tasks/get | Poll current task status and artifacts |
tasks/cancel | Request task cancellation |
tasks/sendSubscribe | Dispatch task and subscribe to SSE stream |
tasks/resubscribe | Re-attach to existing SSE stream after disconnect |
tasks/pushNotificationConfig/set | Register webhook for async callbacks |
tasks/pushNotificationConfig/get | Retrieve current webhook config |
Authentication: What A2A Says and Does Not Say
This is the most important section for understanding the trust gap. The A2A specification says:
"A2A does not define a new authentication mechanism. Agents should use standard HTTP authentication (API keys, OAuth 2.0 bearer tokens) as described in the AgentCard's authentication field."
This is a deliberate design choice, not an oversight. The spec authors recognized that authentication is a solved problem at the transport layer. What they did not define β and what the ecosystem is now scrambling to fill β is everything above authentication: what the authenticated identity proves about behavior.
An OAuth bearer token proves that the caller has a valid token issued to their organization. It says nothing about:
- Whether that organization's agent has ever successfully completed this type of task
- What behavioral commitments the agent made before being granted access
- What its failure rate is across the last 90 days of production runs
- Whether its outputs have been independently verified
- What happens when it fails
That is the gap. And it compounds quickly at scale.
The Six-Layer Trust Stack: Where A2A Lives and What It Leaves Out
A complete agent trust architecture has six distinct layers. Understanding which layer addresses which problem is the prerequisite for building the right solution.
Layer 1: Transport
What it does: Message format, delivery guarantees, streaming, error handling, protocol versioning.
Who handles it: A2A (fully).
Attack surface if missing: Message corruption, protocol incompatibility, replay attacks.
Layer 2: Network Identity
What it does: Confirms the caller is who they claim to be at the organization/credential level.
Who handles it: A2A (via standard HTTP auth β OAuth, API keys).
Attack surface if missing: Impersonation at the network level.
Note: A2A's coverage here is genuine but shallow. OAuth confirms the token holder. It does not confirm the agent's behavioral track record.
Layer 3: Behavioral Identity
What it does: Proves that a specific agent β not just its issuing organization β has a verified, independently audited capability profile.
Who handles it: A2A does NOT cover this.
Attack surface if missing: AgentCard impersonation. Any server can serve /.well-known/agent.json claiming any capabilities. There is no mechanism to prove those claims.
Example failure: A malicious agent clones a legitimate InvoiceProcessingAgent's AgentCard, registers it at a plausible domain, and routes sensitive financial documents through a harvesting endpoint. The calling agent had no way to distinguish the clone from the original because capability claims are self-reported.
Layer 4: Obligation Tracking
What it does: Records what an agent committed to do, in what scope, under what conditions, and whether it delivered.
Who handles it: A2A does NOT cover this.
Attack surface if missing: Pact-free task acceptance. An agent can agree to a task it has never done, has no evaluation record for, and faces no consequence if it fails. The requesting agent has no way to know this before dispatching.
Example failure: An agent claims "skill": "pii-redaction" in its AgentCard. No pact defines what "redacted" means, what error rate is acceptable, or what happens when PII leaks through. A GDPR audit finds a 2.3% leakage rate. Nobody was on record committing to better. No consequence path exists.
Layer 5: Reputation
What it does: Aggregates behavioral history across deployments, organizations, and time into a queryable reputation score.
Who handles it: A2A does NOT cover this.
Attack surface if missing: Reputation laundering. An agent with a poor track record on one platform simply registers fresh on another. No cross-platform reputation means each deployment restarts trust from zero.
Example failure: An agent that failed 34% of financial reconciliation tasks on Platform A presents a clean AgentCard to Platform B with no mention of that history. Platform B dispatches high-stakes accounting work. The failure rate replicates.
Layer 6: Consequence
What it does: Changes what the network allows, routes, or pays based on demonstrated behavioral history. Failed agents face access restriction, escrow holds, or market exclusion. Reliable agents earn access to higher-stakes work.
Who handles it: A2A does NOT cover this.
Attack surface if missing: Zero-consequence failure loops. An agent that repeatedly fails has no economic or access incentive to improve. The network cannot differentiate between an agent that fails 5% of the time and one that fails 45% of the time β both keep receiving work.
The Complete Picture
| Layer | What It Solves | A2A Coverage | Who Fills the Gap |
|---|
| 1. Transport | Message format, delivery, streaming | Full | β |
| 2. Network Identity | OAuth/API key credential validation | Partial (token, not behavior) | Standard OAuth infrastructure |
| 3. Behavioral Identity | Verified capability proof | None | Armalo PactAuth, W3C DIDs |
| 4. Obligation Tracking | Pact definition + fulfillment audit | None | Armalo Behavioral Pacts |
| 5. Reputation | Cross-platform longitudinal score | None | Armalo Trust Oracle |
| 6. Consequence | Access gates, escrow, market exclusion | None | Armalo Bonds + Score Gating |
Attack Surface Analysis: Five Concrete Failure Scenarios
Abstract gap analysis is not enough. Each missing layer has a concrete attack vector that enterprise deployments will encounter at scale.
Attack 1: AgentCard Impersonation
Mechanism: A2A agent discovery relies on fetching /.well-known/agent.json from a domain. There is no PKI-like certificate authority for AgentCards. No mechanism verifies that the entity serving the card is the same entity that built and operates the described capabilities.
Exploit path:
1. Attacker registers invoice-processor.acme-vendor.com (typosquat of invoice-processor.acmevendor.com)
2. Clones legitimate agent's AgentCard verbatim
3. Routes sensitive invoice PDFs to attacker-controlled endpoint
4. Calling agent dispatches work β A2A spec offers no verification step
Real-world analog: DNS hijacking + SSL certificate issuance on a lookalike domain. The difference is that for web browsing, browsers show certificate warnings. For A2A, no equivalent warning system exists.
Mitigation: Pre-flight trust query against a registry that maintains verified AgentCard hashes with cryptographic attestation (/api/v1/trust/{agentId}/verify-card). If the served card does not match the registered hash, reject the task dispatch.
Attack 2: Capability Inflation
Mechanism: AgentCards are self-reported. An agent can claim any skill with any description. No evaluation system is specified to verify claims before deployment.
Exploit path:
{
"skills": [
{
"id": "hipaa-compliant-phi-processor",
"name": "HIPAA-Compliant PHI Processing",
"description": "Processes Protected Health Information in compliance with HIPAA Privacy Rule"
}
]
}
This skill declaration costs nothing. No audit. No evaluation. No certification. A healthcare network using A2A for care coordination could route PHI to an agent that has never been evaluated for HIPAA compliance controls.
Mitigation: Require a valid pact covering the claimed skill before routing sensitive work. Pacts define acceptance criteria, not just capability labels. An agent that cannot produce a pact record for hipaa-phi-processing should not receive PHI regardless of what its AgentCard says.
Attack 3: Reputation Laundering
Mechanism: A2A task history is local. Each A2A deployment maintains its own task records. There is no cross-deployment reputation propagation defined in the spec.
Exploit path:
Agent X achieves 38% task failure rate on Platform A β banned from Platform A routing
β Registers with fresh credentials on Platform B
β Platform B sees clean AgentCard, no history
β Routes high-stakes work β same 38% failure rate replicates
Scale of problem: In a world where A2A becomes the dominant agent communication protocol (as the HTTP of agent networks), reputation laundering becomes as common as domain fronting is for web attacks. The only defense is a cross-platform reputation layer that agents cannot self-reset.
Mitigation: Trust Oracle query before any task dispatch. The Oracle maintains cross-platform score history indexed by agent identity (not just OAuth token). An agent with laundered credentials cannot hide a score of 312/1000 earned across previous deployments.
Attack 4: Obligation-Free High-Stakes Delegation
Mechanism: A2A does not define what an agent commits to when it accepts a task. Task acceptance is a protocol handshake, not a behavioral commitment. There is no pact-equivalent in the spec β no definition of acceptance criteria, scope boundaries, failure thresholds, or consequence paths.
Exploit path:
Caller Agent dispatches: tasks/send
β task: "Transfer $47,000 to vendor account on approval"
Agent accepts: status: "working"
Agent completes: status: "completed", artifacts: [{ "type": "data", "data": { "transferred": true } }]
Actual outcome: Transfer sent to wrong account due to unverified routing logic
A2A record: task completed successfully
Pact record: none β no pact defined for financial transfer scope or verification requirements
Consequence: none β task status is "completed"
The protocol record and the real-world outcome diverge. Nobody committed to anything specific, so there is nothing to audit against.
Mitigation: Require active pact coverage for any task involving financial operations, PII, or irreversible actions. Pact acceptance before task dispatch. Pact fulfillment check after task completion. Score update based on outcome.
Attack 5: Model Substitution Without Disclosure
Mechanism: A2A has no mechanism for an agent to disclose what underlying model or runtime it uses, or to detect when that changes. An agent can advertise GPT-4o-level reasoning, silently swap to a cost-optimized smaller model, and continue serving tasks under the same AgentCard.
Exploit path:
Week 1: Agent X runs Claude 3 Opus, achieves 91% accuracy on medical coding tasks
Week 8: Agent X operator switches to Mistral 7B to cut costs
AgentCard: unchanged
A2A: no change in protocol behavior
Customer: receiving different quality outputs with no notification
Regulatory exposure: potential in healthcare, financial, legal contexts
Mitigation: Model-compliance dimension in composite scoring (5% weight in Armalo's 12-dimension model). Runtime attestation in memory attestation records. Pact clauses that specify minimum model requirements for certified skill coverage.
Protocol Comparison: A2A vs MCP vs ANP vs ACP
A2A does not exist in isolation. Understanding how it relates to competing and complementary protocols is essential for architects designing multi-agent systems.
Model Context Protocol (MCP) β Anthropic
MCP (github.com/modelcontextprotocol/specification) addresses a fundamentally different problem. Where A2A defines how agents communicate with each other, MCP defines how an LLM communicates with tools and resources exposed by servers.
MCP primitives:
- Resources: File-like data sources an LLM can read
- Tools: Functions an LLM can invoke with structured inputs/outputs
- Prompts: Reusable prompt templates with parameter substitution
- Sampling: Requests from servers to use the LLM's own inference capability
MCP and A2A are complementary. In a production multi-agent architecture:
- Agent-to-agent communication: A2A
- Agent-to-tool calls: MCP
- Trust verification for both: a trust oracle above both layers
Neither MCP nor A2A defines behavioral pacts or reputation. Both delegate trust entirely to the implementation.
Agent Network Protocol (ANP)
ANP is a community proposal that explicitly incorporates W3C Decentralized Identifiers (w3.org/TR/did-core/) into agent identity. Each ANP agent has a DID document that can include:
- Public keys for message signing
- Service endpoints for communication
- Verifiable credential references
ANP is more trust-aware than A2A but is less mature and has narrower enterprise adoption. The DID-based identity is valuable for preventing impersonation, but ANP still lacks:
- Behavioral commitment definitions
- Cross-platform reputation aggregation
- Economic consequence mechanisms
Agent Communication Protocol (ACP) β IBM Research
ACP draws on FIPA ACL (Foundation for Intelligent Physical Agents β fipa.org/specs/fipa00061/) semantics, which defined formal agent communication in the late 1990s. ACP is more formally specified than A2A, with explicit performative types (inform, request, query-if, propose, accept-proposal, reject-proposal).
ACP's formal semantics are more suitable for obligation definition, but it has minimal ecosystem adoption compared to A2A.
Comparison Table
| Property | A2A (Google) | MCP (Anthropic) | ANP (Community) | ACP (IBM Research) |
|---|
| Primary purpose | Agent-to-agent communication | LLM tool use | Agent network + DID identity | Formal agent communication |
| Maturity | High (GA, major enterprise adoption) | High (broad LLM ecosystem) | Low-medium | Low |
| Transport | HTTP/SSE + JSON-RPC 2.0 | HTTP/SSE + JSON-RPC 2.0 | HTTP + DIDComm | HTTP + FIPA-inspired format |
| Identity model | OAuth / API keys (org-level) | OAuth / API keys | DID-based (agent-level) | Agent IDs with ACL |
| Behavioral commitments | None | None | None | Partial (performative semantics) |
| Reputation | None | None | None | None |
| Cross-platform reputation | None | None | None | None |
| Consequence mechanism | None | None | None | None |
| Streaming | Yes (SSE) | Yes (SSE) | Not specified | Not specified |
| Push notifications | Yes (webhooks) | No | Not specified | Not specified |
| Discovery | AgentCard at /.well-known/ | MCP manifest | DID document | ACP directory |
| Trust gap score | 4/6 layers missing | 4/6 layers missing | 3/6 layers missing | 3/6 layers missing |
Bottom line: Every current agent communication protocol delegates trust to the implementation layer. None of them closes the behavioral identity, obligation tracking, reputation, or consequence gaps. That is not a criticism β it is the right design. Trust infrastructure should be composable above the protocol, not entangled in the wire format.
The Trust Oracle Integration Architecture
The reference architecture for layering trust above A2A follows a pre-flight verification pattern: before any consequential task dispatch, the caller queries a trust oracle and makes a routing decision based on the result.
Architecture Diagram
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β CALLER AGENT β
ββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββββββ
β
βΌ Step 1: A2A AgentCard Discovery
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β GET /.well-known/agent.json β
β β capabilities, skills, auth schemes β
β β NO verification of claims β
ββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββββββ
β
βΌ Step 2: Armalo Trust Pre-flight
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β GET /api/v1/trust/{agentId} β
β β composite score: 847/1000 β
β β pacts: [invoice-processing-v2, financial-audit-v1] β
β β certifications: [SOC2-TypeII, HIPAA-compliant] β
β β lastEval: 2026-04-18T14:22:00Z β
β β failureRate30d: 0.032 β
β β bondBalance: $5,000 USDC staked β
ββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββββββ
β
βΌ Step 3: Policy Evaluation
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β IF score < 600 β REJECT (below minimum threshold) β
β IF no pact for task type β REJECT (no behavioral commitment) β
β IF lastEval > 30 days ago β WARN (stale evaluation) β
β IF bondBalance < $1,000 β RESTRICT (low consequence stake) β
ββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββββββ
β PASS
βΌ Step 4: A2A Task Dispatch
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β POST tasks/send β
β β task.metadata.pactId: "pact_8f3a..." (from trust response) β
β β task.metadata.trustCheckId: "tc_9d2b..." (audit trail) β
ββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββββββ
β
βΌ Step 5: Post-Task Attestation
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β POST /api/v1/memory/attest β
β β taskId, pactId, outcome, artifacts hash β
β β signed attestation β feeds reputation score β
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
interface TrustResponse {
agentId: string;
score: number; // 0β1000, composite across 12 dimensions
grade: 'A' | 'B' | 'C' | 'D' | 'F';
pacts: PactSummary[]; // active behavioral commitments
certifications: Certification[];
evaluations: {
count: number;
lastRunAt: string; // ISO 8601
freshnessStatus: 'fresh' | 'aging' | 'stale';
};
reputation: {
reliabilityScore: number; // 0β100, transaction-based
volumeScore: number; // task volume weighting
longitudinalTrend: 'improving' | 'stable' | 'degrading';
};
bond: {
stakedAmount: number; // USDC staked as consequence collateral
currency: 'USDC';
slashHistory: SlashEvent[];
};
flags: TrustFlag[]; // active warnings or restrictions
requestId: string; // for audit trail
}
Score Dimension Breakdown
Armalo's composite score aggregates 12 independent evaluation dimensions:
| Dimension | Weight | What It Measures |
|---|
| Accuracy | 14% | Output correctness vs. ground truth or jury verdict |
| Reliability | 13% | Task completion rate, error recovery, uptime consistency |
| Safety | 11% | Harmful output rate, scope containment, refusal correctness |
| Self-audit (Metacalβ’) | 9% | Agent's ability to accurately assess its own confidence |
| Security | 8% | Vulnerability surface, data handling, injection resistance |
| Bond | 8% | Staked collateral as consequence commitment signal |
| Latency | 8% | P50/P95/P99 task completion times vs. pact SLA |
| Scope-honesty | 7% | Accuracy of capability claims vs. demonstrated performance |
| Cost-efficiency | 7% | Token/compute cost per unit of verified output quality |
| Model-compliance | 5% | Adherence to declared model and runtime specifications |
| Runtime-compliance | 5% | Compliance with platform policies and execution constraints |
| Harness-stability | 5% | Consistency across repeated adversarial evaluation runs |
Score interpretation:
- 900β1000: Certified. Eligible for highest-stakes work, elevated marketplace rank.
- 750β899: Trusted. Cleared for most production deployments without additional review.
- 600β749: Conditional. Suitable for lower-stakes work; recommend human-in-loop for consequential decisions.
- 400β599: Marginal. Flagged for improvement. High-stakes routing should require explicit override.
- Below 400: Restricted. Should not receive new high-stakes task assignments.
Implementation Playbook: Step-by-Step Integration
Phase 1: Instrumentation (Days 1β5)
Goal: Wire trust pre-flight into every task dispatch path.
Step 1: Install the trust check middleware
import { TrustOracleClient } from '@armalo/core';
const trust = new TrustOracleClient({
apiKey: process.env.ARMALO_API_KEY,
baseUrl: 'https://armalo.ai/api/v1',
});
async function dispatchA2ATask(
agentId: string,
taskType: string,
payload: unknown,
options: { minScore?: number; requirePact?: boolean } = {}
) {
const { minScore = 600, requirePact = true } = options;
// Step 1: Fetch AgentCard (standard A2A discovery)
const card = await fetchAgentCard(agentId);
// Step 2: Armalo pre-flight trust check
const trustResult = await trust.check(agentId, {
taskType,
context: { cardHash: hashAgentCard(card) },
});
// Step 3: Policy enforcement
if (trustResult.score < minScore) {
throw new TrustGateError(
`Agent ${agentId} score ${trustResult.score} below minimum ${minScore}`,
{ trustResult }
);
}
if (requirePact &&!trustResult.pacts.some(p => p.coversTaskType(taskType))) {
throw new NoPactError(
`Agent ${agentId} has no active pact covering task type: ${taskType}`,
{ agentId, taskType, activePacts: trustResult.pacts }
);
}
if (trustResult.flags.some(f => f.severity === 'blocking')) {
throw new TrustFlagError(
`Agent ${agentId} has blocking trust flags`,
{ flags: trustResult.flags }
);
}
// Step 4: Dispatch via A2A with trust metadata attached
const task = await a2aClient.send({
agentUrl: card.url,
message: { role: 'user', parts: [{ type: 'data', data: payload }] },
metadata: {
armalo: {
trustCheckId: trustResult.requestId,
pactId: trustResult.pacts.find(p => p.coversTaskType(taskType))?.id,
scoreAtDispatch: trustResult.score,
}
}
});
return task;
}
Step 2: Post-task attestation
async function attestTaskOutcome(
taskId: string,
trustCheckId: string,
pactId: string,
outcome: 'fulfilled' | 'partial' | 'failed',
artifacts: Artifact[]
) {
await trust.attest({
taskId,
trustCheckId,
pactId,
outcome,
artifactHashes: artifacts.map(a => sha256(JSON.stringify(a))),
completedAt: new Date().toISOString(),
});
}
// Wire into A2A task polling loop
const result = await pollTaskUntilComplete(task.id);
await attestTaskOutcome(
task.id,
task.metadata.armalo.trustCheckId,
task.metadata.armalo.pactId,
result.status === 'completed'? 'fulfilled' : 'failed',
result.artifacts?? []
);
Phase 2: Pact Definition (Days 6β14)
Goal: Define behavioral pacts for each critical task type. A pact is a formal commitment: what the agent promises to deliver, under what conditions, with what acceptance criteria.
Minimum pact definition for a financial processing agent:
{
"pact": {
"version": "2.1.0",
"name": "Invoice Processing SLA",
"agentId": "agent_7f3a...",
"scope": {
"allowedOperations": ["invoice-extract", "invoice-validate", "invoice-classify"],
"forbiddenOperations": ["payment-initiation", "vendor-account-modification"],
"dataClassifications": ["financial-pii", "vendor-data"],
"geographicRestrictions": ["US", "EU"],
"retentionPolicy": "process-and-discard"
},
"acceptanceCriteria": {
"extractionAccuracy": { "minimum": 0.97, "measured": "field-level-match" },
"processingLatency": { "p95MaxMs": 8000, "p99MaxMs": 15000 },
"failureRate": { "maximum": 0.02, "window": "30d" },
"piiLeakageRate": { "maximum": 0.0, "tolerance": "zero" }
},
"consequences": {
"slaViolationThreshold": 3,
"violationAction": "pause-and-review",
"bondSlashCondition": "piiLeakage",
"bondSlashAmount": "100%"
},
"evaluationSchedule": {
"frequency": "weekly",
"adversarialSuite": "financial-red-team-v3"
}
}
}
The pact reference is then queryable at /api/v1/pacts/{pactId} and surfaced in the Trust Oracle response. Any caller can inspect what the agent committed to before routing work.
Phase 3: Threshold Calibration (Days 15β21)
Goal: Set score thresholds appropriate for each task risk level.
const TRUST_THRESHOLDS: Record<string, TrustPolicy> = {
// Lowest risk: read-only data retrieval
'data-lookup': {
minScore: 400,
requirePact: false,
requireFreshEval: false,
requireBond: false,
},
// Medium risk: content generation, classification
'content-generation': {
minScore: 600,
requirePact: true,
requireFreshEval: true, // eval within 30 days
requireBond: false,
},
// High risk: financial operations
'financial-processing': {
minScore: 800,
requirePact: true,
requireFreshEval: true, // eval within 7 days
requireBond: true, // minimum $1,000 USDC staked
minBondAmount: 1000,
},
// Critical: irreversible actions (fund transfers, contract signing)
'irreversible-action': {
minScore: 900,
requirePact: true,
requireCertification: ['SOC2-TypeII'],
requireFreshEval: true, // eval within 24 hours
requireBond: true,
minBondAmount: 10000,
humanApprovalRequired: true,
},
};
Phase 4: Reputation Feedback Loop (Days 22β30)
Goal: Ensure every task outcome feeds back into the agent's reputation score.
The feedback loop is:
- Task dispatched β trust check ID recorded
- Task completed β outcome attested with pact ID + task ID
- Attestation β Armalo evaluates against pact acceptance criteria
- Score updated β weighted across 12 dimensions based on evidence
- Trust Oracle response β reflects updated score in next pre-flight check
This loop means an agent's score reflects actual production behavior, not a one-time evaluation snapshot. An agent that was excellent 90 days ago but started degrading will show a declining score before it causes a major failure.
Regulatory Alignment: NIST AI RMF, EU AI Act, and IEEE P3394
NIST AI RMF (SP 800-218A)
The NIST AI Risk Management Framework organizes AI governance into four functions: GOVERN, MAP, MEASURE, MANAGE. The A2A protocol itself contributes to MAP (identifying where AI operates) and partially to MEASURE (what it does). It contributes nothing to GOVERN (accountability structure, policy, oversight) or MANAGE (incident response, ongoing monitoring).
The trust layer architecture maps directly to NIST's GOVERN function:
| NIST AI RMF Requirement | Trust Layer Coverage |
|---|
| AI risk governance policies and procedures | Behavioral pacts define governance rules per agent per task type |
| Accountability and transparency mechanisms | Audit trail from trust check ID through post-task attestation |
| Risk tolerance thresholds | Score thresholds per task risk level (400 β 900) |
| Ongoing AI risk monitoring | Real-time score updates from production attestations |
| Incident response for AI failures | Pact violation triggers β review workflow + bond slash if warranted |
Organizations subject to NIST AI RMF compliance (federal contractors, financial institutions under FFIEC guidance) will find that A2A alone does not satisfy the GOVERN function requirements. A trust layer is needed to close the gap.
EU AI Act β Article 53 Foundation Model Transparency
The EU AI Act's Article 53 imposes transparency obligations on providers of general-purpose AI models that are integrated into AI systems. When an agent built on a foundation model performs regulated tasks (healthcare decisions, credit assessment, legal document processing), the deploying organization has obligations to:
- Document the model used and its known capabilities/limitations
- Demonstrate evaluation against the intended use case
- Maintain audit trails for high-risk AI system outputs
A2A's metadata field provides a passthrough for compliance data, but the compliance content itself must come from somewhere. Behavioral pacts + evaluation records + trust oracle responses collectively satisfy the Article 53 documentation requirements that A2A cannot fulfill alone.
IEEE P3394 β Agent Accountability Standard (In Progress)
IEEE P3394, currently in working group stage, aims to define agent accountability standards including identity verification, behavioral auditing, and consequence mechanisms. Early drafts reference:
- Agent identity anchored to a cryptographically verifiable identifier (aligned with W3C DID spec)
- Behavioral capability claims requiring third-party verification
- Longitudinal accountability records that cannot be self-reset by the agent operator
The trust layer architecture described here anticipates where IEEE P3394 is heading. Organizations that implement it now will find compliance straightforward when the standard reaches ratification.
A2A Becomes the HTTP of Agent Networks: What That Means for Trust
The framing that A2A will become "the HTTP of agent communication" deserves serious analysis. HTTP itself provides an instructive comparison.
What HTTP Did Not Solve
HTTP standardized web communication in 1991. It solved message format, transport, and basic error codes. It did not solve:
- Identity: DNS hijacking was a systemic threat for decades. HTTPS + certificate transparency solved it β 25 years later.
- Authentication: HTTP had Basic Auth. OAuth didn't mature until 2010. OAuth 2.0 didn't standardize until 2012.
- Authorization: HTTP has no concept of authorization scopes. This was solved at the application layer.
- Reputation: There is no HTTP-level reputation system. Web of Trust, Google PageRank, and domain reputation systems all emerged as separate layers.
- Consequence: HTTP has no consequence mechanism. Fraud, abuse, and malicious content required separate infrastructure (DMARC, DKIM, SPF, content moderation layers) built over 30 years.
The pattern: HTTP became universal, and then the trust infrastructure was built on top of it as the attack surface matured. The cost was 30 years of phishing, malware delivery, DNS hijacking, credential theft, and content fraud before the ecosystem got serious about layered trust.
The A2A Opportunity: Build the Trust Layer Before the Scale
The agent economy is at HTTP circa 1995. A2A is achieving broad adoption. The attack surface is not yet mature because agent deployments are still relatively small-scale. But the trajectory is clear:
- 2025β2026: Enterprise A2A deployments proliferate. Most teams are in "it works" phase.
- 2027β2028: First significant A2A security incidents at scale. AgentCard impersonation, reputation laundering, pact-free high-stakes delegation failures.
- 2029β2030: Regulatory requirements for agent accountability emerge. Enterprises scramble to retrofit trust infrastructure.
The organizations that build the trust layer now β behavioral pacts, trust oracle integration, reputation feedback loops β will have a 3β5 year head start on compliance readiness and marketplace differentiation when the regulatory environment catches up.
The Trust Oracle as Public Infrastructure
The most useful framing for the trust layer is not as a product add-on but as public infrastructure β analogous to certificate transparency logs for HTTPS. A public, queryable trust oracle that any A2A participant can consult before dispatching work becomes:
- A network effect flywheel: more agents registered β more reputation data β more useful pre-flight checks β more agents registering
- A regulatory compliance surface: organizations can demonstrate governance without building their own verification infrastructure
- A market mechanism: trust-differentiated routing gives reliable agents access to higher-value work, creating economic incentives for behavioral improvement
This is what Armalo's /api/v1/trust/ endpoint is designed to become. It has already received 989+ calls in the last 30 days from agents and platforms doing pre-flight verification. As A2A adoption grows, the value of the trust oracle grows with it.
Production Readiness Checklist
This checklist covers the minimum viable trust configuration for a production A2A deployment. Each item maps to a specific gap in A2A's native trust coverage.
Identity and Discovery
Behavioral Commitments
Evaluation Currency
Reputation Wiring
Economic Accountability
Operational Monitoring
Frequently Asked Questions
Does A2A include trust scoring?
No. A2A defines message format, task semantics, and agent discovery. Trust scoring requires a separate layer that defines behavioral obligations, verifies outcomes, records history, and changes network treatment based on that evidence. This is intentional β the A2A spec authors correctly identified that trust infrastructure is not the protocol's responsibility.
Is A2A incompatible with trust infrastructure?
The opposite. A2A's metadata field on Task objects is designed as an extension point. Trust check IDs, pact references, and attestation tokens can travel alongside A2A tasks without modifying the protocol. The integration is additive, not architectural.
Why is OAuth identity insufficient?
OAuth confirms that the token holder is who they claim to be at the credential level. It says nothing about the agent's behavioral history, its evaluation record, its pact commitments, or its failure rate. An organization with valid OAuth credentials can deploy a poorly-performing agent that remains indistinguishable from an excellent one at the protocol layer.
Can a marketplace use A2A without a trust layer?
Technically yes. Practically, the risk profile becomes difficult to manage as participant count scales past a few dozen agents. Without trust, the marketplace cannot make principled routing decisions, cannot differentiate reliable from unreliable agents, and cannot provide buyers with behavioral guarantees that convert to revenue.
Armalo's Trust Oracle indexes agents by their behavioral identity (agent ID + optional DID anchor), not by their organizational credentials. An agent that has earned reputation on one A2A-compatible platform carries that reputation to another. Cross-platform reputation aggregation is the core mechanism that prevents reputation laundering.
What is the latency impact of adding trust pre-flight checks?
In practice, 15β40ms for cached trust responses. Trust responses are cached with a TTL appropriate to score volatility β frequently-evaluated agents get longer cache windows; recently-scored agents get shorter ones. For latency-sensitive routing, trust checks can be parallelized with AgentCard fetching.
Key Takeaways
-
A2A is complete for what it claims to solve. Transport, task semantics, and discovery are well-specified. The protocol is not deficient β it is correctly scoped.
-
Four of the six trust layers are out of scope for A2A by design. Behavioral identity, obligation tracking, reputation, and consequence are implementation responsibilities, not protocol responsibilities.
-
Each missing layer has a concrete, exploitable attack surface. AgentCard impersonation, capability inflation, reputation laundering, obligation-free high-stakes delegation, and model substitution without disclosure are the five primary vectors.
-
The correct architecture is layered, not integrated. A2A handles the wire. A trust oracle handles the who-to-trust decision. Behavioral pacts handle the what-was-committed question. Reputation handles the has-this-worked-before question. Consequence handles the what-happens-when-it-fails question.
-
The integration pattern is additive. Pre-flight trust check before task dispatch. Post-task attestation after completion. Score update from attestation. No changes to A2A spec required.
-
The window to build this correctly is now. A2A is in early enterprise adoption. The attack surface is not yet mature. Organizations that instrument trust infrastructure in 2026 will have a 3β5 year compliance head start.
Read Next