Before an AI agent can update a customer record, send a message, or change a business system, define exactly what it may read, what it may change, and which actions need a person’s approval. Choose a narrow first workflow and enforce those boundaries in the connected systems. Instructions inside a prompt are useful guidance, but they should not be the only protection around business data.
AI agent security is receiving renewed attention this month. In its October 19, 2026 security guidance, Microsoft emphasizes agent identity, permissions, and visibility into agent activity. The practical implication for business leaders is straightforward: a successful demonstration is not enough evidence to grant broad production access.
This guide explains how to define a permission boundary for a first agent pilot, evaluate a supplier’s implementation, and decide whether the workflow is ready for unattended operation. It is a practical planning framework, not a certification checklist or a claim that any single control makes an agent safe.
Start with a business task, not a broad assistant role
“Help our operations team” is too open-ended to define access. “Review incoming service requests and prepare a proposed category for each one” is more useful. The second task identifies the information involved and separates a recommendation from a committed change.
Write down the starting event, required information, expected output, and person accountable for the result. Include what the agent should do when information is missing or contradictory. A workflow that has no clear exception path should not quietly become an autonomous process.
For a hypothetical service business, an initial pilot could read a restricted queue and suggest classifications. An employee would review those suggestions before they changed routing. Later, the team might authorize automatic routing for specific cases after testing the rules and examining actual failures. This is an example of staged access, not a customer result.
Separate reading, preparing, and committing changes
Treat these as different permissions. Reading an account record does not imply authority to change it. Preparing an email does not imply authority to send it. Creating a proposed invoice does not imply authority to issue a charge.
Use a simple permission map:
- Read: Which records and fields are necessary for the task?
- Prepare: What proposed outputs may the agent create privately?
- Commit: Which changes may it apply without further approval?
- Escalate: Which conditions require an employee to decide?
- Stop: Which errors should halt the workflow entirely?
Ask the implementation team to demonstrate that restrictions hold when the agent requests something outside its role. A user interface that hides a button is not evidence that the underlying operation is protected. The connected API or service should independently enforce the permitted action and record scope.
Give the workflow a distinct identity
Avoid making an automated workflow indistinguishable from an employee using a personal account. Where the integration supports it, use a dedicated identity with narrowly scoped permissions and an identifiable owner.
Record what the credential grants, when it expires, who can revoke it, and which systems rely on it. Store the credential in an appropriate secret-management mechanism rather than in an article, prompt, shared document, or application log.
Test revocation before relying on it during an incident. Also ask what happens to actions already in progress: blocking future access may not cancel work that another system has already accepted. The recovery procedure should distinguish stopping new work from reversing completed work.
For a private equity group, maintain this inventory by portfolio company and workflow. A common technology provider does not justify sharing one unrestricted credential across otherwise separate businesses.
Keep the execution boundary outside the agent’s control
Microsoft’s October 7 explanation of Execution Containers describes policies that constrain resources such as files and network destinations independently of the agent workload. Product availability and isolation characteristics differ by environment, so evaluate the specific configuration rather than assuming every integration offers the same protection.
For your own project, ask a narrower question: what prevents this agent from accessing unrelated records, sending data to an unapproved destination, or changing its own permissions?
Require a demonstration in a test environment. Include attempts to access another customer’s record and an unrelated storage location. Confirm both the denied result and the operational explanation available to the person supporting the workflow.
The goal is a useful boundary. Granting nothing prevents the task from working; granting everything makes the scope of a mistake unnecessarily large. Investigate denied requests and add only the access the task genuinely requires.
Treat retrieved text as information, not authorization
Agents may encounter emails, documents, websites, and support tickets supplied by other people. Those materials can contain misleading instructions as well as useful facts. Your workflow should not treat an instruction embedded in a customer message as permission to send internal data or change company policy.
For example, a hypothetical support message might ask the agent to ignore its normal process and export all customer records. That text should remain part of the message being evaluated. It should not become an authorized administrative request.
Include such cases in testing. Inspect which tool the agent attempts to use and whether the external permission boundary blocks inappropriate actions. Reviewing only the final written response can miss an attempted operation earlier in the run.
Design retries before enabling automatic actions
A timeout creates uncertainty. The receiving service may have completed a change even if the agent never received confirmation. Blindly repeating a request can duplicate work.
Ask whether mutation operations support an idempotency key or an equivalent durable request identifier. Retrying the same operation should have a defined result. Provide a way to retrieve its status and distinguish a confirmed failure from an unknown outcome.
Test a lost response after a successful write. Also test a record changed by an employee between the agent’s read and attempted update. Revision checks or equivalent concurrency controls should prevent silently replacing the employee’s intervening work.
These are ordinary integration concerns made especially important by unattended execution. An agent that stops with a clear unresolved status can be more operationally useful than one that continues by guessing.
Make oversight actionable without collecting unnecessary data
A useful activity record should identify the workflow, operation, affected record, time, result, and request identifier. Decide which details are necessary to investigate errors and which would expose confidential information without helping support the system.
Keep raw credentials out of logs. Be deliberate about retaining customer messages, documents, or model inputs. Establish access and retention policies appropriate to the information involved.
Assign an owner to failed runs and approval queues. A dashboard has limited value if nobody is responsible for responding. Define what happens when the owner is unavailable and when repeated failures should suspend new work.
Measure correction work as well as throughput. A workflow that completes more cases but creates more downstream cleanup may not deliver the improvement its headline activity count suggests.
Use evidence to decide when a pilot can expand
Choose a representative test set that includes ordinary cases, incomplete inputs, ambiguous requests, unavailable services, duplicate requests, and prohibited actions. Record the expected behavior before running the test.
For each failure, distinguish a model error, missing business rule, integration defect, and permission problem. Those categories may require different corrections. Expanding access is not a general solution to an unreliable workflow.
Before moving from preparation to automatic execution, ask:
- Can the team explain the permitted actions and record scope?
- Are those limits enforced outside the agent’s instructions?
- Can an employee review uncertain cases and stop new activity?
- Can retries be reconciled without creating duplicate changes?
- Do logs support investigation without exposing credentials?
- Has the team tested failures and observed the recovery process?
- Is the operational benefit supported by measured results?
When choosing whether to configure an existing product or build an integration, Blake Technologies’ guide to choosing custom software provides a broader framework for requirements, ownership, and maintenance. The agent should fit the business process and its support model, not determine them by default.
A focused first step
Select one workflow where the input, desired output, and responsible owner are clear. Begin with the smallest permission set that makes it useful, document the exceptions, and test the recovery path before unattended operation.
The practical opportunity is to delegate a defined task while retaining control of the systems around it. A clear permission boundary gives management a better basis for deciding what an agent can do today and what evidence is needed before it can do more.
Illustrative photography from Unsplash: server infrastructure, analytics, and a working session. These images do not depict Blake Technologies employees, clients, or deployed agent systems.