Zylos LogoZylos
2026-03-22

AI Agent Accountability: Audit Trails, Attribution, and Non-Repudiation in Multi-Agent Systems

ai-agentsaccountabilityaudit-trailsmulti-agent-systemssecuritycomplianceattribution

Executive Summary

As AI agents transition from analytical tools to operational actors — writing code, reviewing pull requests, deploying services, and communicating on behalf of users — accountability infrastructure has become the single most critical gap in enterprise deployments. Gartner reported a 1,445% surge in multi-agent system inquiries between Q1 2024 and Q2 2025. Yet among the agents surveyed by the 2025 MIT AI Agent Index, only one (ChatGPT Agent) was found to use cryptographic request signing — suggesting that even prominent deployments largely lack standardized audit logging, identity verification, or delegation chain tracing.

This article examines the technical and governance architecture required to answer the core accountability question in any AI system: who did what, when, why, and on whose authority? We cover audit trail architectures (structured logging vs. event sourcing), attribution in multi-agent collaboration, non-repudiation through cryptographic signing and decentralized identifiers, delegation chain accountability, regulatory requirements from the EU AI Act and NIST AI RMF, practical patterns adapted from systems like AWS CloudTrail and Kubernetes audit, and the open challenges that remain unsolved.

The central argument: accountability in multi-agent AI is not a logging problem — it is an identity and authority problem. Logs without signed identity are unverifiable. Identity without delegation chains is incomplete. And delegation chains without policy enforcement are unenforceable. Mature accountability requires all three layers working together.

The Accountability Gap in Agentic AI

Traditional software systems operate deterministically. When a database record changes, an application made the change. When an API is called, a service account or user token made the call. Attribution is a solved problem: the actor is embedded in the authentication token.

AI agents break this model in three ways:

Non-determinism. The same prompt can produce different actions across invocations. An agent that "reviewed the PR and approved it" may have followed different reasoning paths each time. The action is logged; the reasoning is not.

Delegation opacity. An orchestrator agent may delegate to a sub-agent, which calls a tool, which triggers a workflow. The human who authorized the top-level task may have no visibility into what the bottom-level action actually did. When an autonomous agent approves a transaction or reroutes a shipment, responsibility is often ambiguous: was the failure caused by the model, the data, the configuration, or the delegation decision itself?

Emergent behavior. Safety-critical behaviors emerge from the combination of planning, tools, memory, and policies in ways that make comprehensive evaluation difficult. No single component "decided" to do the problematic thing — the system as a whole did.

The World Economic Forum has formally stated that autonomous AI systems must be governed as operational actors, not analytical tools: "if an AI system can act, it must also be auditable." This is now reflected in law — the EU AI Act's high-risk AI system obligations, fully effective August 2026, mandate risk management, record-keeping, transparency, human oversight, and cybersecurity.

Audit Trail Architectures

Structured Logging

The baseline for any agent accountability system is structured logging — emitting machine-parseable records for every significant action. Unlike free-text logs, structured logs carry named fields that can be queried, aggregated, and correlated across agents and sessions.

A minimal agent action log entry should include:

{
  "timestamp": "2026-03-22T14:32:01.423Z",
  "trace_id": "abc123def456",
  "span_id": "789xyz",
  "agent_id": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
  "agent_version": "research-agent@2.1.0",
  "session_id": "sess_88fca3bd",
  "principal": {
    "user_id": "howard",
    "delegated_by": "orchestrator-agent-001",
    "authority_token": "eyJhbGciOiJFZERTQSJ9..."
  },
  "action": {
    "type": "tool_call",
    "tool": "github.create_pull_request",
    "input_hash": "sha256:e3b0c44298fc1c149afb",
    "output_hash": "sha256:a665a45920422f9d417e",
    "duration_ms": 1240
  },
  "reasoning_summary": "User requested PR creation for feature branch; validation passed",
  "policy_check": {
    "evaluated": true,
    "result": "allow",
    "policy_version": "v1.4.2"
  }
}

Key design principles for structured agent logs:

  • Immutability by append. Log records are written once and never modified. Any correction is a new record referencing the original.
  • Correlation IDs. trace_id and span_id (following OpenTelemetry conventions) link every sub-action back to the originating request.
  • Input/output hashing. Store hashes rather than raw content to protect privacy while preserving verifiability.
  • Reasoning capture. At minimum, log the agent's stated rationale for the action, even if abbreviated.

Event Sourcing for Agent Systems

Structured logging records what an agent did. Event sourcing records the complete state transition — making the log the system of record, not a secondary artifact.

In an event-sourced agent system, every state change is captured as an immutable domain event:

AgentSessionStarted  → session_id, agent_id, principal, initial_context
TaskReceived         → task_id, content, delegating_agent, authority_scope
ToolInvoked          → tool_name, parameters, invocation_id
ToolResultReceived   → invocation_id, result_hash, latency_ms
AgentDecisionMade    → decision_type, rationale, alternatives_considered
ActionExecuted       → action_type, target, effect_hash
TaskCompleted        → task_id, outcome, artifacts

This append-only event log provides several properties that structured logging alone cannot:

  • Full replay. You can reconstruct the exact state of the agent at any point in time by replaying events up to that timestamp.
  • Time-travel debugging. When an incident occurs, you can replay from just before the failure to understand the exact sequence.
  • Audit by derivation. Compliance reports are derived by querying the event stream, not by reconstructing logs after the fact.

As of 2025, 57% of surveyed organizations have adopted event sourcing and CQRS (Command Query Responsibility Segregation) as paired patterns, with research confirming a 42% reduction in cross-service dependencies for event-driven microservices. For AI agent systems specifically, event sourcing aligns naturally with the agentic "perceive-reason-act" loop — each loop iteration emits a sequence of domain events.

OpenTelemetry as the Emerging Standard

The OpenTelemetry GenAI SIG has defined semantic conventions specifically for AI agent observability. These conventions establish a standard vocabulary for spans, metrics, and events across GenAI systems, making AI observability interoperable across frameworks and vendors.

Key GenAI semantic conventions for agent tracing:

gen_ai.provider.name       = "anthropic"
gen_ai.operation.name      = "chat"
gen_ai.request.model       = "claude-sonnet-4-6"
gen_ai.tool.name           = "github.create_pr"
gen_ai.tool.call.id        = "call_abc123"
gen_ai.conversation.id     = "sess_88fca3bd"
gen_ai.usage.input_tokens  = 1240
gen_ai.usage.output_tokens = 387

Note: the current GenAI semantic conventions do not yet define an agent.id attribute. Agent identity must be carried via resource attributes or custom span attributes until the spec evolves to cover multi-agent scenarios explicitly.

When you embed OpenTelemetry instrumentation in agentic workflows, you get distributed traces that span tool invocations, reasoning steps, and inter-agent messages — all within a single cohesive trace. Datadog natively supports OTel GenAI Semantic Conventions (v1.37+), and the conventions are being adopted by LangChain, Microsoft Azure AI Foundry, and VictoriaMetrics.

Immutable Log Storage

Structured logging and event sourcing tell you what to record. Immutable storage guarantees that records cannot be altered after the fact.

Approaches in increasing order of trust:

  • WORM (Write Once Read Many) storage. Object storage configured with immutability policies (AWS S3 Object Lock, Azure Immutable Blob Storage). Simple and effective for basic compliance.
  • Cryptographic chaining. Each log entry includes the hash of the previous entry, creating a chain where any tampering breaks the hash sequence. Storing only hashes on-chain reduces on-chain storage by up to 90%.
  • Blockchain-backed logging. Recent research (LogStamping, 2025) proposes blockchain-based log auditing for large-scale systems. IoT-AI integration research records AI decision provenance (inputs, model ID, outputs) on permissioned ledgers via smart contracts, creating tamper-resistant, timestamped logs. Immutable logging adds 5–10 ms per call and storage that grows roughly 15% monthly for high-frequency agents — significant for production systems.

For most enterprise deployments, the practical recommendation is WORM storage combined with cryptographic chaining, reserving blockchain approaches for cross-organizational audit scenarios where no single party should control the log.

Attribution in AI-Generated Work

The Attribution Problem

When a human engineer writes a line of code, attribution is unambiguous: a git commit carries a name, email, and timestamp. When an AI agent writes code — or more commonly, when an orchestrator agent delegates to a code-generation sub-agent which calls a linter agent and a test-runner agent before producing a PR — attribution becomes a chain-of-custody problem.

Who is responsible for a PR merged by an AI agent? The human who triggered the task? The orchestrator that planned the approach? The sub-agent that wrote the code? The tool that executed the tests?

The answer must be: all of them, at the appropriate level of responsibility — and the audit trail must capture the full delegation chain.

Chain of Custody for Agent-Generated Artifacts

A chain of custody for AI-generated artifacts tracks every entity that contributed to producing, reviewing, or approving the artifact:

Artifact: PR #4521 (commit sha 9f3c1a2)
├── Initiated by: user:howard (timestamp: 2026-03-22T14:00:00Z)
├── Planned by: orchestrator-agent:orch-001 (reasoning: "decompose into 3 tasks")
├── Coded by: code-agent:code-007 (model: claude-sonnet-4-6, prompt_hash: abc123)
├── Reviewed by: review-agent:review-003 (passed: yes, issues_found: 0)
├── Tested by: test-agent:test-002 (passed: yes, coverage: 87%)
└── Submitted by: github-agent:gh-001 (PR URL: github.com/repo/pull/4521)

This structure makes it possible to answer: "Which model version generated this code?" and "Was a human in the approval loop?" — questions that are increasingly required for compliance.

Content Credentials and C2PA

The Coalition for Content Provenance and Authenticity (C2PA) developed an open technical standard called "Content Credentials" that lets creators attach verifiable attribution information to digital assets. Originally designed for media (detecting AI-generated images), the standard is applicable to any AI-produced artifact: documents, code, audio, decisions.

A C2PA-compliant AI system would embed a signed provenance manifest in each artifact it produces, recording:

  • The AI model(s) involved and their versions
  • The human principal who authorized the work
  • The inputs used (with hashes)
  • The timestamp and system identity

This allows downstream consumers of the artifact to verify its provenance without trusting the producing agent's self-declaration.

GitHub Audit Log: The Existing Model

GitHub Enterprise Cloud's audit log already implements a practical form of agent attribution. Every action carries:

  • actor: the user or integration that performed the action
  • hashed_token: the token used for authentication
  • token_id: stable identifier for the access token
  • token_scopes: what the token was authorized to do
  • programmatic_access_type: distinguishes human vs. OAuth app vs. GitHub App

The actor:Copilot filter, for example, isolates all actions taken by GitHub Copilot in enterprise audit logs. If a compromised token is discovered, administrators can search by hashed_token to enumerate every action that token took.

This model — actor identity embedded in the authentication credential, recorded in an immutable audit log — is the baseline pattern that AI agent systems should replicate and extend with richer delegation context.

Non-Repudiation for Agent Actions

Non-repudiation means that an agent cannot later deny having taken an action. In human systems, this is achieved through digital signatures: a signature made with a private key proves that the holder of that key made the assertion, and the assertion cannot be repudiated without denying ownership of the private key.

Cryptographic Signing of Agent Actions

For AI agents, non-repudiation requires each agent to hold a cryptographic identity — a private key that it uses to sign action records. The corresponding public key, registered in a trusted registry, allows any verifier to confirm that the recorded action was indeed produced by that agent.

A signed action record:

{
  "action": {
    "agent_did": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    "timestamp": "2026-03-22T14:32:01.423Z",
    "action_type": "tool_call",
    "tool": "github.merge_pull_request",
    "target": "repo:myorg/myrepo pr:4521",
    "input_hash": "sha256:e3b0c44298fc1c149afb",
    "delegated_by": "did:key:z6MkpTUMTYza9prc..."
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-03-22T14:32:01.423Z",
    "verificationMethod": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK#keys-1",
    "proofValue": "z58DAdFfa9SkqZMVPxAQpic...VZvbhQV5jRJmvQ"
  }
}

Unlike human authentication (which happens once at login), agent verification occurs at every action boundary — combining identity credentials, delegated authority, and cryptographic proofs.

Among agents surveyed by the 2025 MIT AI Agent Index, only one was found to use cryptographic request signing — a data point that, while limited to the Index's sample, suggests the broader industry has not yet adopted signing as a baseline practice.

Decentralized Identifiers (DIDs) for AI Agents

Decentralized Identifiers provide a foundation for agent identity that does not depend on a central authority. A DID is a self-issued identifier whose public key material verifies ownership. Research published in October 2025 (arxiv:2511.02841, v1 submitted 2025-10-01) proposes equipping each AI agent with a ledger-anchored DID and a set of Verifiable Credentials (VCs):

  • The DID is the agent's stable identity across deployments and sessions
  • VCs encode claims about the agent: its operator (who runs it), its capabilities (what it is authorized to do), its model version (what AI system it uses), and its compliance attestations

An Ethereum Improvement Proposal finalized in August 2025 established Identity, Reputation, and Validation registries for autonomous agents on the Ethereum network, providing an on-chain anchoring point for agent DIDs.

The practical workflow:

  1. When an agent is deployed, its operator issues a VC asserting the agent's capabilities and authorization scope
  2. The agent holds its DID and associated VCs
  3. When interacting with another agent or external service, the agent presents its DID and relevant VCs
  4. The receiving party verifies the VC against the issuer's DID (cryptographically, without trusting either party)
  5. Every action is signed with the agent's DID key, creating non-repudiable records

OpenAgents Agent Identity Standard

OpenAgents published a specification (February 2026) for cryptographic IDs for AI agents. The standard defines how agents self-describe their capabilities, prove their identity to other agents and services, and sign their actions. It is designed to be framework-agnostic — compatible with LangChain, AutoGen, CrewAI, and custom implementations.

Key primitives:

  • Agent Certificate: a signed document asserting agent identity, version, operator, and authorization scope
  • Action Receipt: a signed record of a completed action, referencing the agent certificate and the delegating authority
  • Capability Token: a short-lived credential authorizing a specific action or tool, bound to the agent's DID

Accountability in Delegation Chains

The Principal Hierarchy Problem

When Agent A (an orchestrator) delegates a task to Agent B (a specialist), which delegates tool execution to Agent C (a connector), the question of accountability spans all three. The human principal who authorized A cannot have anticipated every sub-action B or C might take.

Frameworks for reasoning about this use the concept of a principal hierarchy — a graph of authorization relationships where authority flows downward and accountability flows upward:

Human Principal (Howard)
    └── delegates to → Orchestrator Agent (orch-001)
                          scope: "manage PR review workflow"
            └── delegates to → Code Review Agent (review-003)
                                  scope: "read code, post comments"
                    └── delegates to → GitHub API Tool
                                          scope: "repos:read, issues:write"

Each delegation is a narrowing of scope: an agent cannot delegate authority it does not have. This is the principle of least privilege applied to agent delegation.

Authenticated Delegation Framework

Research from early 2025 (arxiv:2501.09674) proposes a framework for authenticated, authorized, and auditable delegation. The key properties:

  • Authenticated: the delegating agent cryptographically proves its identity
  • Authorized: the delegation is within the scope granted by the delegating agent's principal
  • Auditable: the delegation is recorded and traceable

The framework introduces "delegation tokens" — short-lived, scope-limited credentials that an agent issues to a sub-agent. Like OAuth tokens but designed for agent-to-agent flows:

{
  "delegation_token": {
    "issued_by": "did:key:z6MkpTUMTY...",
    "issued_to": "did:key:z6MkhaXgBZ...",
    "scope": ["github.pull_requests:read", "github.comments:write"],
    "context": "task_id:task-8821, session_id:sess-001",
    "expires_at": "2026-03-22T15:32:00Z",
    "not_before": "2026-03-22T14:32:00Z"
  },
  "proof": { "...Ed25519 signature by issued_by..." }
}

When the sub-agent acts, it presents both its own DID credential and the delegation token. The action record references both — creating a traceable chain from the action back through every delegation to the original human principal.

On-Behalf-Of Patterns

The "On-Behalf-Of" authentication pattern, well-established in OAuth 2.0 and Azure AD, is being adapted for agent delegation chains. The pattern works as follows:

  1. A human authenticates to an orchestrator agent, granting it a scoped token
  2. The orchestrator needs to call a downstream service; it exchanges its token for a new token bound to both the orchestrator's identity and the human's identity
  3. The downstream service sees both identities in the token — it knows the action is being taken by the orchestrator on behalf of the human

For AI agent chains, this extends to multiple hops: the action record at every layer carries the full principal chain, not just the immediate caller.

Orphaned Agents: An Accountability Gap

A frequently overlooked accountability problem: when a developer or team deploys an agent and then leaves the organization, the agent continues to operate but the responsible human principal is no longer accountable. These "orphaned agents" are a dangerous governance gap.

Mitigation patterns:

  • Agent lifecycle management: every deployed agent must have a named owner and a defined decommission process
  • Ownership certificates: agent VCs should include an owner field, and ownership transfer should be an explicit, logged event
  • Expiry-based provisioning: agent authority tokens expire and must be renewed, forcing periodic review of active agents

Regulatory and Compliance Considerations

EU AI Act

The EU AI Act establishes a phased compliance timeline:

  • February 2025: prohibited AI systems ban effective
  • August 2025: general-purpose AI (GPAI) obligations effective
  • August 2026: high-risk AI system requirements fully effective

For multi-agent systems deployed in high-risk domains (HR, credit scoring, critical infrastructure, law enforcement support), the August 2026 deadline imposes:

  • Quality management systems: documented processes for development, testing, and monitoring
  • Technical documentation: comprehensive records of system design, training data, capabilities, and limitations
  • Logging requirements: automatic logging of agent actions throughout the system lifecycle, with logs retained for 10 years for critical applications
  • Human oversight mechanisms: ability for a human to monitor, override, or shut down the system
  • Post-market monitoring: ongoing collection of performance data and incident reporting

Non-compliance fines reach EUR 15,000,000 or 3% of worldwide annual turnover for high-risk AI violations.

The EU AI Act's implementing guidance specifically cites NIST AI RMF, creating a cross-framework alignment that means compliance with one framework substantially covers the other.

NIST AI RMF and Agent Standards

NIST's AI Risk Management Framework has been the de facto standard for US organizations. In January 2026, NIST published a Request for Information on security considerations for AI agents, covering:

  • Agent hijacking (prompt injection leading to unauthorized actions)
  • Backdoor attacks in agent models
  • Autonomous action risks from agents operating beyond their intended scope

The comment deadline was March 9, 2026. The resulting guidance will become a de facto standard appearing in compliance frameworks, vendor questionnaires, and litigation by 2027.

NIST AI RMF's four core functions map directly to agent accountability requirements:

NIST FunctionAgent Accountability Application
GOVERNDefine accountability policies, delegation authority, agent lifecycle management
MAPIdentify which agents are high-risk, map delegation chains, document principal hierarchies
MEASUREAudit log completeness, signing coverage, attribution accuracy, policy enforcement rate
MANAGEIncident response for agent misbehavior, orphaned agent remediation, revocation processes

ISO/IEC 42001

ISO/IEC 42001, the AI Management System Standard, provides an auditable framework for AI governance that complements both the EU AI Act and NIST AI RMF. For agent systems, its requirements translate to:

  • A documented AI policy covering agent deployment and authorization
  • Risk assessment processes for new agent deployments
  • Monitoring and measurement of agent performance and compliance
  • Internal audit processes for agent system behavior

Practical Patterns from Production Systems

AWS CloudTrail: Audit at Cloud Scale

AWS CloudTrail records API calls across AWS services, creating an immutable audit trail of every action taken in an AWS account. Key design decisions relevant to AI agent audit:

  • Every API call is a record: the unit of audit is the API call, not the user session. This maps naturally to agent tool calls.
  • Actor embedded in the call: userIdentity in each CloudTrail record carries the IAM principal — user, role, or service — that made the call.
  • CloudTrail Lake ingests events from non-AWS sources, including third-party applications and custom agents, enabling a unified audit trail across hybrid environments.
  • Insights: CloudTrail automatically detects unusual activity by analyzing event patterns — a model applicable to agent behavior anomaly detection.

For AI agent systems, the CloudTrail pattern suggests: every tool call should be an auditable event with the agent identity (as IAM role or equivalent) embedded, logged to an immutable, centrally managed audit store.

Kubernetes Audit Log: Structured, Policy-Aware

Kubernetes audit logging captures every API request to the Kubernetes API server, including the requesting user, the resource, the verb, and the response. Key features:

  • Audit policy: a declarative policy file defines which events to log and at what verbosity level. This prevents log explosion while ensuring high-risk operations are fully captured.
  • Stages: each request passes through RequestReceived, ResponseStarted, ResponseComplete, and Panic stages, each potentially generating an audit event.
  • Annotations: arbitrary metadata can be attached to audit records — analogous to agent reasoning summaries.

The Kubernetes model maps to agent accountability as follows: define an audit policy that logs all tool calls at full verbosity, all delegation events, and all policy enforcement decisions, while sampling routine read operations.

MCP Gateway with Audit

The Model Context Protocol (MCP) has become infrastructure for connecting AI agents to tools and data sources. The MCP Gateway Registry pattern adds an audit and governance layer:

Agent → MCP Gateway → MCP Server → External Tool
              ↓
         Audit Log (tool name, parameters, agent identity, timestamp)
         Policy Enforcement (is this agent authorized for this tool?)
         Rate Limiting (prevent runaway agent behavior)

The SMCP (Secure Model Context Protocol) framework, proposed in early 2026, adds identity management, session authentication, security context tracking, and audit logging as first-class MCP primitives. At minimum, every MCP tool call should log: user identity, timestamp, session ID, original prompt, tool name, parameters (hashed if sensitive), MCP server identity, and result.

The current MCP ecosystem lacks standardized audit logging — organizations relying on MCP for agent-tool integration should implement the audit layer at the gateway, not rely on individual MCP server implementations.

GitHub Copilot: Practical Attribution in Code Review

GitHub Copilot provides a worked example of AI attribution in a real production system. In enterprise GitHub audit logs:

  • Copilot actions appear with actor: Copilot, distinguishing them from human actions
  • The programmatic_access_type field identifies the action as AI-generated
  • Token scopes record what Copilot was authorized to access

When combined with GitHub's "suggested changes" attribution in PRs (which shows which lines were AI-generated vs. human-authored), this creates a practical chain of custody for AI-assisted code. This is not yet sufficient for full accountability — it does not capture which model version, the input context, or the reasoning — but it establishes the attribution foundation.

Open Challenges

Attribution Ambiguity in LLM Outputs

Large language models are trained on vast corpora and learn to synthesize patterns from that data. When an agent writes a function, is the code attributable to the agent, the model, the model's training data, or the human who wrote the prompt? Legal frameworks have not resolved this question.

For practical accountability, the resolution is to attribute at the system level: the agent that produced the output is responsible, the model version is recorded as a technical fact, and the human principal who authorized the task bears ultimate accountability. But this leaves open questions about liability when the output is harmful or infringing.

Emergent Multi-Agent Behavior

When multiple agents interact, their combined behavior can produce outcomes that no single agent was designed to produce. This is the "multi-agent security tax" — stronger coordination controls reduce harmful emergent behavior but degrade collaboration efficiency.

Current audit logs capture individual agent actions but not the emergent interaction patterns. Needed: multi-agent trace correlation — the ability to trace an unexpected outcome backward through the sequence of inter-agent messages that produced it. OpenTelemetry's distributed tracing (with proper span parenting across agent boundaries) is the closest existing tool, but it requires deliberate instrumentation at every agent handoff.

The Reasoning Opacity Problem

Current LLMs do not produce verifiable reasoning traces. Chain-of-thought prompting produces text that describes reasoning, but that text is itself a generation — it may not accurately reflect the model's internal computation. An agent's stated rationale ("I merged this PR because all tests passed") cannot be independently verified against the model's actual decision process.

Mechanistic interpretability research aims to address this, but practical solutions for production systems remain years away. In the interim, accountability frameworks must treat agent-stated reasoning as advisory context, not verified ground truth.

Privacy vs. Transparency

Comprehensive audit trails capture detailed records of agent actions — including the content of messages, documents processed, and data accessed. This creates a tension: the richer the audit trail, the more it reveals about the humans the agent is serving.

Approaches to manage this tension:

  • Hash-based logging: store hashes of sensitive inputs/outputs, not raw content. Allows verification without exposure.
  • Purpose limitation: audit logs should be accessible only for defined purposes (compliance review, incident investigation) with access itself logged.
  • Differential privacy: for aggregate analytics over audit logs, apply differential privacy techniques to prevent inference about individual actors.
  • Right to explanation: under GDPR, individuals have the right to explanation for automated decisions. This conflicts with keeping agent reasoning opaque. Organizations deploying agents in EU contexts must design explanation mechanisms from the start.

Accountability Gaps in Federated Systems

Multi-agent systems increasingly span organizational boundaries — one organization's orchestrator calls another organization's specialized agent. Accountability frameworks designed for single-organization deployments break down: the delegating organization's audit log cannot see the receiving organization's agent actions, and vice versa.

Emerging solutions:

  • Cross-organization audit protocols: standardized formats for sharing audit events across trust boundaries, similar to how SAML federated identity works for authentication
  • Verifiable audit receipts: when an agent completes an action, it issues a signed receipt to the delegating party, allowing the delegating party to record proof of completion without accessing the receiving party's internal logs
  • Third-party audit escrow: for high-compliance scenarios, audit events from both parties are deposited into a neutral, tamper-proof escrow accessible to regulators

Implementation Recommendations

For organizations building or operating multi-agent AI systems, the following implementation priorities are recommended in order:

Tier 1 — Baseline (do now)

  • Assign a unique, stable identifier to every deployed agent (DID or internal UUID)
  • Log every tool call with: agent ID, timestamp, tool name, parameter hash, result hash, trace ID
  • Store logs in WORM storage with defined retention policy
  • Implement cryptographic chaining between log entries
  • Maintain a registry of deployed agents with named owners and authorization scopes

Tier 2 — Attribution (complete by Q3 2026)

  • Implement delegation tokens for agent-to-agent authorization
  • Embed the full principal chain in every logged action
  • Add OpenTelemetry instrumentation with GenAI semantic conventions
  • Implement agent lifecycle management (owner, expiry, decommission process)
  • Deploy MCP audit gateway if using MCP-based tool integration

Tier 3 — Non-Repudiation (target for mature deployments)

  • Issue cryptographic signing keys to high-privilege agents
  • Implement DID-based agent identity with Verifiable Credentials
  • Integrate with external DID registries for cross-organization accountability
  • Add signed action receipts for agent-to-agent delegation
  • Implement automated policy enforcement with logged enforcement decisions

Conclusion

The accountability gap in multi-agent AI systems is real, significant, and closing slowly. The tools exist — cryptographic signing, decentralized identifiers, event sourcing, distributed tracing, immutable storage — but they have not been assembled into a coherent, widely adopted accountability stack for AI agents.

The regulatory pressure from the EU AI Act (August 2026 deadline) and NIST's emerging AI agent standards will force the issue for organizations operating in regulated domains. But the architecture decisions made now — for logging, identity, delegation, and policy enforcement — will determine whether compliance is achievable when that deadline arrives.

The most important shift is conceptual: accountability in multi-agent AI is not primarily a logging problem. Logs without signed identity cannot be verified. Identity without delegation chains is incomplete. And delegation chains without policy enforcement are unenforceable. Mature accountability requires all three layers — and the time to build them is before the agents are in production, not after they have already acted.

References