An August 19 AWS Security Blog post describes patterns for propagating user authorization context through AI agents built with Amazon Bedrock AgentCore. Its example uses one CRM chat experience for sales and finance employees. Both groups can work through the same agent, but sales should reach only the customer contracts, pricing and pipeline data within its scope, while finance should reach the relevant invoice, payment and financial records. AWS states the architectural principle clearly: the agent acts as an orchestrator, not an access gatekeeper. Identity infrastructure and downstream systems decide what the requester is allowed to see.

A shared interface must not become shared permission

Export companies naturally want one AI entry point across international sales, order coordination, supply chain and finance. The dangerous implementation gives the agent a powerful service account and relies on a prompt such as “never reveal sensitive information.” Prompt instructions are not a durable security boundary. A prompt injection, tool-routing error or defective filter can place the full connected dataset within reach.

Authenticate the person first and propagate relevant attributes into every downstream request. Those attributes might include department, role, region, project, account ownership or legal entity. A salesperson retrieving a quotation history should not inherit access to another team's pricing strategy. A coordinator checking a shipment date should not automatically see unrelated payment records.

The same rule applies when external distributors, agencies or temporary project staff use an assistant. Their access needs an explicit scope and expiry rather than an informal assumption based on which chat channel they entered.

Put the denial decision in the system of record

CRM sharing rules, database policies, document permissions and SaaS access controls should reject an unauthorized request even if the agent asks for it. AWS's reference design includes user-scoped temporary credentials, attribute-based access control and on-behalf-of token exchange so that downstream services continue to apply their existing rules.

An exporter does not have to copy a particular cloud stack to apply the principle. The agent should avoid storing long-lived plain-text credentials. Each tool call should receive only the temporary scope required for the current task. When infrastructure-level enforcement is unavailable, application filtering can supplement the design, but the limitation, owner and test method should be documented.

Do not let retrieval scope and action scope collapse into one permission. A user may be able to read an order status without being able to change it, or view a quotation without exporting the entire customer list. Separate read, write, approve and bulk-export privileges.

Preserve evidence for sensitive tool calls

For each sensitive request, retain enough evidence to answer: who initiated it, under which role, which system and object were addressed, what authorization scope was applied and whether the operation succeeded or was denied. The log should avoid unnecessary customer secrets while still supporting investigation and accountability.

Actions such as changing a quotation, sending an external email, updating payment status or releasing a document need additional controls. Require explicit confirmation, record the proposed change and read the system of record after writing. A successful API response is not enough if the wrong account or object was modified.

Test the negative cases. A sales user asking for a finance-only record should receive a real downstream denial, not an empty answer generated by an interface filter. A user whose project access has expired should be blocked even if a previous conversation still contains references to the project.

What this means for Chinese exporters

The value of an export agent comes from coordinating information across systems, but the wider the reach, the less acceptable an informal permission model becomes. Customer pricing, contracts, samples, shipment evidence and collections belong to different responsibility domains. Concentrating all access in one agent account makes efficiency and exposure grow together.

Management should treat agent authorization as part of role and data governance, not as a prompt-engineering detail. Access must change when a person joins, changes region, leaves a project or exits the company. The operating owner should be clear before the first sensitive system is connected.

Action checklist

Sources