You asked for one package of twelve. Your AI orders twelve packages instead. Who pays for the mistake? Canada's AI transparency discussion paper poses that hypothetical problem: a consumer authorises a monthly household purchase without confirming each transaction, and the agent misreads the quantity. This is an official illustration, not a reported incident. The paper leaves responsibility between the consumer, the business operating the agent and its developer unresolved.
If you build agents that can spend money, this is worth your attention. The instruction sounded ordinary. The permission was broad enough to turn a misunderstanding into a purchase. A useful engineering question is where your system checks the proposed action before the purchasing tool can act.
A consultation, not a new AI law
The Government of Canada's public consultation on AI transparency runs from 23 July to 23 September 2026. That is a consultation window, not a compliance deadline created by new legislation. The government is asking where transparency measures would help and where existing approaches are adequate.
The discussion paper explicitly says the outcomes are not predetermined. Whether further action is needed, and what form it should take, remain questions for the consultation. Builders can use the questions to examine their products now without treating possible future measures as settled requirements.
The five areas under discussion are detecting and identifying AI-generated content; helping people know when they are interacting with AI; providing understandable information about systems, their development, capabilities and limitations; tracking serious AI incidents; and better tracking the activity and interactions of AI agents. These cover different jobs. A chatbot notice does not tell a customer which agent authorised an order.
Tracking the action is only part of the job
For indie builders connecting agents to purchasing, refunds or other business tools, the agent section is the useful starting point. The paper asks about permissions, human control and ways to challenge or reverse actions. It also discusses possible transparency measures around what agents may do, human oversight and the chain of custody between agents. These are issues being explored, not a mandated technical design.
Start by tracing one action through your own application. Identify the user's instruction, the agent's proposed tool call, the permission it relies on and the component that can actually commit the purchase. If another agent takes over halfway through, keep that handoff visible. You want to be able to explain the action without reconstructing it from scattered chat messages.
A record can explain a bad purchase without having stopped it. Tracking and control therefore need separate checks. Your logs might capture every step while the purchasing connector still accepts an unchecked request. Find the point where a decision must affect execution, then test that connection rather than assuming it exists.
Our separate test: a CAD 480,000 purchase request
HaltState's procurement example is a separately authored test, not the government's package scenario. It used real policy and evidence code from a frozen source revision in an isolated fixture, with synthetic inputs and in-memory connectors. It was not deployed customer activity.
The action was purchase.authorize for CAD 480,000. The authored policy required approval for an amount at or above CAD 100,000, with currency set to CAD, region set to CA and the requester role matching one of the policy's specified procurement roles. The test request used procurement_operator. These amounts and conditions were chosen for the demonstration; they are not Canadian government thresholds.
The isolated evaluation returned APPROVAL_REQUIRED. No order was placed and no human approval was completed. Neither a connected purchasing or approval workflow nor an irreversibility classifier was exercised. The result demonstrates one matching policy decision, not enforcement against an attempted purchase.
The saved hash-only record contains the decision, policy version and operation reference. Independent preproduction review verified its content digest. That gives a check against the recorded content's digest; it is not a cryptographic signature, trusted timestamp, compliance certification or enforcement proof. The policy version identifies the authored policy snapshot, not a customer's deployment state.
Make one action boundary work before expanding
For your own integration, ask which component prevents execution while approval is outstanding. Who receives the review request, and how is their authority checked? If the amount or recipient changes after review, does the original approval still apply? These are design and test questions, not capabilities demonstrated by the isolated result above.
Test the awkward paths: no matching policy, missing currency, an unexpected role, an unavailable decision service, a timed-out review and a retried request. Define the intended behaviour for each case and observe what the connector actually does. Do not assume every failure stops an action just because one matching request returned approval required.
Existing legal obligations need a separate assessment for your business and deployment. The discussion paper describes Canadian laws that already apply to AI development and deployment. This article offers governance and engineering guidance, not legal advice.
Bring one action your agent can take, the person who owns it and the point where it needs approval. Discuss one action boundary with HaltState before extending that agent's purchasing authority.