
The boundary between content and instruction
An agent reads product descriptions, reviews, documents and web pages it does not control, and those sources can contain text phrased as instructions. Treating that content as valid commands can divert the agent from its task. OWASP includes this attack class, known as prompt injection, among the risks facing LLM applications. [S70]
The boundary matters especially in commerce because information and action are closely connected. A product page may explain warranty terms. It must not independently instruct an agent to ignore other sellers or transmit private customer data. The customer’s assignment and the system’s permissions take precedence over retrieved content.
Connect information and permission clearly
Clear data fields make processing easier. Dimensions, price and delivery date can be retrieved and checked for format. For free-form descriptions, reviews or documents, the system also needs to consider who supplied the content and how it may be used.
The executing system checks permission to act. A product description can explain a feature; permission to purchase comes from the customer’s request. This separation protects the link between information read and the decision an agent is allowed to make.
Principal attack surfaces
| Risk | Commercial consequence | Essential control |
|---|---|---|
| Instructions embedded in content | unauthorised disclosure | treat content as data, constrain outputs |
| False agent identity | abusive access | verified origin and access policy |
| Excessive permissions | wrong order or refund | separate rights, amount and object limits |
| Replayed messages | duplicate or outdated action | freshness, task binding, replay protection |
| Offer substitution | consent differs from execution | fixed offer revision and revalidation |
| Crafted link to an internal system | confidential data retrieved | validate destinations and block internal networks |
| Unbounded loops | cost and load escalation | task budget, timeout, stop state |
Use the table for a shared review by shop development, security and business teams. Each important purchasing route needs suitable access checks, bounded permissions, traceable execution and a way to correct problems.
The right access for the right customer
An agent request belongs to a particular customer and task. The shop checks who is acting, which order is involved and which permissions apply. It is the everyday service question: “For which customer account may we make this change?”
Sender-constrained tokens such as DPoP add protection by binding use of access to a key. Together with checks on customer, resource and action, they provide traceable access to the right task. [S62]
Test security in the real execution path
Use focused counterexamples: read permission attempts a change; an expired offer is confirmed; the same order is retried after a lost response; external product text requests private data. Inspect the resulting commerce state. A correct error message is insufficient if an order was nevertheless created in the background.
Log decisions and effects using a consistent task identifier. Tokens, keys and passwords do not belong in freely readable conversation logs. The objective is accountable operation, not the largest possible collection of sensitive information.
Agent in a Box: a workspace for each project
A workspace for each project makes customization easier. Agent in a Box bundles tools and services for coding agents. Security decisions concern actual mounts, credentials, network routes and write permissions. [S109]
Trust needs a stop control
Merchants need to disable individual capabilities so product advice can continue, for example, during a payment outage. For the suitcase, new orders can stop while delivery updates for existing purchases remain available. The team reviews affected tasks and their states before resuming permitted work. The stop control therefore needs an owner, a clear scope and a traceable restart. Those boundaries belong in the architecture and lead to the next commercial question: does it pay?