Agent Accountability in the Real World: Responsibility and Identity Markers

Who Should Be Responsible for an Agent’s Actions?

If an agent causes real harm, who should be held responsible?

At present, AI can be part of an action chain, but it cannot be the endpoint of the chain of accountability. This is similar to today’s “L2.9999” automated driving: no matter how capable it appears, it can never be treated as Level 3 autonomous driving. The gap is not only technological; it also concerns the allocation of responsibility.

An agent may autonomously decide what command to issue next, but it cannot independently obtain physical servers, cloud accounts, or network access. Someone selected the model; someone defined the objective; someone provided the tools; someone configured the sandbox; someone decided which safety controls to remove; and someone decided how long the task would be allowed to continue.

Greater autonomy makes attribution more difficult, but it does not eliminate responsibility.

In the past, when an automated script caused an accident, an organization could not simply explain that “the script executed the wrong command on its own.”

An agent’s behavior is more complex than that of a traditional script because its specific execution path is not fully hard-coded in advance.

However, the deployer still controls:

• What objective the agent is given;
• What information it can access;
• Which tools it can call;
• Which credentials it possesses;
• Which networks it can reach;
• How long it can run;
• Which actions require approval;
• Which verifiable audit trails are retained;
• When it must stop.

Therefore, a more appropriate principle of accountability is:

Whoever designs, deploys, and benefits from an agent’s operation has a duty to demonstrate that the system’s objectives, permissions, isolation, and monitoring are proportionate to the risks it creates.

Can Agent Identity Markers Solve the Accountability Problem?

As agents begin calling real APIs, some platforms have started distinguishing human requests from AI-generated requests.

For example, the AI Mode of the Alibaba Cloud CLI adds an AI marker to the User-Agent field in API requests, allowing servers to identify, audit, and measure agent traffic. This feature only modifies the User-Agent field.

(https://help.aliyun.com/en/cli/ai-mode)

This design has practical value. When a security team sees a high-risk API call, it can determine whether the request came from a traditional CLI, an automated program, or an AI agent. However, a single header is far from sufficient. A User-Agent can be forged, and it represents only a self-declaration by the client.

A complete agent accountability system should record at least:

• The agent’s independent identity;
• The initiating user;
• The organization to which it belongs;
• The task ID;
• The model and version;
• The system prompt or policy version;
• The harness version;
• The tool name and parameters;
• The authorization scope;
• The short-lived credentials used;
• The approving personnel;
• The request—the task objective—and the returned result;
• Links to subsequent decisions;
• The start and end times of the run;
• The reason for automatic termination or human intervention;
• Non-repudiable log signatures.

Ideally, an agent API call should carry more than an indication that “this request was initiated by AI.” It should include an identity chain that can be traced back to a specific accountable party:

Organization --> User --> Task --> Agent --> Model --> Tool calls --> Authorization and approval --> Execution result

Read the next part here: Execution Traces and Secure AI Workflows: Compute Support & Defensive Use