Runtime vulnerabilities, compromised software supply chains, and AI-driven attacks are exposing security assumptions that enterprises can no longer afford to leave unchecked.

Manufacturing AI security depends on controlling what a compromised system or agent is allowed to do. Runtime patching, verifiable credential revocation, and separate authorization for operational changes help limit the impact of failures across connected systems.

For manufacturing IT teams, some of the hardest systems to secure are not the ones that frequently break down. They are the systems that have been running reliably for years, with little documentation and even less appetite for change.

Consider an internal web dashboard used to monitor equipment utilization or maintenance records. It may have been delivered by a systems integrator a decade ago, built on an older version of PHP, and subsequently connected to manufacturing execution systems (MES), enterprise resource planning (ERP) platforms, and production databases.

The original developer may no longer be involved. The system still works. Production teams depend on it, and nobody wants to risk disrupting operations by upgrading its underlying components without extensive testing.

Similar compromises accumulate in cloud and development environments.

Service accounts, API keys, and OAuth grants are created to keep CI/CD pipelines and integrations running. Release permissions may be temporarily expanded to address an urgent customer issue. Credentials that were intended for limited use remain active, while exceptions introduced for convenience are not always reviewed or rolled back.

Individually, these decisions may seem reasonable. Over time, they create layers of implicit trust that become increasingly difficult to audit.

The applications continue to function, but the permissions and dependencies underneath them tell a different story.

In late October 2026, several major security disclosures brought these risks into sharper focus.

On October 21, two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, were disclosed under the name PHP2Shell. Both carry CVSS v4.0 scores of 9.2. Researchers demonstrated unauthenticated remote code execution (RCE) in affected Apache mod_php environments, including attack paths that execute before application code runs. Other deployment models, including PHP-FPM, require separate assessment of their execution and request-lifecycle conditions.

That same day, LiteLLM disclosed that its official release pipeline had been compromised, allowing a malicious package to reach PyPI and container registries. Cloud platform Railway also reported unauthorized access to internal systems, with some customer environment variables potentially exposed.

The risks were not limited to faulty application code. They involved runtime behavior, software release processes, persistent credentials, and access to sensitive infrastructure.

Another development made the picture more concerning. On October 21, Microsoft published threat intelligence describing how Storm-0940 had used ARTEX, an agentic AI penetration-testing framework, to accelerate parts of its offensive operations. In multiple observed cases, attackers progressed from initial targeting to privileged cloud access in less than three hours.

Firewalls, vulnerability scanners, endpoint protection, and application security controls remain essential. What these incidents demonstrate is that organizations also need to examine the trust relationships those controls may not fully address.

A vulnerable runtime can be exploited before application code runs. A compromised release process can distribute malicious software through an official channel. A credential issued for legitimate work can become a route to broader access.

The question is no longer limited to whether one system can be compromised. It is also how far an attacker could move using the access that system already holds.

PHP2Shell: When the Runtime Is Compromised Before Application Code Executes

PHP2Shell deserves attention because the vulnerabilities affect assumptions that web application developers often take for granted.

Authentication, authorization, and input validation are commonly implemented in application code. Yet an HTTP request must first pass through the web server and PHP runtime before that code can execute.

A vulnerability in this earlier processing stage can create an attack path that application-level controls are not designed to prevent.

According to the PHP security team’s advisory, both vulnerabilities involve failures in how PHP handles memory and request state.

CVE-2026-109618: Memory corruption during out-of-memory handling

PHP uses error-handling mechanisms to terminate processing when memory allocation fails.

Under certain conditions, an allocation failure can interrupt request processing before internal state has been fully initialized. Subsequent cleanup operations may then treat invalid memory as valid, creating a memory-corruption vulnerability.

Specially crafted HTTP requests, including multipart form submissions, can trigger the affected processing paths.

The consequences can extend beyond a process crash or denial of service. Researchers demonstrated unauthenticated RCE against Apache mod_php, including exploitation before application code executes.

PHP-FPM is also considered potentially susceptible, but the PHP security team’s initial disclosure distinguished this from the demonstrated mod_php exploit. At that point, a complete PHP-FPM exploit for this vulnerability had not been publicly demonstrated.

The distinction matters. Different PHP execution models have different request lifecycles, error-handling behavior, and exploitation conditions. Organizations should assess their actual deployment configuration rather than assume that all installations have identical exposure.

See the official CVE-2026-109618 advisory.

CVE-2026-109619: Stale state across requests

The second vulnerability involves global state that persists within PHP worker processes.

Some internal state can retain references to memory belonging to a request after that memory has been released. Under particular error-handling and request-reuse conditions, subsequent processing may access the stale state before it is properly reinitialized.

This creates a use-after-free vulnerability that can potentially be exploited for remote code execution.

The underlying issue is not simply that an HTTP connection remains open. It concerns how worker processes retain and reuse internal state across requests or during interrupted processing.

The affected execution paths differ across PHP environments, and exploitation depends on the relevant runtime behavior.

See the official CVE-2026-109619 advisory.

Together, the vulnerabilities illustrate an important architectural risk: an application can contain sound authentication and validation logic while remaining vulnerable through the runtime that executes it.

If an attacker gains code execution with the web worker’s privileges, the potential damage depends partly on what that identity can access. A service account with unnecessary database permissions or access to adjacent applications can turn a runtime compromise into a broader incident.

Runtime patching and least-privilege access therefore need to be considered together.

The manufacturing problem: a critical patch with no easy maintenance window

PHP released fixes in versions 8.2.35, 8.3.36, 8.4.27, and 8.5.12.

For a modern application with automated testing and controlled deployments, upgrading may be relatively straightforward. For a decade-old manufacturing dashboard, the work can be more complicated.

The application may rely on an outdated PHP extension or database driver. It may run inside a virtual machine that has not been rebuilt for years, or within a container image that receives little maintenance. It may also be bundled with third-party equipment management software.

Updating the host operating system does not necessarily update the runtime inside a container. Redeploying an application does not guarantee that an embedded third-party dependency has been replaced.

An IT security team may see a critical CVSS score and demand immediate action. Operations may see a system tied to production and insist on a maintenance window, compatibility testing, and a rollback plan.

Neither concern can simply be ignored.

The right first step is to establish actual exposure:

• Which PHP runtime and patch level are deployed, including any vendor backports?
• Does the deployment use an affected execution model?
• Can untrusted requests reach the vulnerable processing path?
• What privileges does the web service hold, and which downstream systems can it access?
• What would an upgrade or restart affect operationally?

Where an immediate upgrade is not feasible, organizations may need to narrow network access, remove unnecessary privileges, apply vendor-recommended configuration changes, strengthen request filtering, and increase monitoring.

These are temporary risk-reduction measures, not substitutes for a vendor-supported fix.

For unsupported PHP branches or older packaged applications, the organization should establish whether a vendor-maintained patch is available. The PHP security team has also published limited source backports for certain older versions, although these are not necessarily suitable for every environment.

If no supported fix is available, isolation and a controlled migration plan become increasingly important.

The challenge is not choosing between security and uptime. It is developing a patching process that accounts for both.

What PTC and Oracle Reveal About the Limits of Dependency Visibility

Following the PHP2Shell disclosure, major enterprise software vendors began publishing product-level impact assessments.

PTC established a dedicated PHP2Shell advisory page and reported that several core products, including ThingWorx, Windchill PLM, and FlexPLM, were not affected. For PTC Cloud, the company reported applying recommended protective measures and scanning environments to ensure relevant PHP executables and libraries were updated or removed.

Oracle published a security alert identifying affected versions across several products, including Oracle Communications Diameter Signaling Router and EAGLE Application Processor, as well as other Communications and infrastructure products.

These vendor responses give customers a starting point for assessing their own exposure.

However, the assessment of a standard product does not automatically describe every customized deployment in a customer’s environment.

Manufacturing software frequently passes through multiple layers of integration. A systems integrator may add a lightweight web service. An internal team may develop a reporting interface or connect the application to another database. A vendor-supplied package may include dependencies that are not obvious from its product name.

As a result, the application running on the factory floor may differ significantly from the standard configuration assessed by its original vendor.

This exposes a familiar limitation in enterprise asset management.

A configuration management database (CMDB) may identify a server’s hostname, IP address, application owner, and business function. Those records are useful, but they may not reveal:

• The exact container image or build currently deployed.
• The versions of libraries and runtimes contained in that artifact.
• Dependencies introduced through customization or third-party integrations.
• The service accounts, database connections, and API permissions associated with the deployment.
• The upstream and downstream systems that could be affected by an emergency update.

A software bill of materials (SBOM) can improve visibility, but only when it reflects the software actually running.

An SBOM created during project acceptance and never updated offers limited value during an incident. The same applies to an asset inventory that is disconnected from CI/CD, container registries, runtime configurations, and identity management.

Ideally, organizations should be able to correlate a newly disclosed CVE with the deployed artifact, its dependencies, the environment in which it runs, and the access it has been granted.

Without that visibility, answering a question as basic as “Are we affected?” can require days of investigation across development teams, systems integrators, vendors, and operations.

For manufacturing environments with tightly controlled maintenance windows, that delay is more than an administrative inconvenience.

LiteLLM and Trivy: Removing a Secret from Git Is Not the Same as Revoking It

PHP2Shell illustrates the risks associated with the runtime. The LiteLLM incident exposes a different problem: the trust placed in official software distribution channels.

On October 21, 2026, LiteLLM’s release pipeline published a compromised version, litellm==1.107.0, to PyPI and container registries.

Users obtaining the affected package through an official distribution channel could therefore encounter malicious code without downloading anything from an obviously suspicious source.

One of the most consequential findings was that the official source release tag did not contain the malicious content. The compromise occurred in the process that produced and published the release artifacts.

Reviewing the legitimate source tag alone would not have established the integrity of what customers actually downloaded.

LiteLLM’s October 23 root-cause analysis reconstructs how the attacker reached that point.

1. A master key was exposed in May but never revoked

On May 27, a configuration file containing the master key to an internal LiteLLM Agent Platform deployment was accidentally committed to a public GitHub repository.

The exposed configuration was removed from the repository’s visible history, and the credentials were identified as requiring revocation.

The critical step, however, did not happen: the master key remained valid.

Deleting a secret from a repository does not invalidate copies that may already have been obtained. The credential must be revoked at the issuing service, and its downstream access must be assessed.

2. The key became a path to GitHub organization-level access

On October 10, an attacker used the still-valid master key to access the internal Agent Platform API.

That API returned a GitHub CLI OAuth token associated with a GitHub organization owner.

The token was not restricted to a narrowly scoped service identity. It carried extensive privileges across the organization’s repositories.

Armed with that access, the attacker created temporary CI workflows to exfiltrate additional secrets, including tokens belonging to other maintainers.

Some workflow execution records were subsequently deleted, although organization-level audit evidence remained available to investigators.

The original exposed key had become an entry point into multiple development and release systems.

3. The attacker redirected the release workflow to a malicious repository

On October 21, the attacker attempted to modify LiteLLM’s private release workflow so that it would build from a lookalike repository rather than the legitimate source.

Branch protection initially blocked the unauthorized change.

The attacker then used the organization owner’s credentials to override those protections and push the modified workflow.

This is an important distinction. A security control existed and worked as intended at first, but the broader permission model allowed a sufficiently privileged identity to bypass it.

4. Temporary approval changes made publication easier

Under normal circumstances, LiteLLM’s production release process required approval from a dedicated account associated with a physical device.

That requirement had been temporarily relaxed to support more frequent releases and bug-fix backports, allowing two authorized engineers to initiate and approve publication.

Because the attacker had already obtained multiple maintainer tokens, the modified approval process could be satisfied with stolen credentials.

The attacker used one token to initiate the compromised release and another to approve it.

The pipeline then signed and published the malicious artifacts through LiteLLM’s official infrastructure.

The sequence illustrates how multiple individually trusted mechanisms can be manipulated when an attacker gains enough control over the identities and workflows connecting them.

Trivy: When credential rotation leaves an opening

A related lesson emerged from the March 2026 supply-chain compromise involving Aqua Security’s Trivy ecosystem.

According to the project’s security advisory, the March attack followed an earlier incident disclosed at the beginning of the month.

Credential rotation had been performed, but the process was not atomic: not all credentials were invalidated simultaneously.

The advisory identifies a possible scenario in which a remaining valid token could have been used to obtain newly rotated secrets, allowing the attacker to retain access. That mechanism was presented as a potential explanation, rather than conclusively established.

On March 19, attackers used compromised credentials to publish a malicious Trivy release and redirect numerous GitHub Action version tags to malicious code. Additional compromised container images appeared on March 22.

The attacks affected tools that development teams commonly incorporate into automated security scanning and build workflows.

This creates a particularly difficult supply-chain scenario: a tool introduced to improve security can itself become a delivery mechanism for malicious code.

Both incidents point to several practical requirements.

Credential revocation must be verifiable. Removing a file or closing a ticket is not sufficient if the credential remains accepted by the issuing service.

Rotation must account for connected systems. Replacing one token while another compromised identity can still retrieve the replacement may leave the original access problem unresolved.

Release protections must withstand privileged-account compromise. High-risk workflow changes should require independent oversight, and temporary approval exceptions should have explicit expiration and restoration procedures.

Artifact provenance matters. A signed artifact can establish who or what signed it, but a valid signature alone does not prove that the build used the intended source or that the build process was uncompromised.

Organizations should validate the relationship between approved source revisions, build workflows, signed artifacts, and deployed versions. Immutable references, trusted build identities, audit records, and reproducibility checks can reduce the opportunity for substitution.

Official distribution remains valuable. The lesson is not to abandon trusted sources, but to verify the process by which software becomes an official release.

Railway: Encryption at Rest Does Not Eliminate Credential Exposure

The October 2026 Railway security incident drew attention to another widely used architectural pattern: secrets stored as environment variables and accessed by automated services.

Cloud-native applications routinely rely on API keys, service accounts, and other non-human identities (NHIs) to communicate with databases, infrastructure services, and external providers.

These credentials enable automation. They also create attractive targets when the identities or systems permitted to use them are compromised.

According to Railway’s October 22 preliminary incident report, the attack began on October 20 and continued through October 22, when Railway confirmed that the attacker no longer had access to its internal systems.

The investigation confirmed unauthorized access to a subset of those systems. Railway also reported that the attacker accessed encrypted customer environment variables and decrypted stored secrets for a subset of workspaces.

The company estimated that no more than 1.85% of workspaces had potentially compromised environment variables.

That figure does not mean every secret within those workspaces was accessed or exfiltrated. Railway also stated that it could not determine exactly which variables had been decrypted.

The complete intrusion mechanism had not been disclosed in the preliminary report. In particular, the report does not establish container escape as the confirmed entry point.

What it does establish is the operational importance of protecting the infrastructure identities and services involved in handling secrets.

Encryption at rest is an essential security measure, but applications and infrastructure services must eventually decrypt the secrets they are authorized to use.

If an attacker compromises an identity or system with legitimate decryption privileges, encrypted storage alone cannot prevent misuse of that authorized access path.

Railway’s investigation indicated that the attacker was particularly interested in high-value AI provider and platform API keys.

The incident also highlights an important distinction in credential recovery.

Revoke exposed credentials promptly; reissue them into a trusted environment

Incident response often treats credential rotation as a single step, but two separate actions are involved.

The first is containment: revoke or disable credentials that are known or reasonably suspected to have been exposed.

The second is recovery: issue replacement credentials and deploy them only after the relevant systems and access paths have been secured.

Railway reported notifying upstream providers so potentially affected credentials could be revoked. It also delayed asking customers to deploy replacement credentials until the immediate intrusion had been contained, reducing the chance that newly issued secrets would be compromised again.

For manufacturing operations, the same distinction applies.

An organization may be unable to shut down every connected system immediately. It still needs a clear understanding of which credentials and access paths require urgent containment, which services must remain available, and how recovery should be sequenced.

The objective is not simply to generate new keys. It is to prevent the attacker from retaining access while keeping critical operations under control.

Agentic AI Is Compressing the Time Available to Defenders

Credential abuse and supply-chain compromise are not new attack techniques. What is changing is the speed and scale at which attackers can combine them.

Microsoft’s October 21 threat intelligence report described how Storm-0940, a state-aligned threat actor, used ARTEX, an agentic AI penetration-testing framework, to automate elements of its offensive operations.

Microsoft observed activity involving automated reconnaissance, password spraying, OAuth application abuse, and follow-on actions in cloud environments.

In multiple instances, the time between initial targeting and privileged cloud access was less than three hours.

That finding should not be interpreted as a universal three-hour compromise window. Nor does it mean every automated attempt succeeded.

Microsoft also documented unsuccessful activity, including a large password-spraying campaign in which its telemetry recorded more than 151,000 failed sign-in attempts without observing successful authentication.

The significance of the findings is not that AI-assisted attacks consistently compromise organizations within hours. It is that certain successful intrusions progressed at a pace that can outstrip conventional investigation and response workflows.

During activity associated with the ConnectWise supply-chain compromise, Microsoft observed attackers abusing credentials associated with applications that customers had previously authorized.

That existing authorization was significant. The attacker could attempt to access downstream cloud environments through application identities without requiring a new interactive user sign-in.

Some observed activity then progressed to Microsoft Graph operations, including reconnaissance and changes involving application credentials and permissions.

For defenders, this changes the operating assumptions.

A conventional response process might involve an alert, analyst review, escalation to the application owner, business-impact assessment, and an approved containment or maintenance action.

That process may take hours or days, particularly when production continuity is involved.

An AI-assisted attacker can attempt multiple paths in parallel while moving through already authorized services.

Organizations therefore cannot depend entirely on discovering excessive privileges during an incident. They need to reduce unnecessary access beforehand, monitor non-human identities, and establish containment procedures that can act quickly without introducing unacceptable operational risk.

This is a different problem from deploying AI agents inside an enterprise. ARTEX was an offensive framework used by a threat actor.

The connection is architectural: the more actions an automated system can perform with existing privileges, the more important the boundaries around those privileges become.

AI Agents in Enterprise Operations: Keep Analytical Access Separate from Execution Authority

As enterprises introduce AI agents into operational workflows, identity and access management take on new significance.

An agent may retrieve documents, query databases, invoke APIs, and coordinate actions through tool-calling frameworks or the Model Context Protocol (MCP).

These capabilities make agents useful. They also mean that a poorly scoped identity can give an otherwise limited assistant far more authority than its intended role requires.

Consider an equipment troubleshooting agent in a manufacturing plant.

An engineer wants the agent to review maintenance manuals, query sensor readings, retrieve historical fault records, and recommend possible causes of an equipment anomaly.

The intended workflow is analytical. The agent needs access to information, not the authority to change equipment settings.

During integration, however, the team may reuse an existing service account because it already connects to the relevant systems.

That account might also have permission to update maintenance records, create work orders, modify production schedules, or invoke commands through another operational application.

The agent has now inherited privileges beyond its original purpose.

If the agent encounters malicious instructions embedded in retrieved documents, tool responses, or other untrusted content, an indirect prompt injection attack may cause it to misuse otherwise legitimate tools.

The resulting impact depends on the permissions granted to the agent and the controls enforced by the connected systems.

Likewise, a compromised dependency or tool integration could introduce additional risk if it operates with excessive privileges.

These are potential attack scenarios, not evidence that the incidents discussed earlier involved compromised manufacturing agents.

The concern is that legitimate tool access can be misused when authorization is broader than necessary.

A prompt instructing an agent not to modify production data is not a security control. Enforceable boundaries must exist in the identity, API, workflow, and infrastructure layers.

Three design principles are particularly important.

1. Separate read access from operational changes

An agent used for diagnosis should have read-only access wherever possible, enforced through the connected systems rather than described only in its instructions.

Even read-only access needs controls.

An agent that can retrieve confidential information and send it to an external destination may still create a data-exfiltration risk. Data access and outbound communication should both be restricted according to the task.

Actions that change operational state require stricter treatment.

Changing equipment parameters, altering production plans, or initiating procurement should pass through explicit authorization checks. Depending on the operation’s criticality, that may include human approval.

Approvals should be meaningful. Reviewers need to see the proposed action, the relevant equipment or records, the expected changes, and the potential consequences.

A generic approval button without sufficient context provides little protection.

2. Scope machine identities to the task and duration

Agents should not automatically inherit broad administrative permissions from the systems they connect to.

Where supported, organizations should use dedicated identities, narrowly scoped authorization, and short-lived credentials.

The objective is to grant an agent only the access required for a specific task, for as long as that task requires it.

Short-lived credentials are not always practical in older operational environments. Some industrial applications were not designed for modern identity protocols, dynamic credential issuance, or frequent reauthentication.

In those cases, the goal remains the same, but the architecture may need to enforce controls through an intermediary rather than directly on the legacy system.

Regardless of credential lifetime, the organization should be able to identify who or what initiated an action, which permissions were used, and whether access remains necessary.

3. Put a controlled interface between agents and legacy OT systems

Manufacturing environments cannot assume that every existing machine or control system supports modern security mechanisms.

For older equipment, a controlled gateway or intermediary service can enforce policies between an AI agent and the production network.

For example, an agent may be permitted to retrieve equipment status from an approved interface, while changes to operating parameters require an additional authorization step.

Controls can also restrict which equipment is accessible, which commands are permitted, how frequently requests may be made, and whether outbound connections are allowed.

Network segmentation between enterprise IT and operational technology (OT) remains important. A compromised business application or agent should not have unrestricted access to production systems.

These boundaries help ensure that an analytical assistant does not inadvertently become an operational control channel.

At Profet AI, the same principles inform our approach to Domain Twin™, which brings machine learning and agentic AI into enterprise manufacturing workflows.

The objective is not to assume that models will always interpret information correctly or resist malicious input. It is to place agent capabilities within a governable operating environment, with defined access permissions, appropriate human oversight, and auditable activity.

As AI moves beyond analysis and begins participating in operational decisions, the separation between recommendations and authorized execution becomes an essential part of enterprise deployment.

After Pandora’s Box Opens: Making Security a Continuous Engineering Practice

Taken together, these incidents expose limitations in security assumptions that organizations have long relied upon.

An unchanged application may still be exposed through its underlying runtime.

A package obtained from an official distribution channel may still be compromised if the build or release process has been manipulated.

Encrypted secrets may remain vulnerable when an attacker gains access to the identities authorized to decrypt them.

And AI-assisted attacks can accelerate the abuse of existing credentials and permissions, leaving defenders less time to investigate and respond.

None of this makes conventional security practices obsolete.

Patching, vulnerability scanning, network controls, identity management, and incident response remain fundamental. The problem is treating any one of them as a complete defense.

Patching is essential, but patching alone is not a security strategy.

The need for continuous vulnerability management extends well beyond PHP.

Java-based systems, including applications built on Apache Tomcat, Node.js services, and other widely deployed components all require ongoing dependency monitoring and exposure assessment.

For manufacturing organizations, the process must also account for maintenance windows, validation requirements, and operational continuity.

That means connecting several activities that are too often managed separately:

1. Continuous vulnerability intelligence: Monitor new CVEs and vendor advisories for components relevant to the environment.
2. Actual exposure assessment: Determine which deployed versions, configurations, and access paths are affected, rather than treating every published CVE as an equally urgent patch.
3. Risk-based remediation planning: Prioritize action based on exploitability, exposure, privilege, business criticality, and available mitigations.
4. Controlled deployment and validation: Test security updates against system dependencies, document changes, and verify that remediation is effective.
5. Ongoing visibility: Keep component inventories, deployment records, credentials, and vendor dependencies current as systems change.

These activities need to form a repeatable operating process, not an emergency exercise reconstructed each time a critical vulnerability appears.

How Profet AI Is Putting This into Practice

In response to recent major security advisories, Profet AI has conducted product-level component reviews and vulnerability scanning across relevant software components and container images.

The team is using those findings to assess potential impact and coordinate security updates with compatibility testing.

A further change is taking place in day-to-day monitoring.

Profet AI has introduced an internal security monitoring agent that checks CVE updates daily and helps filter advisories according to relevant software components and severity.

The purpose is not to hand security decisions entirely to AI. It is to reduce the manual effort involved in sorting through large volumes of vulnerability disclosures so that engineering and security teams can focus on confirming exposure, assessing impact, and validating remediation.

Alongside its existing product release cycle, Profet AI is developing a more structured process for delivering critical security fixes and communicating the relevant CVEs, affected product versions, and remediation status.

The aim is to give customers the information they need to coordinate updates with their operational and compatibility requirements.

This responsibility is shared.

Software providers must maintain visibility into their dependencies, protect the integrity of their release processes, communicate security issues transparently, and deliver appropriate fixes.

Enterprise customers must assess their deployed environments, manage network access and operational identities, and plan updates within their business and production constraints.

Neither side has complete visibility into the other’s environment. Effective security depends on maintaining that connection.

The same thinking applies as ML and agentic AI become more deeply embedded in manufacturing engineering and operational workflows.

Data access, tool invocation, approvals, and auditability need to be designed around clear boundaries, not left to assumptions about how an AI model will behave.

Major vulnerabilities may dominate the headlines for a few days. The underlying environment, however, changes continuously.

New dependencies are introduced. API integrations are added. Service accounts gain permissions. Software is upgraded, replaced, or quietly left running long after its original maintainers have moved on.

There will always be another vulnerability to investigate. The more durable question is whether the organization knows enough about its own systems to respond effectively.

That is a more meaningful measure of security resilience than whether an organization can claim it has never experienced an incident.

Resilience means being able to identify exposure early, understand its operational consequences, contain the impact, and recover without losing control of the systems the business depends on.

As enterprises put AI to work, maintaining that control will matter as much as the capabilities they choose to deploy.

Related reading

• From Generative AI to Agentic AI: Why MCP Is the Missing Link
• Domain Twin™: Enterprise AI Operations Platform

Sources and security guidance

• PHP security advisories and updates
• LiteLLM: October 23 root-cause analysis
• Trivy: official supply-chain incident advisory
• Railway: incident report and updates
• Microsoft: Storm-0940 and ARTEX threat intelligence
• OWASP: Excessive Agency

INDUSTRIAL AI · TECHNICAL ARCHITECTURE

A technical architecture for connecting NVIDIA-enabled physical-world intelligence with manufacturer-specific expertise, Machine Learning, Agentic AI, governance and action

Industrial digital twins model physical state and possible outcomes. Profet AI Domain Twin™ adds manufacturing knowledge, model evidence, permissions and workflows so teams can turn that evidence into governed action and reusable operating expertise.

Manufacturers have spent years building digital representations of factories, production lines, machines and products. That work is now converging with Physical AI. NVIDIA positions industrial digital twins across design, simulation, operation and optimization. NVIDIA Omniverse™ libraries and OpenUSD provide interoperable 3D data, physics, sensor simulation and validation capabilities for building simulation-ready environments used in Physical AI development.

For factory engineering, the result is a physical environment that is increasingly computable and testable. Teams can examine what is happening on a line, test how layout changes affect material flow, validate robot behavior, and evaluate throughput, energy use and other operating constraints before touching the live system. For robots, autonomous systems and AI agents that interact with the physical environment, these virtual environments also provide a controlled place to test and validate behavior before deployment. The harder engineering problem begins when physical evidence has to become an enterprise decision. The response to the same abnormal signal may depend on the active recipe revision, the current lot, maintenance history, the latest SOP, a model’s validated operating window, an engineer’s judgment and whether the system or agent is authorized to act.

Domain Twin™ is designed for that enterprise decision state. It turns accumulated manufacturing expertise, model evidence, decision logic, permissions and workflows into machine-usable operating context. Physical-state evidence can then be interpreted against the manufacturer’s own rules, responsibilities and operating history rather than treated as an isolated signal or model output.

Digital Twin models physical state. Domain Twin™ carries enterprise decision context.

The two twins encode different forms of state. In this reference architecture, the digital twin represents physical state, behavior and constraints; Domain Twin™ carries the enterprise expertise and decision logic applied around them. One provides evidence about what is happening, or what may happen under a given physical condition. The other provides the context for deciding what this manufacturer should do next, based on its knowledge, models, policies and responsibilities.

Comparison point	Industrial Digital Twin / Physical-World Intelligence	Domain Twin™ / Enterprise Domain Intelligence
What it models	Physical state, geometry, constraints and behavior.	Enterprise knowledge, engineering experience, AI / AutoML models, procedures and decision logic.
Typical inputs	Equipment state, sensor data, process conditions, simulated outcomes and physical constraints.	Engineer know-how, SOPs, historical cases, quality data, model outputs, policy, permissions and workflow context.
Questions it helps answer	What is happening? What could happen if the layout, process or robot behavior changes? How would throughput, energy use or material flow respond?	Given our knowledge, policies and experience, what should we check, decide or authorize next?
Contribution to the loop	A testable representation of the physical world.	An operational representation of how the organization understands, decides and acts.

Table 1. Two complementary forms of context inside the same industrial AI loop. This is an architectural split, not a limit on digital-twin functionality; NVIDIA industrial digital twins also extend into live operations and optimization.

What Domain Twin™ adds: enterprise expertise as an operating model

Manufacturing expertise is distributed by nature. It lives with experienced engineers, in SOPs, troubleshooting records, process parameters, maintenance history, quality reports and engineering documents. It also lives in AI and machine-learning models built for specific products, equipment families and operating windows.

What is hardest to replicate is not the documents themselves, but the reasoning that connects them. When an abnormal condition occurs, what should be checked first? Which historical cases are genuinely comparable? When is a model output strong enough to support a recommendation? When must a human approve the next step? Which engineer, system or AI agent is authorized to carry it out?

Within this architecture, Domain Twin™ functions as the enterprise AI brain for manufacturing: the layer that makes operating knowledge, model evidence, decision rights and workflows explicit enough for AI to use and for the enterprise to govern. People, Process, Knowledge and Data form the context around five functions: understand context and intent, reason across multiple sources, decide within defined options and policy, govern safety and compliance, and translate an approved decision into action. The knowledge layer can include engineering know-how, SOPs, historical cases, AI and AutoML models, quality evidence and decision logic.

Within Domain Twin™, Machine Learning and Agentic AI are complementary capabilities. AutoML provides the Machine Learning capability for structured manufacturing data, turning it into prediction, anomaly-detection and optimization models whose outputs can serve as decision evidence. AI Studio provides the Agentic AI capability: orchestrating agents across the Model Hub, Knowledge / RAG and catalogs, Tools / MCP integrations, Memory, Guardrails, ACL / ABAC and Audit. Agents can retrieve approved knowledge, invoke analytical tools or AutoML models, compare historical cases and carry a decision into a governed workflow. To make that context reusable, the system also has to preserve provenance, applicability, authority and action scope.

Retrieval alone is insufficient. A RAG system may return the right SOP, but it does not by itself establish whether that revision is valid for the active recipe, whether a model applies to the current lot, or whether the caller is authorized to act. Domain Twin™ keeps those relationships attached to the decision state.

Reference architecture: from physical state to governed action

Figure 1. Complementary architecture: physical-world intelligence and Profet AI Domain Twin™ exchange state, constraints, decisions and operational feedback inside a governed closed loop. Domain Twin™ is the product layer; AutoML and AI Studio provide its Machine Learning and Agentic AI capabilities.

Layer	Technical role	What it contributes
1 · Physical world	Equipment, production lines, robots, sensors and industrial / OT systems	Generate real-world events, telemetry, operating state and execution results.
2 · Industrial digital twin / Physical simulation	OpenUSD scene data and NVIDIA Omniverse capabilities, where applicable	Represent, simulate, validate and optimize the physical environment, behavior and constraints.
3 · Profet AI Domain Twin™	Enterprise expertise (People, Process, Knowledge, Data); Machine Learning capability (AutoML); Agentic AI capability (AI Studio) with Model Hub, Knowledge / RAG, Tools / MCP, Memory, Guardrails, ACL / ABAC and Audit	Turn manufacturer-specific expertise into machine-usable decision context; combine model evidence and agentic workflows; govern reasoning, authorization and action.
4 · Enterprise action & feedback	Human approval, enterprise-system write-back and equipment response through approved paths	Execute only within authorized scope; retain results, exceptions and feedback for audit and governed improvement.

Table 2. Four interacting layers connect physical-state evidence with enterprise decision logic and governed agent operation.

The most important engineering boundary sits between physical state and enterprise decision state. Asset identity, plant and line hierarchy, recipe revision, lot identity and timestamps have to align before an agent combines physical signals with enterprise knowledge. Model outputs need version and applicability context. Authorization must remain separate from reasoning: permission to inspect an event is not permission to modify a system. Treating this boundary as an explicit interface, rather than hiding it inside an LLM prompt, is what makes the architecture testable and governable.

From simulation to decision to action: a semiconductor equipment abnormality

Consider an equipment abnormality in a semiconductor factory. Equipment telemetry shows behavior drifting outside the expected operating range. A digital twin or another physical-world data and simulation layer can describe the equipment, surrounding environment and current state, and, where simulation is available, expose relevant physical constraints or the likely effect of a proposed change.

Diagnosis rarely depends on sensor data alone. An experienced engineer may correlate the alarm with maintenance history, process conditions, the active recipe and key parameters, recent lot context, prior failure cases, equipment documentation, quality data, the current SOP and analytical or AutoML model outputs. Within Domain Twin™, the Agentic AI capability can bring those sources into the same decision context, invoke approved models and tools, and compare the current event with historical cases rather than treating each source in isolation.

At that point, the agent enters a stateful enterprise workflow. It observes the event, analyzes the relevant evidence, recommends a bounded next step, validates it against operating rules and model limits, routes it through the required authorization, and only then invokes the approved action. The outcome returns to the system as traceable feedback for the next decision cycle. The result is a governed operational workflow in which AI participates under explicit enterprise controls.

Figure 2. Domain Twin™ governed industrial AI workflow: an abnormal event moves from observation and analysis through recommendation, validation, authorization and execution, with results retained as traceable feedback.

Step	Engineering behavior
Observe	Capture the abnormal event, equipment signals, telemetry and operating context.
Analyze	Correlate data, historical cases, SOPs, engineering knowledge and analytical / AutoML evidence.
Recommend	Propose likely causes, the next inspection or a bounded corrective action with supporting evidence.
Validate	Cross-check the recommendation against operating limits, approved procedures, model applicability and enterprise policy.
Authorize	Apply RBAC / ABAC and Human-in-the-Loop controls. Where used, issue time-bounded authorization scoped to the action and duration.
Execute	Invoke only the approved workflow, enterprise-system action or equipment response within the authorized scope.
Learn	Record outcome, audit trail and memory. Feed the result into governed knowledge, model or workflow improvement.

Table 3. Engineering behavior behind a governed abnormal-event workflow.

Governance belongs in the runtime architecture

Once an agent can use enterprise tools, write back to systems or affect equipment, governance becomes runtime behavior. RBAC or ABAC can determine whether the agent may access a particular model, knowledge source or tool. Human-in-the-Loop controls can require a qualified engineer to approve high-impact actions. Where used, a time-bounded authorization token can constrain both permission scope and duration. Every consequential step should leave enough evidence to reconstruct what the agent saw, which sources and models it used, who approved the action and what happened afterward.

Learning belongs inside the same control model. Operational outcomes can be retained as feedback, memory and new enterprise knowledge for the next decision cycle. Model retraining, knowledge changes and workflow updates should still pass through their own validation, versioning and governance before they return to production.

How this architecture aligns with NVIDIA Physical AI

NVIDIA describes a three-computer solution for Physical AI spanning training, simulation and real-time inference and control. DGX systems support training; Omniverse and Cosmos on RTX PRO Servers support simulation; Jetson AGX systems support real-time inference and control. NVIDIA’s industrial digital twin portfolio also extends into operation and optimization. The Factory Operations Blueprint (FOX) is a reference design for building autonomous factory-manager agents that reason across live factory data and coordinate specialized agents and machines.

As NVIDIA capabilities extend into live factory operations, manufacturer-specific domain context becomes a core architecture requirement. Orchestration can coordinate agents and machines, but it cannot know a manufacturer’s recipe authority, valid SOP revision, model operating window, escalation path or plant-specific exception unless those states are represented explicitly. Domain Twin™ is designed to carry that context.

Physical AI stage	NVIDIA role	Domain Twin™ contribution
Training / model development	Train and improve AI capabilities with accelerated computing and data.	Bring validated model outputs into the enterprise knowledge and decision context.
Simulation / digital twin	Represent, test and optimize physical environments, behavior and constraints before deployment.	Use physical state, simulated outcomes and constraints as evidence in enterprise reasoning and decision workflows.
Inference / factory operations	Run AI close to physical systems and coordinate operational AI patterns, including factory-agent architectures.	Apply manufacturer-specific knowledge, decision logic, permissions, approval conditions and governed workflows around what happens next.

Table 4. NVIDIA Physical AI and Domain Twin™ address different, complementary parts of the industrial AI lifecycle.

A closed loop depends on bidirectional context and constraints

The loop is bidirectional. Physical-world systems and digital twins can provide real-time state, simulated outcomes and physical constraints to Domain Twin™ and its agents. Domain Twin™ can return enterprise goals, engineering logic, decision rules, security policy and human-approval requirements to planning and execution. Once a decision is validated and authorized, the agent can translate it into an enterprise-system action or approved equipment response. The result then returns as feedback, memory and enterprise knowledge for the next cycle.

Exchange direction	Typical content
Physical world / Digital Twin → Domain Twin™	Equipment state, telemetry, simulated outcomes, physical constraints and event identity
Domain Twin™ → planning / agent workflow	Enterprise goals, engineering logic, SOPs, model evidence, security policy and human-approval requirements
Agent workflow → enterprise / equipment	Recommended action, evidence summary, authorized parameters and target tool / system
Outcome → Domain Twin™	System response, exceptions, engineer feedback and operating result retained as feedback, memory and enterprise knowledge

Table 5. The operating loop closes only when context, constraints and outcomes can move in both directions.

Where Domain Twin™ fits in the NVIDIA industrial AI ecosystem

NVIDIA’s industrial AI foundation now spans digital twins, Physical AI and factory-level agent orchestration. What remains manufacturer-specific is the operating context around that foundation: recipe ownership, SOP validity, trusted historical cases, model applicability, approval matrices and the differences between products, lines, plants and regions. The more capable the horizontal foundation becomes, the more important it is to formalize this domain layer, because models, agents and physical systems need to share the same operating semantics and decision rights.

NVIDIA’s Foxconn case study illustrates the physical side of portability: standardized OpenUSD-based digital-twin assets are used to migrate and duplicate production-line layouts across global sites. That leaves a second portability problem at the enterprise layer: how the validated decision method, model applicability, SOP authority and approval boundaries travel with the line. Domain Twin™ is designed to make that operating context portable without detaching it from governance.

Domain Twin™ is Profet AI’s implementation of that manufacturer-specific layer. At the point where horizontal industrial AI enters live operations, this layer stops being an implementation detail: it is what keeps context, authority and model applicability consistent as more models, agents and physical systems participate in the same workflow. Domain Twin™ carries those operating semantics, evidence, decision rights and governance boundaries across the industrial AI stack.

In the reference architecture described here, Domain Twin™ serves as the manufacturing domain software layer. It is designed to connect NVIDIA-enabled physical intelligence with the manufacturer’s own knowledge, models, permissions and workflows and preserve that operating context as governed, auditable and reusable AI assets. At scale, what should move from one proof of concept to another line or plant is not an agent transcript. It is a validated decision method: the relevant knowledge, model evidence, operating rules, workflow and governance boundary. That is what turns a horizontal technology foundation into repeatable manufacturing capability without forcing every site to rebuild the same operating knowledge.

From higher-fidelity simulation to repeatable industrial operations

Industrial digital twins will continue to gain physical fidelity, simulation speed and operational reach. Factories also run on accumulated human experience, process knowledge, business rules, security policy and organizational responsibility. If industrial AI is expected to operate consistently beyond a single use case, those elements need a machine-usable and governable representation of their own.

Connecting the twin of the physical world with the twin of enterprise expertise creates a more complete industrial AI loop: sense what is happening, simulate what may happen, reason with enterprise context, decide within policy, act through an authorized path and retain the outcome for the next cycle.

Digital twins give Physical AI a world it can observe, simulate and optimize. Domain Twin™ gives industrial AI a durable representation of enterprise expertise, model evidence, permissions and decision logic, with Machine Learning and Agentic AI capabilities operating inside the same governed context. Connected through a closed operating loop, the two create a path from physical intelligence to accountable action and from a successful use case to repeatable deployment across lines and plants. Manufacturing know-how becomes a reusable enterprise asset without losing the evidence, authority and controls that make it trustworthy.

Frequently asked questions

Does Domain Twin replace an industrial digital twin?

No. In this architecture, the industrial digital twin supplies physical state, simulation results and constraints. Domain Twin adds manufacturer-specific knowledge, model evidence, permissions and workflows for governed decisions and actions.

Can an AI agent change equipment settings without approval?

Only actions within the explicitly authorized scope should execute. Process limits, access controls, required human approvals and audit records define the boundary between a recommendation and an equipment or enterprise-system action.

By James Yang, Executive Assistant to the CEO, Profet AI

Seven Capability Domains, Three Maturity Tiers: A Completely Different Approach to Defense

After finishing the previous article, if you are calculating which tool to buy to address each type of threat, pause for a moment. The mindset of patching vulnerabilities one by one could barely keep pace back in the era of human attackers. Now that attackers are also using AI agents, new attack techniques are emerging faster than security teams can patch them. This article is about switching to a completely different defense logic.

Zero Trust as a concept traces back to 1994, when Stephen Paul Marsh first systematically proposed it in his doctoral dissertation at the University of Stirling. NIST formally established concrete guidance with SP 800-207 in 2020. In its report “Zero Trust for AI Agents,” Anthropic applies this framework to the entirely new attack surface of agentic AI, proposing seven capability domains detailed down to an executable level.

One Principle, Three Tenets

The core logic of Zero Trust, in one sentence: trust nothing and no one, verify every access request, and assume a breach has already occurred. Expanded, this becomes three tenets:

•       Never trust, always verify: Every access request must be authenticated and authorized, regardless of whether it originates from inside the corporate network.

•       Assume breach: Systems should be designed on the assumption that intrusion will eventually happen. The focus is not on preventing intrusion, but on limiting the damage an attacker can do once inside.

•       Least privilege: Grant only the minimum access needed to complete a task, so that any single breach is contained to a small blast radius.

More important than the principles themselves is a litmus test: does this control make an attack impossible, or does it merely make the attack more inconvenient? Defenses that rely on “adding friction”, extra jump boxes, rate limiting, non-standard ports, lose most of their effectiveness against automated attackers whose cost per attempt approaches zero. Controls that actually hold up share a common trait: hardware-bound credentials, tokens that expire, cryptographic identities, and network paths that simply do not exist. This litmus test runs through all seven capability domains described below.

Three Maturity Tiers: A Growth Path, Not Three Options

Anthropic breaks each capability domain into three tiers: Foundation, Enterprise, and Advanced. Enterprise builds on Foundation, and Advanced builds on Enterprise, each tier reinforcing existing controls layer by layer rather than starting over. Foundation is the entry point into Zero Trust. Enterprise is the target level most organizations of a certain size should aim for. Advanced is designed for heavily regulated industries, national security applications, or deployments where the consequences of failure are severe.

Worth noting: because of the compressed attack speed discussed in the previous article, the bar for Foundation itself has been raised. Practices once considered a reasonable starting point, such as managing risk through API key rotation, no longer qualify. Short-lived tokens, cryptographically rooted identities, identity-based isolation, and automated frontline alert triage are now baseline requirements, not advanced options.

Seven Capability Domains: A Complete Chain from Foundation to Governance

Agent Identity and Authentication

Identity and authentication form the foundation underlying all other capabilities. Without a verifiable identity, access control cannot be enforced, and behavior cannot be attributed to a specific agent. The path runs from cryptographically rooted persistent identity, to certificate-based authentication paired with lifecycle management, and ultimately to hardware-bound identity, where credentials are stored in a hardware security module and integrity is verified through remote attestation.

Once identity is established, an agent must prove its identity again every time it accesses a service. This is service authentication. The path runs from short-lived tokens measured in minutes, to mutual TLS with certificate pinning, and ultimately to hardware-bound credentials. Managing risk through API key rotation is no longer sufficient, because credentials that can be extracted from a codebase do not become meaningfully harder to steal no matter how often they are rotated.

Access Control and Privilege Management

An agent with legitimate permissions has a genuine identity. The problem is what it does once authorized. The path runs from role-based access control with default deny, to attribute-based access control that factors in context such as time, location, and risk score, and ultimately to real-time authorization that is re-evaluated for every single action. OWASP’s concept of Least Agency extends least privilege to cover what each tool is allowed to do, how often, and where, for example limiting a database tool to read-only queries.

It is worth being precise about the difference between RBAC and ABAC. RBAC (role-based access control) only looks at what role an agent holds. Once a role is assigned, its scope of permissions is fixed, and every agent under that role has identical access regardless of context. ABAC (attribute-based access control) goes further and factors in the context of the request itself, such as time, location, data sensitivity, and risk score. Two agents may both be customer service agents, but one querying general customer data during normal hours will be allowed through, while the same agent pulling large volumes of highly sensitive data late at night may be denied or asked for additional verification. Moving from RBAC to ABAC is essentially upgrading from a static judgment of “who you are” to a dynamic judgment of “what you are doing right now and how risky it is.” This is the single most important upgrade in moving from Foundation to Enterprise.

While the permission model decides whether access should be granted at all, the scope of that access determines when and for how long it can be exercised. Static permissions, once granted, persist indefinitely, remaining active even after the task is finished and creating long-term exposure. Dynamic permissions are elevated only for the duration of task execution and are withdrawn immediately afterward. The strictest form, just-in-time and just-enough access (JIT/JEA), compresses even the act of elevation to nearly the moment of use, granting access only at the instant it is actually needed and automatically revoking it on timeout or task completion, leaving no residual access behind. Last is the boundary of resources: identity-based isolation as the primary control, supplemented by network segmentation, progressing to containerized sandboxing, and ultimately to hardware isolation. For agents that process untrusted input, sandboxed execution is standard practice, not optional.

Observability and Auditing

Access control determines what gets blocked. Observability determines what actually happened. Logging progresses from complete records with timestamps, to tamper-evident audit trails, and ultimately to real-time streaming into a centralized monitoring platform. But before chasing the specifications of all three tiers, it is worth first establishing measurement for two metrics: dwell time (the interval between an anomaly occurring and a human noticing it) and coverage (the proportion of alerts that are actually investigated). These are the two metrics where AI automation delivers the greatest leverage.

Traceability is a separate dimension: generating a unique identifier for each request that follows it through every subsequent action, progressing to distributed tracing across multi-agent workflows, and ultimately to a complete provenance chain that supports replaying the full decision history. Logging answers “what happened.” Traceability answers “why it happened.”

Behavioral Monitoring and Response

Behavioral monitoring has to judge whether a given behavior is normal or suspicious, which requires an established baseline before anomalies can be identified. Baselines progress from being manually defined, to automatically learned statistical baselines, and ultimately to baselines that continuously update and can detect slow, gradual drift. This tier specifically addresses techniques such as long-term memory drift. Anomaly detection progresses from threshold-based alerts, to statistical methods, and ultimately to machine learning models that incorporate contextual information.

Once an anomaly is detected, response speed is what actually determines the extent of the damage. The division of labor is clear: automation handles the paperwork, logging, evidence collection, and drafting initial reports, while decisions about containment, disclosure, and customer communication remain with humans. Response capability itself also progresses through three tiers: alerts routed to the security team with a triage agent producing an initial assessment, progressing to automated execution of containment actions, and ultimately to agentic SOAR capable of coordinating containment across multiple systems. What automation should do is free up human response time, not replace final judgment.

Input Validation and Output Controls

This domain is the direct countermeasure to indirect prompt injection. On the input side, the path runs from basic format validation, to content filtering that screens out encoded payloads and suspicious instructions, and ultimately to multi-layer validation combining AI classifiers with content boundary markers. SQL injection has well-defined attack patterns that can be defended against, but agent input is free-form and unpredictable, so rule-based defense alone is not enough.

The output side guards against data exfiltration: progressing from scanning for sensitive patterns, to analyzing the semantics of output to identify social engineering risk, and ultimately to requiring human approval for high-risk actions. Input validation prevents malicious manipulation. Output control prevents data leakage. Both are essential.

Integrity and Recovery

When every other defense fails and a breach actually occurs, attackers often turn to tampering with the agent’s own configuration. The path runs from version control, to cryptographic signing, and ultimately to immutable infrastructure, where configurations are never modified but wholesale replaced, with image integrity verified before execution.

One practice runs counter to intuition: for components where risk is acceptable, enabling automatic updates is actually safer than insisting on manual approval, because the delay inherent in manual approval is itself a risk. The solution is to let automatic updates coexist with pre-deployment signature verification: signed updates flow through automatically, while unsigned changes are rejected outright. Recovery follows a similar path, from documented rollback procedures, to automated rollback, and ultimately to self-healing systems. No amount of automation can save a situation that cannot reliably roll back to a known good state.

AI Governance Policies

Technical controls can only enforce what governance policy defines. The path runs from a documented acceptable use policy, to a cross-functional governance framework that includes security, legal, and business stakeholders, and ultimately to embedding policy checks into the deployment pipeline itself, automatically detecting violations. Shadow AI, meaning employees using LLM tools on their own without approval, bypasses every one of the controls described above. This is the reality governance has to confront.

Seven Capability Domains: A Complete Chain from Foundation to Governance

Having gone through the seven capability domains, you do not need to redesign your defenses for every new attack technique that emerges. What you need to do is check where your enterprise’s existing agent deployments stand across these seven areas. Identity makes attribution and access control possible. Observability reveals what actually happened. Behavioral monitoring detects anomalies. Input and output controls intercept attacks at the boundary. Integrity makes recovery possible. Skip any one of these areas, and that is the gap attackers will come through.

The next article moves from framework to implementation: a concrete operational workflow, and how defense teams can accelerate their security operations to keep pace now that attack speed has compressed to a matter of hours.

By James Yang, Executive Assistant to the CEO, Profet AI

From Breach to Exfiltration in 72 Minutes: Five Threats Enterprises Must Redefine for the Agentic AI Era

AI is destabilizing the balance of speed between attackers and defenders, and most enterprises have yet to grasp this. Palo Alto Networks Unit 42’s 2026 Global Incident Response Report, drawing on more than 750 major security incidents across over 50 countries, found that the fastest 25% of attacks now take an average of just 72 minutes from initial access to full data exfiltration, four times faster than the previous year. The same report found that attackers begin automated scanning an average of 15 minutes after a vulnerability is disclosed.

This velocity is not an isolated finding. Verizon’s 2026 Data Breach Investigations Report found that nearly one third of data breaches now originate from software vulnerabilities, surpassing stolen credentials as the leading initial access vector. On the defense side, the World Economic Forum and KPMG’s Empowering Defenders report offers a telling counterpoint: organizations with mature AI defense capabilities cut breach detection and response cycles by roughly 80 days and reduce average breach costs by up to 1.9 million US dollars.

Seventy two minutes. Fifteen minutes. This is the attacker’s timetable today. Can your security team keep pace?

Two Curves Accelerating at Once

Enterprises are deploying AI agents at an equally striking pace. BCG’s 2026 AI Radar found that 90% of CEOs worldwide expect AI agents to deliver measurable ROI this year. Gartner forecasts that by the end of 2026, 40% of enterprise applications will incorporate task specific AI agents, up from under 5% in early 2025.

Taken together, these numbers point to the same conclusion: AI does not take sides. It accelerates both defenders and attackers at once. The only question is who recognizes that the rules have changed first.

Conversations about AI security and governance have traditionally centered on the model itself: Is it safe? Will our data be used for training? What does the privacy policy say? These are valid questions, but they belong to the old battlefield. What deserves real attention in 2026 is something else entirely: as enterprises push AI agents to the front lines, attackers are arming themselves with the same technology, often well ahead of the enterprises they target. Governance itself has quietly become a competitive advantage.

Why Traditional Defenses Cannot Hold This Line

Traditional security logic is sound: verify identity, confirm authorization, allow actions within scope. That logic has protected enterprises for two decades. But an AI agent operating with legitimate, properly issued credentials has not broken through any door it was not supposed to open. The problem lies in what it does once it has been authorized.

This is the most fundamental way AI agents differ from every prior category of security incident. Traditional access control governs who gets through the door, but an agent capable of reading databases, sending emails, and querying industrial control systems can be manipulated into taking an action that falls within its permissions yet was never meant to happen, and no access control can stop it, because from the system’s perspective, every credential is valid, every process is normal, and no rule has been broken.

The five threats unfolding right now all target the same blind spot: what is actually hiding behind operations that look entirely legitimate.

Five Threats Unfolding Now

Threat One: Indirect Prompt Injection

This is the blind spot most easily overlooked in this era. A conventional question answering AI only responds to input typed directly by a user. An AI agent is different: it browses the web, reads documents, and queries databases on its own initiative, gathering information and taking action autonomously. This capability opens an entirely new attack surface. An attacker only needs to embed a hidden instruction for the agent inside a web page, an email attachment, or a shared document. The root cause is a fundamental technical limitation: Microsoft Research has confirmed that large language models cannot reliably distinguish between text that is merely reference material and text that constitutes an instruction to be executed. The user never sees the malicious instruction, yet the agent treats it as a legitimate request and carries it out. When an agent is granted access to external files or industrial databases and integrated with MES, ERP, or OT control systems, the consequences escalate sharply. Research published in the journal Information (MDPI) in January 2026 found that in industrial control settings, the potential impact of this class of attack extends well beyond data exfiltration into direct manipulation of production systems. A Center for Internet Security report from April 2026 recorded a 340% year over year increase in related attacks, and the OWASP GenAI Security Project ranks prompt injection as the top threat to agentic AI.

Threat Two: Tool Misuse and Tool Chaining

Every tool an agent can call opens another door an attacker might exploit. An attacker can tamper with a tool’s description or interface, tricking the agent into trusting a compromised tool and executing an unauthorized action, a technique known as tool poisoning. Alternatively, an attacker can leave a tool clean for a period of time, then swap in a malicious version once the agent has come to trust it, a technique known as a rug pull. Anthropic has documented a real world case: the first malicious MCP server ever discovered in the wild posed as a legitimate email service while secretly copying every message the user sent. Harder still to detect is tool chaining. Viewed individually, an internal CRM lookup tool and an external email tool are each perfectly safe, but an attacker can induce the agent to chain them together, pulling customer records with the CRM tool and exfiltrating them through the email tool. The entire sequence runs on legitimate credentials through normal program execution, so conventional malware monitoring detects nothing at all.

Beyond tampering with the tools themselves, an agent’s automated nature can also be exploited directly. A human operator grows fatigued with repetitive tasks and pauses to check in, but an agent does not. As long as its logic concludes that one more query is warranted, it will keep triggering the next call. An attacker needs only to trap the agent in a loop, repeatedly invoking a costly external API, to cause a service outage or a runaway cloud bill within minutes. The entire attack is self triggered by the agent, requires no human intervention, and does not need to breach any system at all. It is often noticed only after the bill or the service alert arrives, a textbook case of legitimate functionality being overused rather than a conventional intrusion.

Threat Three: Identity and Privilege Abuse

A common failure in multi agent systems is unscoped privilege inheritance: a high privilege manager agent delegates a task to a worker agent without applying least privilege scoping, passing along its full access rights unchanged. A related variant is the confused deputy problem: a lower privilege agent forwards an instruction that appears legitimate to a higher privilege agent, which executes it without verifying the original user’s intent. Risk can also hide in memory. If an agent caches credentials or keys from a prior session for reuse without proper memory segmentation, an attacker can prompt it to retrieve those residual credentials and carry out actions its own credentials would never permit, effectively escalating privilege across session boundaries. When multiple agents routinely trust and delegate to one another, these gaps widen further, and reconstructing which delegation caused the breach often only happens after the fact.

Threat Four: Supply Chain and Model Risk

Agentic systems differ from traditional software in that they frequently assemble capabilities at runtime, loading external tools and switching between models or personas on the fly, which pushes the attack surface beyond what traditional software supply chain analysis can handle. The risk operates on two layers. One lies in the model itself: if training data or the fine tuning process is tampered with, a backdoor can survive the entire deployment lifecycle. Anthropic’s own research found that injecting just 250 malicious documents is enough to plant a backdoor in models ranging from 600 million to 13 billion parameters, and that backdoor persists even after subsequent safety training, including supervised fine tuning and RLHF. The other layer lies in tools and frameworks: the PyTorch dependency confusion attack showed how malicious packages can exfiltrate SSH keys during installation, and security researchers have identified roughly 100 malicious AI models on major platforms, some of which open a reverse shell the moment they are loaded. A model’s provenance, where its training data came from and whose hands it passed through, is itself an attack surface that warrants scrutiny.

Threat Five: Memory and Context Poisoning

Agents retain records of past interactions to become more useful, but without proper isolation, a single successful injection can poison every future session, leaving the agent to carry out an attacker’s planted instructions indefinitely. Contamination can arrive through more than one channel. If an agent relies on a vector database for retrieval (RAG), poisoned sources, direct uploads, or an overly trusted data pipeline can all introduce malicious data into that database, and anything the agent later retrieves from it can produce false answers or execute a planted payload. In multi tenant environments, contamination can also spread through shared context, passing from one user’s session into another’s.

These poisoning techniques can still be traced back to a single identifiable event. Long term memory drift is a harder to detect variant. It does not rely on one successful injection but instead works through summarization or feedback from other agents, gradually and quietly distorting the knowledge or goal weighting an agent has stored. Because each individual change looks harmless in isolation, perhaps a slight shift in how a summary is worded or a minor adjustment in weighting, conventional anomaly detection struggles to flag any single instance. It is typically only noticed once the agent’s behavior has visibly drifted from its original scope, and by then the drift may have been accumulating for a long time.

From Chasing Threats to Principled Defense

Having read through these five threats, it is easy to fall into a particular kind of anxiety: does every new attack technique require a new corresponding defense? Follow that logic and you will spend forever chasing attackers, because new techniques keep emerging faster than any team can patch for them. The real question is different: is there a set of principles that holds regardless of what new technique appears next, so that as long as the principles are upheld, the defense holds too.

If a service account’s access were scoped down from the outset to the minimum dataset its task actually requires, then even if it were manipulated into an anomalous action, the blast radius would already be confined to a small perimeter. The breach happens, but the damage is contained. That is an achievable defensive posture: not preventing every breach, but ensuring a breach never becomes the start of a disaster.

In the next installment, we break down a systematic framework for putting this into practice: eight capability domains across three tiers of maturity, showing exactly what a defense architecture built to withstand the agentic AI era looks like.