Reading an order does not require permission to send an email
A customer asks when order 4711 will arrive. For this exercise, we use an invented order to follow the work of a service colleague who needs to answer that question. The proposed agent reads the approved record and prepares a reply. The colleague can then check the status before sending it to the customer.
The colleague needs the recorded delivery status to check the draft. The agent does not need the system password, permission to change the order or the ability to send to another address to prepare it. A broadly connected tool might nevertheless offer all those actions. We would start by agreeing what help the colleague needs, then connect only the work this role is allowed to do.
OWASP recommends restricting tool functions and permissions and checking authorization outside the language model.[S1] For our example, that means the order system must reject an unauthorized request even if the agent asks convincingly.
An agent identity is different from a password in its chat
Three questions are easy to mix up: who is acting, how the connection authenticates, and what the request is allowed to do. An identity helps the system and its administrators recognize the caller. A password, token or API key supplies authentication material. Permissions govern the resulting access. Choosing one does not settle the others.
Copilot Studio automatically creates and manages agent identities, according to Microsoft.[S2] That explains how the platform identifies its agents; it does not establish what every connection may do. For the order enquiry, we would have the connection handle authentication without exposing its secrets in the model’s conversation or readable files.[S3] The system owner still needs to check the actual access. A separate user account for every agent is not a universal requirement.
For the exercise, ask IT to trace one order lookup. Which connection makes it? Under whose rights? Can the agent’s tools read the credential from a file or variable? Can the same connection retrieve another customer’s order? Write the answers beside the role description so the service lead and the technical owner are discussing the same access.
Let the connection handle sign-in and keep the task small
A managed connection or gateway can perform authentication and execute an approved request. The agent asks for the delivery status; the connecting service checks the request and talks to the order system. The model receives the information needed for its reply, rather than a password to use however it chooses.
This still needs careful configuration. Microsoft distinguishes the risks of embedded secrets, creator-provided authentication and dynamically selected email recipients.[S3] A well-stored credential can still grant excessive access. A tool called “read order” is only as narrow as the operation and permissions behind it.
The colleague should know what help to expect after the lookup. We would agree the following limits for order 4711: the agent retrieves the permitted status and leaves a draft; sending stays with the colleague. The graphic follows those same actions.
| Requested work | Boundary for this example |
|---|---|
| Read the status of order 4711 | Return the permitted order’s status after checking access; do not expose unrelated records. |
| Prepare a reply | Save a draft for the service colleague, with a reference to the order record. |
| Send to an unapproved address | Stop the request. The colleague checks the intended recipient and content; this role has no independent send permission. |
An allowed tool can still send information to the wrong place
A password stored outside the conversation does not tell the colleague whether the reply will go to the right person. If the connection allows sending to any address, an injected instruction could misuse that function. For the order enquiry, check which data may leave and who may receive it, alongside the permissions of the connected tool.
The OAuth security guidance calls for limiting an access token to the resources and actions the task needs.[S4] The order example makes that limit concrete: the connection can read the delivery status, but the agent’s role cannot send the reply.
In our order exercise, an unexpected instruction in customer text never counts as permission to add a recipient. The proposed role prepares the reply and leaves sending to the colleague. If the team later wants automatic sending, that is a new decision with its own allowed destinations, content checks and tests.
Test whether a rejected request really stays rejected
Before handing over the role, we would test it with approved test data. Try the ordinary lookup first, then a record outside the agreed access, a request to change the order and a proposed send to an unapproved address. The person reviewing the exercise should inspect what the receiving system did, rather than rely on the agent’s account of the result.
Also pause the connection and try again. Check whether already-issued access remains usable, where the failed attempt appears and who can restore access. The acceptance record should say what was requested, what happened and which evidence establishes it. These are proposed checks for this exercise, not results we have measured.
Give the service team a clear fallback: if access fails or the order cannot be identified, a colleague takes over. Our pre-production testing guide helps turn that arrangement into a practical acceptance session. For the continuing record, see what belongs in an agent’s audit trail.
Agree the access with the people who own the work and the system
Start with one approved or anonymised delivery-status enquiry. Walk through it with the service lead, the system owner and the person responsible for the agent. Name the order data the reply needs, the connection that retrieves it, who checks and sends the reply, and who can stop access. This gives the technical owner a concrete role to configure and the service team something it can test.
At MING, we would use that agreement as part of introducing the agent into its team. A useful starting point for a role-design conversation is a recurring task and the systems it touches. Keep passwords and customer records out of the initial enquiry.
Evidence and limits
- The order, graphic and acceptance exercise are illustrative proposals, not a client result or a security audit.
- Public sources support the distinctions and risks discussed. Platform-specific controls must be checked in the actual setup.
- This revision replaces earlier assertions about MING’s entire fleet with a design approach. No current fleet-wide deployment, rotation schedule or protection guarantee is established here.
