AI tool boundaries
AI integration and tool boundaries define what an AI workflow may read, decide, call, change, and report.
Name the business task, permitted operation, expected context, affected record or service, owner, and completion evidence. Separate retrieval, recommendation, drafting, and external action.
The AI consulting and implementation route provides an internal path when tool access must become a delivery decision.
Pass only the context needed for the task. Record the identity under which a tool is called, permitted data, role boundaries, and what the workflow must never access.
Define when a human must review, approve, reject, or stop an action. Make the approval evidence and return path visible.
State what happens when a tool is unavailable, returns incomplete data, times out, or produces an unverifiable result. Record the escalation owner and audit evidence.
Revisit permissions and boundaries when the use case, data, user group, model, prompt, endpoint, or consequence changes.
Use the smallest permission and context that can support the defined task, with a clear owner for exceptions.
Connecting an AI workflow to a business system is the point at which a demonstration becomes a risk. Until then the workflow can only produce text, and a person decides what happens to it. Once the workflow can call a tool, it can look up a customer record, open a change request, send an email or update a status field, sometimes several times in one run and sometimes faster than anyone is watching. The architect's task is to decide, for each system and each operation, how much of that power the workflow should hold. The useful distinction is between reading, recommending, drafting and acting, because each carries a different consequence when it goes wrong.
A read operation exposes information, which matters for confidentiality but can be reversed by restricting access. A recommendation changes nothing until someone accepts it. A draft is a record in waiting, and its risk depends on where it is sent. An action changes the state of a system of record, and in many cases cannot be undone without a manual correction. Most of the design work consists of placing each operation on this scale and then deciding what stands between the workflow and the operations that are hardest to reverse.
The table below is a practical way to sort operations before any connection is built. It describes the tiers and the controls that usually fit each one. The controls are starting points for discussion with the system owner, not a substitute for the owner's own risk assessment.
| Tier | Typical operations | Controls that usually fit | Common mistake |
|---|---|---|---|
| Read, scoped | Retrieve the fields a single task needs | Field-level access, the identity of the calling service recorded, no bulk export | Granting read access to a whole table because the task needs one field from it |
| Recommend | Suggest a category, next step or response | Recommendation stored separately from the record, visible reason given | Writing the recommendation straight into the field that drives a decision |
| Draft | Prepare an email, note, ticket text or report section | Draft held in a queue, marked as generated, approved before sending | Sending drafts on a timer because the queue became a backlog |
| Act, reversible | Add a comment, tag a case or create a task | Logged action, an undo route, rate limits | Treating a reversible action as harmless and failing to log it |
| Act, consequential | Change ownership, approve, pay, close, notify a customer or alter configuration | Human approval before execution, a recorded approver, a stop control | Allowing the workflow to execute because the approval step was optional in testing |
The bottom two rows deserve most of the attention in a review. A consequential action should never sit behind a control that the workflow itself can bypass. If the approval is a flag the workflow sets on its own request, the approval is decorative.
Every tool call runs under an identity, and that identity decides what the call can reach. Many early integrations run under a broad service account because it is the fastest way to make the demonstration work. That account then holds more access than any single task requires, and every log entry shows the same identity regardless of which user or case triggered the call. A better design gives the workflow a narrow identity per tier, passes only the context a task needs and records the requesting user alongside the calling identity.
The workflow should also have an explicit list of things it must never access. Those lists are often more useful than the permission grants, because they are easier to test. Examples include personal data outside the case in hand, credentials, unrelated customer accounts and the configuration of the workflow itself. A test that tries each prohibited access and confirms a refusal is cheap to write and catches a surprising number of gaps.
An approval step is only worth its cost if the approver can see what they are approving, can change it and can refuse it without penalty. Approvals fail in predictable ways. The approver sees only a one-line summary of an action whose consequences are in a linked record they never open. The approval queue grows until people click through it. The approver is a person who requested the action in the first place. The design should show the proposed action, the record it touches, the evidence the workflow relied on and the outcome if the action is refused. The approval itself should be stored with the identity of the approver and the time it was given, so the audit trail shows who decided rather than merely that someone clicked.
Tool failure is a normal case in production, not the exception. A service times out after the first of three updates has been written. A lookup returns a partial list. A downstream system accepts the request and never confirms it. A workflow designed only for success will either repeat the first update, which can duplicate a record, or carry on as if the later updates happened, which leaves the record inconsistent. The design should state, for each consequential operation, whether it can be retried safely, what compensating action is needed if it cannot, and who receives the exception. The audit record should show the attempted operation, its result and any follow-up, so that a person reconstructing the event does not have to infer it from the final state.
Unverifiable results need their own rule. If a tool returns something the workflow cannot check, the correct behavior is usually to stop and route the case, not to present the result as confirmed. A workflow that reports success when it has no evidence of success is a source of false confidence that is hard to unwind.
Boundaries drift. A use case expands from triage to resolution, a new model is substituted because it is cheaper, a prompt is extended to cover another team's requests, or a system owner adds a field that the workflow now picks up. Each change can move an operation to a higher tier without anyone deciding that it should. A simple control is to treat the list of permitted operations as configuration with an owner, and to require a review whenever the use case, the data, the user group, the model, the prompt, the endpoint or the consequence changes.
On ServiceNow platforms the tier model maps onto familiar constructs: scoped access through roles and access controls, integration flows built in Integration Hub or exposed through the REST interface, and approval rules that already hold records of who decided what. The practical risk is that an assisted flow can inherit the broad permissions of the integration user it was built under. The enterprise platform integrations page covers connections between service, identity, customer, finance and asset systems, and the IntegrationHub and API automation page covers controlled orchestration of a business action across systems. Whichever route is used, the choice of identity for each flow should be made before the flow is built rather than after.
Monitoring needs the same discipline. Calls that fail, time out or return unexpected data should reach a named owner. The integration monitoring and error ownership page frames monitoring around telling whether an interface is behaving as expected, what failed and who owns the next decision. The broader question of which AI capabilities the platform should expose at all is the subject of the AI governance and control page, which covers access, approvals, exceptions, monitoring and evidence for AI workflows.
Test it directly. Attempt a request for an adjacent record, a field outside the task and a bulk query, and record what comes back. The test result is more reliable than the permission matrix on paper.
The answer should name a role, a route and a method, such as disabling the tool connection rather than editing the prompt. A stop control that depends on the workflow's own cooperation is not a stop control.
At minimum: the calling identity, the requesting user, the operation, the record affected, the result and any approval. If one of these is missing, the first incident review will be guesswork.
Only for reversible operations whose effects are logged and whose undo route has been tested. For consequential operations the default answer should be no, and any exception should be recorded with its owner and its reason.
If you are planning to connect an AI workflow to a system of record, write down the list of operations you have in mind, the identity each one would run under and the approval you expect a person to give. That list is the input to the tier table above, and the controls attached to each tier must exist before the connection goes live.
Bring the integration, permission, or approval question that needs a clearer operating model.
Discuss AI tool boundariesGuides from the Oblytech ServiceNow library that explain the practice behind this page.