By James Yang , Executive Assistant to the CEO, Profet AI
In our previous articles, we explored the risks enterprises may face when adopting AI Agents and the security governance mechanisms needed to address them.
This time, we take a closer look from the perspective of the semiconductor industry.
As enterprises increasingly adopt external AI services—and begin introducing AI Agents into manufacturing workflows—we need to ask whether the cybersecurity defenses we have built over the years are still sufficient.
The Cybersecurity Baseline for Semiconductor Manufacturing: SEMI E187
For years, cybersecurity in the semiconductor industry has focused heavily on the security of equipment itself.
Does the equipment run a supported operating system? Are network communications secure? Are endpoints properly protected? Are security monitoring and logging capabilities in place?
Released in 2022, SEMI E187 was developed to address foundational cybersecurity requirements for semiconductor manufacturing equipment. It establishes security requirements across four key areas: Operating System, Network Security, Endpoint Protection, and Security Monitoring.
This provides a cybersecurity baseline that can be applied throughout the equipment lifecycle—from deployment and operation to ongoing maintenance.
But as AI Agents begin entering fabs and enterprise IT environments, the objects we need to secure are changing.
In the past, we managed equipment, servers, applications, and users. Now, we also have AI Agents that can understand tasks, access data, call tools, and potentially execute actions autonomously.
A recent report from Anthropic highlights another cybersecurity issue that semiconductor companies should pay attention to.
What Anthropic’s Latest Report Reveals About Enterprise AI Security
On September 10, Anthropic published its 154-page report, Detecting and Countering Misuse of AI, detailing how it detected and disrupted malicious activities involving Claude over the previous eight months, including cyberattacks, surveillance, fraud, weapons development, and unauthorized model distillation.
One of the most attention-grabbing findings was Anthropic’s disclosure that a user suspected of being connected to a Chinese military research institution had used Claude to develop software related to electronic warfare and air defense suppression, and had reportedly used Taiwan’s air defense facilities as simulated targets.
The headlines are certainly striking. But after reading the report, I found myself thinking about a question that is much more directly relevant to enterprises:
How did Anthropic know?
The ability to identify accounts, analyze usage patterns, connect multiple interactions, and ultimately develop threat intelligence indicates that AI platforms themselves need sophisticated capabilities for monitoring, detection, classification, and investigation.
There is a legitimate reason for this. Without such capabilities, AI platforms would have difficulty detecting and preventing fraud, cyberattacks, and other forms of abuse.
But the question changes when we look at this from an enterprise perspective.
In recent discussions with large semiconductor, AI server, and high-tech manufacturing companies, I have observed a common pattern: many enterprises have already begun adopting tools such as Claude Enterprise and ChatGPT Enterprise, giving engineers direct access to Frontier Models.
The productivity benefits are clear. But enterprises also need to understand:
- What data are employees actually sending to AI?
- Which conversations are retained, and for how long?
- Which interactions may be subject to safety or abuse detection?
- Under what circumstances could content be investigated further?
- Can the enterprise control its retention policy?
- Does the enterprise maintain its own audit logs?
- Which process parameters, yield data, equipment information, and customer confidential information should never be sent directly to external AI services?
To be fair, Anthropic publicly states that inputs and outputs from its commercial products are not used to train models by default. Claude Enterprise also provides controls for data retention and auditing.
However, “not used for model training” is not the same as “never processed, retained, or subject to security detection.”
Anthropic’s documentation also explains that certain content associated with policy violations may be retained longer for safety investigations, while some Covered Models are subject to additional safety retention and review requirements.
This does not mean that every enterprise conversation is manually reviewed, nor does it justify concluding that enterprise secrets have been exposed. Actual data handling and retention depend on the specific product, enterprise agreement, and configuration.
But the report does highlight an important principle:
Enterprises should not only ask whether an AI provider uses their data to train models. They also need to understand who controls the data throughout the AI lifecycle, how it is processed, how long it is retained, and whether those activities can be audited.
As AI moves from answering questions to taking autonomous actions, these questions become even more important.
From Equipment Security to Agent Security
Historically, one of the major risks of external AI was that employees might voluntarily submit sensitive information to an AI service.
Agentic AI changes the equation.
AI Agents are no longer limited to answering questions. Through APIs, MCP, and other interfaces, they can access enterprise systems, retrieve data, and potentially execute real-world operations.
For example, an Agent responsible for process anomaly analysis may access MES, production history, equipment logs, and quality data at the same time.
Another Agent responsible for equipment maintenance could access machine status through connected tools and potentially recommend parameter adjustments.
These applications can significantly improve efficiency.
But they also introduce a new set of security questions:
Which Agent can access which data, call which tools, and execute which actions—and under what conditions?
This is one of the fundamental differences between Agent Security and traditional equipment security.
Within semiconductor manufacturing environments, SEMI E187 can establish a relatively clear equipment security governance chain through equipment procurement, supplier management, and ongoing maintenance requirements.
AI Agent adoption, however, may span IT, manufacturing, equipment engineering, quality, and multiple enterprise applications. Responsibility may not sit with a single organizational unit.
Enterprises therefore need to address at least three additional areas:
1. Dynamic Authorization Can permissions be dynamically adjusted based on the user, task, tools involved, and data sensitivity?
2. Agent Delegation When one Agent invokes another Agent, can permissions be properly constrained to prevent privilege escalation during delegation?
3. Identity Lifecycle Management When an Agent is created, activated, suspended, or revoked, can its credentials and access permissions be managed accordingly?
For equipment or human users, permissions may remain relatively stable over long periods.
For Agents, however, permissions need to evolve with the task and execution context.
This is why Agent Security cannot be solved simply by extending traditional account management.
From SEMI E187 to an Agent Security Governance Framework
SEMI E187 establishes four foundational cybersecurity areas for semiconductor equipment: Operating System, Network Security, Endpoint Protection, and Security Monitoring.
As AI Agents begin entering fabs and manufacturing workflows, we can borrow the layered security mindset behind E187 when thinking about how to build an Agent Security framework.
However, it is important to clarify that the following is a proposed extension of the governance concept inspired by E187—not a claim that SEMI E187 itself defines Agent Security requirements.
1. Identity & Runtime Security
Every Agent needs a clearly defined digital identity.
Who created it? Which user or business function does it represent? Where does it run? Who issues, rotates, and revokes its credentials?
When an Agent operates across multiple systems, enterprises must distinguish between the human user’s identity, the Agent’s identity, and the identity actually used to perform an operation.
An Agent should not be given a long-lived Service Account with broad access simply because it needs to perform one specific task.
2. Network & Tool Permission
When Agents interact with enterprise systems through APIs, MCP, or other interfaces, security is no longer just about whether the connection is encrypted.
The enterprise must also determine whether each tool invocation is appropriately authorized.
Which Agents can connect to MES? Which can query equipment data? Which can execute equipment-related operations?
RBAC and ABAC can provide the foundation for different levels of authorization, while access decisions can incorporate factors such as the user, task, equipment state, and operational risk.
For high-risk actions such as equipment parameter changes, organizations should consider additional controls such as Human-in-the-Loop approval, MFA, and short-lived authorization tokens.
3. Data Boundary & Isolation
Semiconductor manufacturers hold extensive process Know-how, equipment parameters, yield data, and customer-sensitive information.
During execution, an Agent may access these datasets while also generating conversation records, temporary files, working memory, and other intermediate artifacts.
Data governance therefore cannot stop at what a user initially submits to an AI model.
It must also address:
What did the Agent access? What did it generate? And what information could potentially be transmitted to an external ance therefore cannot stop at what a user initially submits to an AI model.
It must also address:
What did the Agent access? What did it generate? And what information could potentially be transmitted to an external model?model?
Clear data access and isolation boundaries are needed across departments, fabs, customers, and tasks.
This is why enterprises cannot rely solely on an external model provider’s data protection commitments. They also need a Data Boundary that they can control themselves.
4. Monitoring & Audit
Equipment security requires logs. Agents require them even more.
An Agent’s behavior is not necessarily a fixed sequence of actions. Given different data and contexts, the same task may lead an Agent to select different tools and execution paths.
Enterprises therefore need visibility into:
Who initiated the task? Which Agent executed it? What data did the Agent access? Which tools did it call? What intermediate artifacts or working memory were generated? Which actions were authorized? Which were blocked by guardrails? If something goes wrong, can the activity be traced, permissions restricted, or execution stopped immediately?
These records need to be integrated, retained, and transformed into auditable reports.
Only then can Agent activity become a manageable enterprise security capability.
The Agent Security Baseline: What Enterprises Really Need Is Governance Control
Let’s return to Anthropic’s report.
It demonstrates that major AI platforms already possess sophisticated capabilities for abuse detection and threat investigation. More importantly, it gives enterprises an opportunity to rethink the security capabilities they need to establish themselves.
For large semiconductor and high-tech manufacturing companies, an AI Agent platform needs to govern more than the model itself.
From models and data to tools and actual operations, enterprises need an AI Governance Layer that they control.
This governance layer should cover:
Identity → RBAC / ABAC → Guardrails → Tool Permission → Data Boundary → Audit Log → Retention → Reporting
Together, these capabilities form a closed-loop AI security governance framework.
When these controls can be managed consistently, enterprises can maintain the same security requirements across different Frontier Models, different Agents, and different enterprise systems.
This does not replace SEMI E187.
Nor does it mean that existing equipment security is no longer sufficient.
Rather, as AI Agents begin to access enterprise data and execute actions, a security architecture historically centered on equipment, networks, and human users needs to extend toward Agent identity, behavior, and authorization.
The future question for semiconductor security is no longer only:
Which equipment is allowed into the fab?
It is also:
Which Agent is allowed in? What can it see? What can it do? And if it makes a mistake, can we stop it before it creates real-world impact?
AI should—and will—be widely adopted.
But enterprises cannot allow the convenience of AI to mean outsourcing their data boundaries, permissions, and governance along with it.
After reading Anthropic’s 154-page report, I believe the question enterprises should be asking is not simply whether external AI platforms have adequate security protections.
It is this:
When thousands of employees use AI every day and hundreds of Agents begin connecting to enterprise systems, can the enterprise still see what data is leaving its boundaries—and what actions are being executed in the name of AI?
That is the question the semiconductor industry needs to start answering as it moves from Equipment Security to Agent Security.
