Sales teams want to use an AI Agent to retrieve historical quotations, procurement teams want it to organize supplier data, and customer service teams want it to access customer records. During proof-of-concept testing, teams focus on the quality of its responses. Once preparations for production deployment begin, however, managers face a different set of questions: Which systems may the AI Agent connect to? Whose data may it access? Is it allowed to modify content? And if something goes wrong, where should the investigation begin?
If governance requirements are added only after development is complete, IT and information security teams can do little more than layer restrictions onto the existing design. Business teams may also mistake the convenience of the testing phase for a production requirement. We therefore recommend defining connectivity, permission, and audit requirements before deployment—and keeping the scope of the initial rollout deliberately narrow. Internal data should initially be read-only, external domains should be permitted only after individual review, and every operation should leave a verifiable record.
Restrict Which Data an AI Agent Can Access Before Deciding Which Operations It May Perform
Chimei Hospital’s approach offers a valuable reference. The hospital began building its data analytics capabilities in 2005 and subsequently invested in disease risk prediction and generative AI–enabled documentation workflows before gradually moving toward AI Agent. However, its AI Agent has not yet been formally deployed because its data governance and secure execution environment still require further strengthening. The hospital uses a “lobster tank” as a metaphor for a secure sandbox—an environment in which programs operate under restrictions so they cannot directly affect production systems or access data they should not be able to reach.
Enterprises can begin by creating two lists. The first should identify data sources, including order databases, quotation files, supplier information, and customer service records. The second should identify the operations an AI Agent may perform, such as searching, downloading, sending, creating drafts, and writing to systems. Allowing an AI Agent to read data does not mean permitting bulk exports. Allowing it to draft a quotation does not mean allowing it to send that quotation directly to a customer. By listing data sources and operational permissions separately, managers can clearly identify where the risks lie.
For the initial rollout, read and write access should be separated. The AI Agent can first be assigned to query internal data, summarize differences, and generate drafts for employees to review. Changes to master data, price approvals, purchase order submissions, and customer status updates should continue to be handled through existing systems and approval workflows. External connectivity should not be enabled all at once. Instead, every required domain should be listed individually, together with its purpose and responsible owner. Any connection not included on the approved list should be denied.
As part of the deployment review, the project team should first be required to provide three lists: data sources, permitted operations, and external domains. The system should then be tested with actual user accounts to verify that it blocks unauthorized access and prohibited write operations. If the team cannot clearly define these three lists, it should not expand the scope of the system’s capabilities.
Permissions Must Not Exist Only in Prompts; They Must Reflect Roles and Organizational Responsibilities
If a rule such as “users may only view data from their own department” exists only in a prompt, it remains merely a textual instruction for the model. It cannot replace authentication and system-level permissions. Enterprises must first answer three categories of questions: Who may use each AI Agent? Which departments’ data may each AI Agent access? And who may modify connectivity and back-end settings? If all three types of permissions are concentrated in a single administrator account, it will be difficult to determine whether an incident resulted from a business requirement, an operational error, or an improper configuration change.
Consider a quotation workflow. Sales representatives may retrieve historical orders for the customers they manage and create drafts, while sales managers may view cases within their business unit. IT is responsible for configuring connections, and information security is responsible for reviewing anomalous activity. The same principle can be applied to procurement price comparisons: each employee should only be able to view designated suppliers and items. Sharing the same AI Agent across business units should not automatically expose the contract terms of other units. These rules must be implemented through accounts, roles, and data scopes rather than relying on users to remind the AI Agent during every conversation.
IT, information security, and business owners should jointly create a role matrix that specifies which features each role may use, which data it may view, which settings it may modify, and whose approval is required. In addition to confirming that normal workflows function correctly, the team should conduct negative testing by simulating scenarios in which a user’s department does not meet authorization requirements, an account has been disabled, or a user attempts to access unauthorized data. Permissions should be expanded gradually based on actual business needs only after the system has been verified to reject these operations.
Keeping Records Is Not Enough—You Must Be Able to Determine Who Did What
When an AI Agent makes an error, retaining only the final document is not enough to investigate what happened. Enterprises must also be able to determine which user initiated the task, which data the AI Agent accessed, which tools it called, when the system denied an operation, and who modified permissions. If audit records can be freely deleted or altered—or if someone can download them without leaving a trace—information security and internal audit teams will still be unable to reconstruct the sequence of events.
Chimei Hospital is exploring a division of responsibilities in which an AI Agent first understands and plans a task, after which robotic process automation (RPA) performs predefined operations. Enterprises can use the same approach to allocate responsibilities: the AI Agent organizes information and recommends next steps, while RPA performs only preconfigured operations with predictable outcomes. For tasks involving payments, price approvals, changes to customer master data, or external communications, the workflow pauses and waits for confirmation from the responsible person. Enterprises do not need to allow an AI Agent to modify production systems directly as soon as it understands a task.
EgentWrX can enforce these restrictions through a unified management framework. An AI Agent can access databases through the corporate intranet, while connections to internal databases can be configured as read-only. External domains can be reviewed and approved individually. Front-end and back-end permissions are managed separately, allowing administrators to restrict features and data scopes by business unit and custom role. Audit logs can be searched and exported, while a hash chain can verify whether records have been altered. Even when an administrator downloads audit records, that action is itself logged. These mechanisms allow enterprises to impose operational restrictions and inspect records in practice, but each enterprise must still decide which workflows to enable and who is responsible for approving them.
Before production deployment, enterprises should define which records information security or internal audit teams will review weekly and monthly. At a minimum, these reviews should cover AI Agent execution activity, permission changes, and audit data downloads. Deactivation criteria, notification recipients, and investigation procedures should also be clearly documented. Only after the team can use the records to answer “who did what, when, and with which permission” should it consider enabling another data source or write operation.
FAQ
Should databases initially be configured as read-only?
For the initial rollout, we recommend using read-only access so the AI Agent can query, compare, and organize data. Operations such as modifying master data, approving prices, or submitting documents should continue to be handled by existing systems. After the team completes testing and risk reviews, write access can be evaluated one operation at a time. Do not grant access to the entire database all at once.
Can prompt-based restrictions on an AI Agent replace system permissions?
No. Prompts can communicate operating rules to an AI Agent, but they cannot replace system permissions governing accounts, roles, and data scopes. Enterprises should manage data visibility, feature access, and back-end configuration permissions separately. They should also test the system with unauthorized accounts to verify that access is denied, preventing a mismatch between the rules stated in prompts and the permissions actually enforced.
Which operations should require human confirmation?
For operations involving payments, price approvals, changes to production data, external communications, or cross-departmental disclosure of information, the workflow should pause for confirmation from the responsible person. Enterprises can define human approval checkpoints based on transaction value, data sensitivity, and scope of impact. They should also specify who is authorized to approve an operation and who is responsible for handling exceptions.
What information should an audit log contain at a minimum?
At a minimum, an audit log should record the person who initiated the task, execution time, data and tools used, permission changes, failed or denied operations, and downloads of audit data. Information security or internal audit teams should also conduct regular reviews to confirm that records cannot be altered freely and to ensure that relevant permissions can be revoked immediately and an investigation initiated when unauthorized activity is detected.
References
- From AI-Assisted Operations to AI-First: Chimei Hospital Unveils Its Four-Stage AI Development Roadmap — iThome reports on Chimei Hospital’s AI development path, its AI Agent plans, and the secure sandbox prerequisites for deployment.
