An agent needs a business boundary
An AI assistant that drafts a response and an agent that can change a customer record carry different operational risks. Before adding another tool, decide which business outcome the agent owns, which records it can access, and which actions it must never take. A useful pilot should make those limits visible to the team responsible for the process.
Separate identity from employee access
NIST’s August 27, 2026 discussion of agent identity warns that shared credentials create accountability gaps. Its practical direction is to give agents identifiable credentials and tightly scoped authority. For a business workflow, that means a dedicated identity with an owner, an expiry policy, and a clear way to revoke access. Use supported delegated authorization where available; avoid handing the agent an employee’s unrestricted login. Authentication identifies the caller. Authorization still has to decide whether that caller may perform this particular action.
Make permission checks part of the tool
OWASP’s MCP Top 10 highlights token exposure, expanding privileges, and insufficient authorization. Translate those risks into explicit tool rules: restrict permitted operations, record sets, and destinations; use scoped, short-lived credentials where supported; and enforce access checks in the connected service. A support agent allowed to read a case should not inherit permission to export the entire customer database. A successful login should never be the only check protecting a tool call.
Treat retrieved instructions as untrusted data
An agent can encounter instructions inside a web page, document, repository file, or tool response. OWASP’s engineering guidance treats these as prompt-injection entry points and recommends isolation and limited network access. Keep external content separate from the trusted workflow policy. Contain execution in an environment with only the files, services, and destinations the task needs. Review connector changes as software changes, including their requested access.
Test the boundary before expanding the workflow
Our suggested readiness exercise is deliberately small: select one internal workflow, document its allowed actions, and test both valid requests and requests that must fail. Try accessing another customer’s record, sending data to an unapproved destination, and continuing after access has been revoked. Record the agent identity, action, target, approval decision, and outcome without copying secrets into logs. Have an operator practise stopping the workflow and investigating the trace. Measure useful completed tasks alongside blocked actions and exceptions; expand the pilot only when the team can explain those results. These controls reduce exposure, but do not guarantee that an agent will always make the right decision.