After employees install AI Agent on their computers, the first question managers usually ask is, “Who in the company is using it?” This is certainly an important question, but completing an inventory does not mean the risks are under control. Suppose a sales representative only needs AI Agent to look up historical orders, but the system grants it administrator privileges. Or a procurement employee downloads a skill from an unknown source. AI Agent may then be able to read local files, call application programming interfaces (APIs), or even modify data it should never have been able to access.
A TechOrange report cites TeamT5 Senior Manager Hou Hsiang-Ling, who says that enterprises must first identify which AI Agent deployments exist internally, which models they use, and whether they comply with company policies. They must then continuously review permissions, skills, and access to sensitive data. The report also references a Gravitee survey indicating that more than 80% of surveyed enterprises have deployed a large language model (LLM) or AI Agent, yet fewer than 50% of AI Agent deployments are monitored or protected. However, the original report does not specify the number, location, or industry distribution of the surveyed companies. These figures should therefore be treated as a reminder to examine governance gaps, not as a direct estimate of an individual company’s risk exposure.
After Completing the Inventory, Determine Which Data Each AI Agent Can Access
Once an enterprise has completed its inventory, it will know which AI Agent deployments exist within the company. The next step is to determine what each AI Agent is allowed to do. In addition to documenting product names, versions, and installation locations, the company should identify every database, shared folder, local file, API, and external domain each AI Agent can access. It should also specify which content the AI Agent can read, modify, delete, or transmit. With this inventory, IT, information security, and business leaders can jointly determine whether a task only requires data queries or genuinely needs permission to modify data.
Consider sales quotations. If AI Agent is only responsible for looking up historical orders and pricing rules, it does not need permission to delete orders or modify customer master records. The same principle applies to procurement price comparisons. If the task only requires access to supplier quotes and delivery schedules, administrator privileges should be removed, and the APIs the AI Agent can call should be restricted. If AI Agent needs to send results to an external service, the team should review each destination domain, identify which fields will be transmitted, and confirm that the connection serves a genuine business need. Connections should not be opened broadly simply for convenience.
The original article divides the risks into three categories: tampering with a tool’s usage description, embedding malicious requests in tool output, and modifying content within the skill supply chain. Regardless of the attack method, the extent of the resulting damage ultimately depends on the permissions held by AI Agent. We recommend that enterprises assume malicious instructions may enter the workflow. Database connections should therefore be limited to the internal network and configured as read-only. External domains should be denied by default and approved individually to reduce potential damage. Permission restrictions, however, are not a substitute for skill reviews. Enterprises must maintain both lines of defense.
At this stage, an enterprise can take one concrete step: select a task already in production and map the entire workflow, from its data sources to the destination of its results. If the task does not require reading, modifying, or deleting data—or connecting to an external service—remove those permissions first, and then ask the process owner to confirm that the workflow can still be completed successfully.
Can a Skill Created by a Colleague Be Rolled Out Across the Company Immediately?
No. Skills package standardized instructions, tools, and processing rules into reusable workflows. Once a company designates a skill as a shared resource, its use expands from an individual trial to multiple departments. The original article warns that changing even a single instruction within a skill could cause AI Agent to transmit environmental data to an attacker. Therefore, the fact that “a colleague used it without any problems” is not sufficient grounds for company-wide approval.
Enterprises should classify skills into two levels: “individual trial” and “company-wide shared use.” During an individual trial, the skill should only use test data and run in a controlled environment. Before it can be reclassified as a company-wide shared skill, it must undergo a formal review, with an owner who understands the relevant business process assigned to it. At a minimum, reviewers should examine the instructions, the data the skill can access, the tools it can call, whether it connects to external domains, and who is responsible for reviewing it again after a version update. If a skill comes from an unknown source, has no clearly identified owner, or requests permissions beyond what the task requires, it should not be rolled out.
Reviewers cannot focus solely on the code. Consider a quality-control report: information security personnel can inspect network connections and file access, but only the quality-control manager knows which fields are necessary for the task and which results may be transmitted outside the facility. IT, information security, and business units should each review the areas within their responsibility and record the approver, skill version, and approval date. Enterprises can begin with the most widely used skills or those that handle sensitive data. They do not need to incorporate every individually tested skill into company standards at once.
If Permissions Are Already Restricted, Why Review Logs Every Month?
Permissions, skill versions, and workflows can all change. Enterprises cannot treat the initial approval as permanently valid. The original article argues that AI Agent must continue to be evaluated and reviewed after deployment rather than waiting until an incident occurs. Enterprises need traceable audit logs that record which AI Agent accessed what data and when, which tools it called, when its permissions changed, and who downloaded the audit logs. This ensures that relevant activity can be investigated after the fact.
Monthly reviews do not require teams to read every log entry from beginning to end. IT, information security, and business units can agree on a fixed set of review items, such as unusually large volumes of data accessed outside working hours, connections to unapproved domains, newly added write permissions for tasks that originally required only queries, and version changes to shared skills. Every anomaly should be assigned an owner and a resolution deadline. If a system can export logs but no one reviews them regularly, those logs still cannot fulfill their governance purpose.
EgentWrX provides several mechanisms that enterprises can adopt. Companies can allow AI Agent to query corporate databases through read-only internal-network connections, while denying all external connections by default and approving domains individually. Skills created by employees must pass an administrative review before they can be rolled out across the company. AI Agent activity is captured in exportable audit logs, and a hash chain can be used to verify whether records have been modified. The system even records when an administrator downloads an audit log. However, enterprises must still decide which data may be used, who is responsible for approval, and how often reviews should be conducted. The platform provides tools for enforcement and investigation, but managers must determine which risks are acceptable.
After completing the inventory, start by testing a task that handles sensitive data or requires an external connection. Remove unnecessary permissions, review shared skills, and then examine the logs every month. Once every anomaly has an assigned owner and resolution deadline—and someone is responsible for confirming that it has been resolved on schedule—the same approach can be rolled out to other departments.
FAQ
Is it enough to record only the product and version when conducting an AI Agent inventory?
No. In addition to the product and version, the inventory should document which data each AI Agent can read, which APIs it can call, which account permissions it uses, and which external domains it connects to. It should also identify the purpose and owner of each AI Agent. This information makes it possible to determine which permissions should be removed during subsequent reviews.
What permissions should an AI Agent have if it is only responsible for queries?
Start with read-only permissions and limit access to the databases, fields, and files required to complete the task. If the workflow genuinely needs to write or delete data, a separate approval step should be designed rather than reusing an administrator account.
When can an employee-created skill be made available across the company?
A skill should only be designated for shared use after the company has reviewed its instructions, data access scope, and external connections and assigned a responsible owner. Test data should be used during the individual trial period. The content and permissions must also be reviewed again whenever the skill is updated.
Which AI Agent records should be reviewed each month?
Start by reviewing anomalous data access, unapproved external connections, permission changes, version changes to shared skills, and records of administrators downloading audit logs. Every anomaly should have an assigned owner and resolution deadline, and the next review should confirm whether the issue has been resolved.
References
- When AI Risk Shifts from Hallucinations to Taking the Wrong Actions, TeamT5 Examines Enterprise Defenses: Governance Begins with Visibility — TechOrange reports TeamT5’s perspectives on enterprise AI Agent risks, endpoint inventory, and continuous monitoring.
