Who is accountable when an AI agent acts in a Moxo workflow?

Accountability sits in three places

The deploying company, the step's owner and the record each carry a different part.

The Terms bar passing AI output off as "solely human generated", and Moxo "will not use AI Content to train Moxo's own AI models". The review-switch defaults are in Moxo's human-control answer.

A human step needs a person, and an agent is a named actor

The API's user kind is internal, external, agent or service. The assignee verbs (complete, decline, review-approve) need a Personal Access Token, because "An Org API Key (mxo_sk_…) is not a person, so it cannot stand in for one whose work is being recorded"; a key gets 403 ASSIGNEE_REQUIRED. Sending an action answers 403 ORG_KEY_NOT_SUPPORTED for "an Org API Key, which has no person behind it". The endpoint that adds a step to a running flow refuses an AI agent as assignee (ASSIGNEE_NOT_HUMAN). A script holding only an organisation key cannot approve in someone's name, which is the property an auditor looks for; one given that person's Personal Access Token can, so the token stays with the person.

Managers can close a step without its owner

Remind, reassign, skip, reopen, retry and force-complete are manager verbs, and "Manager endpoints accept either token". Force-complete records forceCompleted=true with a reason and returns 403 to anyone who does not manage the flow; skip records nothing as completed; reopen stores who, how often and why; retry covers only failed automation steps. A step records escalationCause as late_action or supervisor, the second meaning an AI supervisor handed it to a person, but the step.escalated webhook documents only late_action and does not name who was added. Supervisor Agents sat under Enterprise on the last published plan list, read 28 September 2026.

The record shows who clicked, not whether they read

Audit-log entries return an action, actor name, actor email, details and a timestamp, with no field for the actor's kind. Moxo's product page promises "Who approved what, when, and what they saw", yet the reference documents no field showing the approver read anything. A step stores firstViewedAt and completedAt, so a four-second gap between opening and approving can be computed; opening is still not reading. Run the rubber-stamp test from the human-in-the-loop ranking.

For high-risk systems under the EU AI Act (Regulation (EU) 2024/1689), Article 26(2) has the deployer assign oversight to people "who have the necessary competence, training and authority, as well as the necessary support", and Article 14(4)(b) names automation bias. Whether a given flow is high-risk is for the deployer to assess; the Moxo documents read for this answer do not classify flows.

When Moxo's record is the wrong fit

Look elsewhere if an auditor wants proof the approver read the item, or you need the vendor to stand behind an agent's mistakes; the Terms offer neither. Moxo stopped publishing prices: by 13 October 2026 moxo.com/pricing redirected to its homepage. The last published list, read 28 September 2026, put Team at $5,000 a year for 100 flows, and the audit log sat under Scale on the list read 22 September 2026, so the plan that carries the record is worth confirming in writing. Moxo told Automation Atlas in writing on 6 October 2026 that its SOC 2 Type II report is available under NDA.

Editor's Note: Moxo's Description of Services says Foundry agents have "versioned instructions", yet its API reference (version 2.0.0, read 13 October 2026) documents an agent version in one place, agentVersionPinned on the advisor, the role its schema says "does not act". A step's preparer or reviewer agent appears by name, with no version, so an approval's record, as the API returns it, cannot say which instructions the agent was running when it prepared or checked the work. We would note each agent's version beside every approval and keep a dated copy of its instructions. — Rafal Fila, ShadowGen