A Useful AI Workflow Needs Boundaries, Not Full Access
By Ryan Clement · Published
When I evaluate an AI capability, I am interested in more than what it can produce.
How I approach the data, permissions, integrations, and human decisions behind the task
I want to understand what information it can access, which actions it can take, and what happens when the task reaches a point that requires a person’s judgment.
That is why a detail in Microsoft’s September 23 Dynamics 365 announcement caught my attention. Microsoft described planned role-based controls that would place additional restrictions on what agents can do when operating on a user’s behalf through Copilot Cowork or other agents. These are forthcoming Dynamics 365 capabilities—not a universal folder-by-folder control across Microsoft 365. But the principle is important: a person’s access does not have to become an agent’s unrestricted authority.
That distinction connects directly to how I approach AI workflow integration.
My work includes Python-based data processing, reusable research and portfolio-analysis workflows, and applications developed with AI-assisted coding and external research APIs. Across those projects, I keep coming back to the same question:
What does this part of the process need to do—and what should remain outside its responsibility?
I separate the work before connecting the tools
In my portfolio-prioritization work, I bring together information such as relationship activity, giving history, open opportunities, and follow-up gaps. The purpose is not to produce another long report. It is to help someone decide where to focus and understand the evidence behind that recommendation.
That requires several different kinds of work.
I have built Python pipelines that combine CRM exports with additional data, apply defined scoring and segmentation rules, and prepare files for analysis. I then use AI to help interpret those signals, organize the findings, and develop proposed next steps.
The distinction matters. I do not need a language model to reinvent a calculation every time I run a report.
When a rule is explicit—calculate elapsed time, total a set of records, or apply an agreed scoring weight—I prefer to make that logic visible in code. Code still needs testing, but the calculation can be inspected and rerun.
The AI-assisted portion has a different job: connecting information, explaining patterns, and preparing recommendations for review.
I want the calculation to be reproducible and the recommendation to be explainable.
Working from exports also makes the data boundary concrete. An export is a snapshot, not a live connection. I need to know when it was created and what may have changed since then. A workflow should not describe an old file as current simply because the analysis was generated today.
I treat instructions and permissions as different controls
I use ChatGPT Projects and reusable workflow instructions to keep recurring research, portfolio strategy, and operational analysis organized. That gives me a defined process to improve instead of starting with a blank conversation every time.
But written instructions and technical permissions serve different purposes.
“Use only this folder” tells an agent what I intend. It does not, by itself, establish which folders the system can technically access.
OpenAI’s Codex documentation makes this distinction explicit: the sandbox controls what commands can access or change, while the approval policy determines when the agent must pause and ask. Workspace write restrictions, network access, and approvals are related controls, but they are not interchangeable.
The same care is necessary with connected business applications.
For example, ChatGPT’s SharePoint controls can restrict access to specified site collections. Those controls do not provide individual-folder or file-level scoping, and they do not automatically restrict OneDrive. A configuration that selects content for indexing also should not be assumed to restrict a separate live connection.
Anthropic’s Cowork guidance likewise recommends being selective about local file access and considering a dedicated working folder rather than granting broad access.
These are useful capabilities, but they do not mean every platform implements the same boundary.
My starting point is to separate three decisions: what the agent may read, what it may change, and what requires approval. Then the configuration needs to be checked against those decisions.
If a platform cannot enforce the required boundary, I would narrow the design, use a separately prepared working dataset, or leave that action manual. I would not describe a prompt as a security control it cannot provide.
Integration does not have to mean automatic action
In my independent application development, I have used Codex to help build and test workflows that connect structured inputs, external research through the Perplexity API, and printable research outputs.
The API connection is useful because it makes research a defined part of the application rather than a series of disconnected copy-and-paste tasks.
But retrieving information, preparing a recommendation, and acting on that recommendation are separate steps.
A research application can help prepare someone for a conversation without contacting anyone. A portfolio workflow can suggest a priority without changing the official relationship stage. A reporting process can produce a draft without emailing it to leadership.
For a hypothetical monthly sales briefing, I would define the boundaries before choosing the automation:
Source information: Use the designated CRM export and supporting documents, with a clear reporting date.
Processing: Validate required fields and apply agreed calculations without changing the original records.
Draft output: Create a separate briefing containing the findings, supporting evidence, and unresolved questions.
External action: Require a person’s approval before distributing the briefing or updating the source system.
Those are requirements to implement and test, not permissions created by putting the table into a prompt.
Unrelated SharePoint sites, OneDrive folders, and Outlook conversations would not belong in that task simply because the employee can access them.
Connecting an application should solve a defined problem, not quietly expand the assignment.
I build the evidence trail alongside the output
Access controls are essential, but they do not make an answer accurate.
An agent can stay inside an approved folder and still misread a spreadsheet, rely on an outdated document, or reach a conclusion the evidence does not support. Anthropic’s guidance recommends allowing uncertainty, grounding answers in source material, and verifying claims with citations—while explicitly noting that these measures do not eliminate hallucinations.
That is why source verification and conflicting-information handling have been part of my research-workflow development.
I want to distinguish what the record says from what the analysis suggests.
For example, these statements are not equivalent:
“The record contains no recent documented contact.”
“The person is no longer interested.”
The first describes the available data. The second interprets someone’s intentions. Missing documentation does not establish that conclusion.
A useful workflow should preserve that distinction rather than turn an information gap into a confident recommendation.
The same standard applies to external research. A source link should let the reviewer check the claim, not merely make the report look well-supported. If the sources disagree, I want that disagreement visible. If the search does not establish a fact, the output should say so.
Defensible work includes knowing where the evidence stops.
I want to know how the workflow behaves when something goes wrong
A clean example shows that a process can work. Before relying on it, I also want to understand its failure behavior.
What happens when a required column disappears from the next export? When two records have similar names? When a research service returns no useful result? When the source file is older than expected?
These are practical questions for a test plan. The expected response should be defined: stop, flag the affected record, request clarification, or continue with a clearly stated limitation.
I apply the same thinking to permissions. Using approved test files, the system should demonstrate that it can reach the intended source and cannot reach a source outside the allowed scope. OpenAI’s SharePoint guidance explicitly recommends testing allowed and blocked content rather than treating a saved policy as proof that access behaves as intended.
I also want to distinguish a failed lookup from a completed task. A report should not look finished merely because the application produced a file.
That is part of the work behind an integration: making the exceptions understandable to the person who has to handle them.
The workflow still needs to belong to the people using it
I have created reusable workflows and trained colleagues on source verification, responsible data handling, and human review. That experience keeps the handoff central to how I think about implementation.
Someone needs to know which inputs to provide, how to recognize a problem, what to verify, and who approves the next step. They should not need to reconstruct the process from a collection of old chats.
My standard for documentation is practical: could the person responsible run the workflow, explain the result, and recognize when not to rely on it?
I would also evaluate the whole task—not just how quickly AI generates the first draft. Preparation, verification, corrections, and maintenance all belong in the assessment. A faster draft is useful only when it improves the work that follows.
The part of AI integration that interests me most is not how many applications an agent can connect to. It is whether those connections form a process someone can understand and responsibly use.
The goal is not an agent that can do everything. It is a workflow that does the right work, with the right information, within boundaries the people responsible can explain.