Agent Enforcement

Abstract

As autonomous AI agents begin to transact against real world inventory, the discourse around their safe operation has consolidated under the word "trust." This document argues that trust names an outcome rather than a mechanism, and I propose the term Agent Enforcement to describe the technical layer that constrains, validates, reverses, and registers agent actions at the point of transaction. The term is defined, distinguished from adjacent concepts, and grounded in a taxonomy of observable failure modes.

Definition of Agent Enforcement

Agent Enforcement is the technical mechanism that validates, constrains, reverses, and logs the actions of AI agents transacting against real world inventory. It operates on the premise that no agent action is self-executing: an agent proposes an action, the enforcement mechanism adjudicates it against a set of invariants, and the action commits only if it satisfies them. For actions that commit and are later found invalid, the mechanism guarantees reversibility. Enforcement is therefore not a policy, a score, or a promise. It is code that makes invalid actions either impossible or recoverable.

What agent enforcement is not

Agent Enforcement is distinct from adjacent concepts with which it is commonly conflated. It is not agent identity, which answers who an agent is and whether it is authentic. It is not trust scoring, which interprets an agent’s history into judgment. It is not payment security, which protects the movement of funds and is already built (AP2) with established liability. An agent can be correctly identified, well reputed, and transacting through secure payment rails, and still book twenty rooms it should not book. Identity and reputation govern admission; enforcement governs action.

Failure taxonomy of agents

The necessity of the mechanism is demonstrated by failure modes that no existing mechanism prevents. Using hotel inventory as the illustrative domain: an agent may execute an action at invalid scale (booking twenty rooms where one was intended), against unavailable inventory (booking a room with no vacancy), against nonexistent inventory (booking a room that does not exist), or with malformed completeness (committing a transaction without the details required to fulfill it). Each failure corresponds to a checkable invariant: scale limits, availability validation, existence validation, and completeness validation. This taxonomy generalizes across any domain where agents act on finite, stateful, real world inventory.

Enforcement mechanism

Agent Enforcement comprises three functions:

• Adjudication: every proposed action is checked against domain invariants before it commits.
• Containment: limits bound the blast radius of any single agent or session, so that even a malfunctioning agent can only do bounded damage.
• Reversal: committed actions carry a defined unwind path, so failures that pass adjudication remain recoverable.
• Registration: every adjudicated action, committed or refused, is recorded against the agent that proposed it, producing the history that reversal requires and accountability presumes.

The analog is familiar from card networks, where authorization precedes settlement and reversal follows error; Agent Enforcement applies the same architecture to the behavior of the transacting party rather than to the movement of money.

Implication of agent enforcement

Current commercial activity in agentic commerce concentrates on verifying agents. Almost none of it constrains what verified agents do, or has any idea which agent has a history. Until an enforcement mechanism exists, every merchant exposing inventory to agents is extending unbounded operational credit to software they did not write. The gap is not a trust problem awaiting better sentiment. It is an engineering absence awaiting a build.