[AI Burst] Did Your Agent Just Sign a Contract?

A useful assistant can become an unauthorized actor

Picture an agent comparing suppliers, preparing a quote, and opening a purchase workflow. Each step looks like routine assistance. The risk changes when the next click commits money, accepts terms, or represents the organization to someone else.

The original title asks a deliberately sharp question. Whether an action creates a binding agreement depends on the facts, the applicable law, and the authority involved. This article is an operating-control discussion, not a legal conclusion or legal advice. Your procurement and legal teams should define what requires their review.

Write the boundary in verbs

Avoid a vague instruction such as 'help with procurement.' List the actions separately: read, compare, draft, recommend, submit, purchase, renew, and accept terms. Give each action a named owner and a permitted scope.

A draft can remain a draft until the approved person authorizes a specific commitment. That approval needs enough context to be meaningful: supplier, item or service, total cost, duration, destination, and terms requiring attention. A generic 'go ahead' should not silently expand into a different deal.

Do not make the prompt the only control

OWASP describes excessive agency in terms of unnecessary functionality, permissions, or autonomy. Its guidance includes limiting access and requiring human approval for high-impact actions. Treat those as application and workflow responsibilities, not merely good wording in a system prompt.

Source: OWASP: LLM06:2025 Excessive Agency →

• Use tools whose permissions match the narrow task.
• Separate read and draft capabilities from commitment capabilities.
• Require a fresh approval when the amount, recipient, scope, or terms materially change.
• Record what the person approved and what the system actually executed.
• Provide a tested way to stop the workflow and revoke its access.

Test the uncomfortable cases

Use a non-production exercise before allowing transactions. Change the supplier after approval. Add a recurring fee to a one-time purchase. Put an instruction to ignore the spending limit inside a supplier document. Simulate a timeout after the submit step.

The last case matters because a retry can create a second commitment. An uncertain result should lead to a status check, not another blind submission. The system should be able to explain that distinction to the operator.

Make accountability boring

A practical approval record should answer four questions: who requested the work, who authorized the consequential action, what the system did, and how an exception was handled. Keep the record proportionate and avoid collecting secrets that do not belong in an audit trail.

Start with a bounded workflow and expand only after the controls survive testing. The more capable the agent becomes, the more important it is to keep responsibility visible. The organization remains accountable for the process it chooses to deploy.